That snap-based TPM setup also breaks spectacularly. I would highly recommend people using something else entirely.
Basically if any bug surfaces in the encryption setup snap permanently loses the ability to update kernel, which, if you care about security, means the system has to be reinstalled to resume receiving kernel bug fixes. The issue is in "Wishlist".
can someone explain like I'm 5, what's the point of during storing disk encryption keys in TPM? What kind of attack or attacker do we protect from?
my logic is following:
- if the attacker is remote and somehow modifies my kernel... Yes, the tpm and hardware attestation (is this the term?) would have saved me. But I'm fucked anyway since the attacker already has root on my computer
- if the attacker is local -- yes, with tpm they cannot steal just the hard drive and bruteforce it offline. But they can just reset bios and install their own os and trick me into typing the os passwords? Or even if they cannot trick me (hard to spoof my os UI) they can just install a physical keylogger?
so, if you use encryption on ubuntu you get a vendor controlled delivery path that has all the practical properties of a backdoor, without the transparency to easily prove its not being used as one
Nice to see a Linux vendor developing a sealed environment, but rather cruel of them to hide it silently behind a disk encryption checkbox. I suppose they must consider their non-paying users as test subjects? Lots of bugs in process here that need to be cleaned up for this to remain viable if Steam Linux decides to compete in the sealed-signed-attested space someday.
7 comments
[ 0.25 ms ] story [ 15.1 ms ] threadBasically if any bug surfaces in the encryption setup snap permanently loses the ability to update kernel, which, if you care about security, means the system has to be reinstalled to resume receiving kernel bug fixes. The issue is in "Wishlist".
https://bugs.launchpad.net/snapd/+bug/2045417
can someone explain like I'm 5, what's the point of during storing disk encryption keys in TPM? What kind of attack or attacker do we protect from?
my logic is following: - if the attacker is remote and somehow modifies my kernel... Yes, the tpm and hardware attestation (is this the term?) would have saved me. But I'm fucked anyway since the attacker already has root on my computer
- if the attacker is local -- yes, with tpm they cannot steal just the hard drive and bruteforce it offline. But they can just reset bios and install their own os and trick me into typing the os passwords? Or even if they cannot trick me (hard to spoof my os UI) they can just install a physical keylogger?
Also a reminder that when OEMs ship Linux distros, it is always customised.
the threat model does not make sense. especially in the past when it was i2c