sbctl VS tang

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl

No problem! The sbctl package ships with a pretty extensive hook out of the box (https://github.com/Foxboron/sbctl/blob/master/contrib/pacman/ZZ-sbctl.hook). It's been very reliable for automatically resigning .efi executables after updates for me.

sbctl verify returns failed to find EFI system partition despite it definitely is there. It's the same issue as this but remounting or restarting doesn't fix it.

lol

Must actually prevent unsigned images from booting

sudo dnf install asciidoc golang -y VERSION=0.11 cd /tmp curl -L "https://github.com/Foxboron/sbctl/releases/download/${VERSION}/sbctl-${VERSION}.tar.gz" | tar zxvf - cd "sbctl-${VERSION}" make sudo make install cd ~

By far the easiest is to use sbctl to generate, install and use keys to sign your efi images. You can use mkinitcpio to build the unified kernels automatically and a pacman trigger to rerun the sbctl signing when the kernel is updated. Pretty straightforward (once you've done it once).

The question is whether you have any UEFI drivers or not. If they're in the ESP you can just look there to check, but UEFI drivers can also be loaded from PCI cards or baked in the firmware itself.

If you're using a TPM for Secure Boot, you can use the command in https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom to know for sure.

Have a look at clevis and tang. These allow you do have one server - which could be your remote you want to pull from - to be source of the LUKS decryption on the system using tang.

I found that running tang[1] at home and needing to decrypt that box (can be a Pi or whatever) requiring a complex passphrase is very sufficient. You can even just unplug it at night if it makes you sleep better.

https://github.com/latchset/tang

There are 3 ways to unlock a volume in a headless environment: - use a keyfile, located on an already available volume - use your device's TPM and utilize systemd-cryptenroll - use Clevis/Tang to unlock volumes remotely

This is why on headless servers you use tang (ideally, multiple tang servers)

Sharing my notes on running a Tang server on OPNSense, in case it is useful for somebody else.

We use clevis against multiple tang servers to provide Network Bound Disk Encryption (NBDE). It's possible to also use TPM2 but it's easier to use multiple tang servers (requiring more than one server to decrypt) in the datacenter.

For automating unlocking of encrypted drives, look into tang . Here is a red hat guide on setting it up. You will want to be running this on another device on your network, i run it on my router with openwrt since its a local device thats on 24/7. Basically it will unlock your disks as long as your server is on your network, so if your machine or drives are stolen or removed from your network they will just be encrypted as usual. Obviously use a strong encryption password.

There are other ways to bind data, e.g. "network binding" with Tang server.

I wonder if https://github.com/latchset/clevis and https://github.com/latchset/tang (complementary projects) will help here.

Yes you can, using either Mandos or Clevis and Tang. https://www.recompile.se/mandos https://github.com/latchset/clevis https://github.com/latchset/tang. Basically on boot the server gets the key from another(s) servers. You could use a hidden raspberry pi for example.