It seems it's quite often that Ubuntu reminds me how much I appreciate Mint dropping everything snap.
Except the graphical installer, which is bizarrely still a snap
Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
21–29 of 29 posts
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#22Basically following the path that same other OSes are trailing in security, Windows, macOS, mobile, container-based immutable infrastruture.
Also a reminder that when OEMs ship Linux distros, it is always customised.
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#23the tpm model is silly and always has been. if you need encryption why would you care if the cpu or motherboard is the same?
the threat model does not make sense. especially in the past when it was i2c
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#24Earlier quoted context omitted.
The point is that you don't have a separate password just for the disk encryption. It all works transparently.
How often do you reboot your laptop anyway? It takes a couple seconds to type in a well-rehearsed passphrase. When I reboot mine it's actually three passwords that I need to put in: disk encryption, linux login, and firefox master key.
i so wish the firefox master key was better implemented. they need at least a dont remind me for x minutes option.
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#25Earlier quoted context omitted.
Far better to just use the raw tools and manage it yourself ala arch wiki: https://wiki.archlinux.org/title/Trusted_Platform_Module#PCR...
The problem with manuals like that is they are like commercial flight checklists, except in most cases the user is not a professional pilot.
Skill issue
Jokes aside, I agree on the sense that this should be a solved problem. On the other hand, if the only implementation is a broken one, there's only one way to help yourself, and that is learning how to do it and helping yourself
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#26holy hell! snap-based kernel 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 t…
The point is that you don't have a separate password just for the disk encryption. It all works transparently.
The downside is after all that, is you end up with an running Ubuntu system, and you realise you're running a shitty NIH Debian fork.
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#27the tpm model is silly and always has been. if you need encryption why would you care if the cpu or motherboard is the same? the threat model does not make sense. especially in the past when it was i2c
Re: Ubuntu's TPM encryption switches to snap kernel that blocks deb kernel packages
#28Earlier quoted context omitted.
no, I mean the attacker boots his own copy of Windows or Ubuntu, which is supposedly trusted by the UEFI keys. Will tpm somehow detect that it shouldn't unlock secrets for this boot?
Yes. The PCR state after booting won't match that of the regular system, so the TPM will refuse to give up the key.
This is contingent on the sealing policy including PCRs that would change as a result of booting a different operating system, like PCR 11, which, when booting a UKI, contains those measurements. Only sealing against PCR 7 would allow this attack, since the default platform secure boot policy would not need to change.