Add support for EncFS

[Anuskuss]

Leaving the keys in /etc/efi-keys unprotected kinda defeats the purpose of SecureBoot, so I've added support for EncFS.

[Maryse47]

Right, leaving the keys unencrypted on hard drive isn't best idea although using EncFS which is at this point obsolete isn't best idea either. Much better solutions like fscrypt exist.

Generally encrypting just one directory is poor solution for extra security. I would recommend using FDE with LUKS and I wouldn't make a sbudate directly responsible for encryption/decryption of any files as it's orthogonal to its job.

[Anuskuss]

using EncFS which is at this point obsolete

Hm, I've been using EncFS for ages and I think it's neither obsolete nor insecure. At the end of the day, it's still AES@256b so good luck with that. But I guess I'll give fscrypt a try since it seems to be getting regular updates (which isn't necessarily a good thing btw).

Generally encrypting just one directory is poor solution for extra security. I would recommend using FDE with LUKS

My keys are already safe from outside by utilizing my SED (self-encrypting drive) via Opal (hardware encryption). This is just for extra security from the inside.

make a sbudate directly responsible for encryption/decryption of any files

Well, true, it's just something I've been doing myself and I though others would benefit from as well. Following the guides online and then using sbupdate gives you a false sense of security ("Place your custom keys in /etc/efi-keys") and anything is better than nothing. It doesn't even have to be EncFS, you could still do fscrypt/7-zip/LUKS2 yourself. It's just EncFS is super easy to setup and I do think sbupdate should make an effort to protect it's user in that regard (since you're already spoon-feeding anyway by being a convenience script).

Edit: fscrypt doesn't work for me because I use btrfs.

[Maryse47]

Certainly decrypting keys like that makes the extra security close to the security theater. Never put decrypted data in fixed path accessible for everything. This is the example of false sense of security when your threat model assumes adversary have accesses to booted system (it does, right?).

[Anuskuss]

Never put decrypted data in fixed path accessible for everything.

I don't understand how that's a concern. The data is encrypted on-disk, decrypted only after the right password has been used and then removed immediately after sbupdate did its job. Unless you mean that malware could specifically wait for /tmp/efi-keys, which shouldn't be worrisome because the decrypted files will share the same permissions as the corresponding encrypted files (in my case root:root 0600). If the malware can read that (i.e. has root privileges) you're going to have bigger problems.

[Maryse47]

If the malware can read that (i.e. has root privileges) you're going to have bigger problems.

So what's the difference between unencrypted and encrypted files then if you consider file permissions as sufficient attack prevention? The threat you want to protect from is already protected while others still aren't - just security theater all over.

You need to define exact scenario which additional encryption helps for otherwise the extra security is just empty buzzword.

[Anuskuss]

Okay, so instead of just criticizing my approach, why don't you present yours? Why doesn't the ReadMe say anything about "Hey, but don't just leave your keys around. Encrypt them or put them on a separate drive. At the very least, make them only readable by sbupdate (root)." Or something like that. For the longest time I just followed the Arch Wiki and left my keys unprotected, thinking that I'm completely safe (which considering we are talking about "Secure Boot" here, is not even remotely true). I didn't even think about the possibility that I need to protect my keys. Atleast I made an honest effort to solve this. Do with my code whatever you want, I don't care. Or write your own solution. But atleast consider mentioning this in the ReadMe, otherwise this whole thing is pointless.