- cross-posted to:
- linux@programming.dev
- cross-posted to:
- linux@programming.dev
You must log in or # to comment.
Isn’t setting up fscrypt on your home partition enough?
Integrated TPM chips have been busted for a while
TPM + Pin with Secure Boot is still unbroken AFAIK
And as far als inux goes, physical access to TPM is game over
Automated TPM2 LUKS setup might be the one thing that can get me to switch from Fedora to OpenSUSE.
TPM unlocking FDE is complicated for me. I fully understand measured boot and support it, but it seems less secure to me than manually unlocking the disk.
Once the disk is unlocked and you’re put onto the display manager, I feel like there are many more vulnerabilities that could be exploited to gain access to your data.
With manually entering the disk password, the data is locked. You either need to brute force it or use the XKCD wrench method.
So I feel TPM+Pin is the best for security. Unfortunately Aeon, which is based on OpenSUSE and implements TPM, doesn’t support TPM+Pin. I think it’s mainly due to how poor and widespread TPM support is. It could lock you out entirely.
What makes TPM+pin safer than just having a normal LUKS password? I would think it would be the same amount of security just with more chance of data loss if your computer gets damaged
TPM is used for measured boot. Measured boot can check various parts of the system to ensure they are the expected values haven’t been tampered with. You don’t want a part of the system to be replaced with malware and not realize it.
If it detects something changed, it won’t release its secret. It may signal to you that something malicious was done or something benign that the OS updated didn’t account for.
Interesting, how do you recover from that and get your data back?
A recovery code. I did a test install of Aeon and was given the code: dhnhlgc-fbndjbni-ufrkcfnk-nfebvtut-ftkkiiur-tijidtub-hujnucgu-erduhije
64 digits, but only alphabetical and a certain subset (16/26) due to weirdness of keyboard layouts.
As I understand it the TPM is for people who have physical access. It prevents them from cloning your disk.
I think with an adequately long password (or an adequately resource-intensive encryption algorithm) you can secure your disk enough to prevent unauthorized access. But the TPM would prevent them from removing your hard-drive and shunting it into a super-computer (so all password attempts would need to be on the crummy 10-year old laptop CPU) so a TPM + password is more secure.
I’ve read the arguments and trust the people who know far more than I do about this, but… I just find it difficult to think of “unlocks automatically” as more safe than “is locked until I enter my password”. I’m open for it, but it just feels strange to me.
Is it possible to configure the kernel to allow access to decrypted contend only through the user session?
Theoretically, kernel keys can be set to be readable only by the user session, and in an uncompromised root is not able to read those keys. I can imagine a filesystem encryption design that uses a user session key to en/decrypt data on the fly using a user session key, such that not even root or a process in another user session could read the mounted filesystem.
Does such a system exist? As I understand, this is not the way dm-crypt or LUKS work. FDE and TPM are still vulnerable to hacking while everything is running, unlocked, and mounted.
I believe thats how Android works. As I recall, it uses fscrypt.
Yeah, it sounds like something you could do with SE linux and some scripting to handle mounting the user’s filesystem as needed.
Ok, I went and read some more about it, and you can manage keys with the kernel user session keyring. So it’s possible.
It brought me back around to why systemd is so shitty.
Session Keyring (Rejected)
This strategy involves placing all keys for fscrypt in KEY_SPEC_SESSION_KEYRING. Using the current session keyring means that fscrypt will not need elevated privileges to place keys in this keyring, eliminating the need for a setuid binary. It also means that if something like pam_keyinit is used, the keys will be inherited across things like sudo.
However, this strategy has a few significant downsides that led to it not being used. The first issue is that keys unlocked in one session for a user are (sometimes) not accessible to the user in other sessions. This can create confusion for users unable to access certain directories. However, the bigger problem is that systemd is incompatible with use of the system keyring. The systemd maintainers are of the reasonable position that the session keyring just shouldn’t be used.
Emphasis mine. Because the user session keyring is incompatible with systemd, the Poetterites say it shouldn’t be used.
The only way to handle keys securely Ok base Linux shouldn’t be used because it’s incompatible with systemd. What a way to see the world: so convinced in the superiority of your monolithic monster system that you argue against an immediately available way of improving security.
It’s incompatible, by the way, because systemd doesn’t run user jobs in the user’s session, but in parallel sessions. This means that, if you use systemd, you can’t use the most secure way of handling secrets with fscrypt, the kernel user session keyring.
