Lennart: Linux Comes Up Short Around Disk Encryption, Authenticated Boot Security

[RahulSundaram]

I agree, that's a good point. It's like saying C is inherently unsafe and dangerous. Yes, that's why a skilled programmer needs to write C code. Doesn't make the language bad, just means you need to take care.

No, that hasn't worked as a strategy to deal with the problem. Even the largest tech companies are moving away from C (and to some extend C++) precisely because they need better tooling. Just recently, this got published

https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html

[mdedetrich]

I agree, that's a good point. It's like saying C is inherently unsafe and dangerous. Yes, that's why a skilled programmer needs to write C code. Doesn't make the language bad, just means you need to take care.

Actually it means both, these things aren't mutually exclusive

[perpetually high]

RahulSundaram mdedetrich

Fair, both good points. But it's worked for the time it needed to work. It's all about evolving. I trust Linus and his direction on Linux. It really comes down to that. I completely and 100% understand why C is used, and I understand why they want to move away from C. Both can also be true here as well.

edit: I also, am *heavily* against knee-jerk reactions and everyone wanting to change eveything cause some fany new girl (rust) came along with a short dress. Shitty analogy, but Linus wasn't born yesterday. Slow and steady

You guys like rust, great, prove it, show why it works, show the driver can work in harmony with the current C implemention, show that it can be maintained, tested, QA'd, all of it. Otherwise, not interested. Save the better "language" for another project and that it can withstand decades of maintainance.

[RahulSundaram]

RahulSundaram mdedetrich

Fair, both good points. But it's worked for the time it needed to work. It's all about evolving. I trust Linus and his direction on Linux. It really comes down to that. I completely and 100% understand why C is used, and I understand why they want to move away from C. Both can also be true here as well.

Just to be clear, this specific discussion has nothing to do with the Linux kernel or Rust in particular. Lennart isn't talking about that either.

[perpetually high]

Just to be clear, this specific discussion has nothing to do with the Linux kernel or Rust in particular. Lennart isn't talking about that either.

Good call out. I don't know where I took rust from and why I took it there. Thanks.

I think it was just a general feel I'm getting from the forums and people being so quick for change. Change takes time.

Linux is just a kernel. MacOS and Windows are full on out-of-the-box Operating Systems. Just hardly an apples to apples comparison.

We never talk about Linux in the context of Darwin and NT kernel but maybe we should.

edit: Btw, people can take lessons from Rahul on how to communicate without being a jerk. Thank you, btw. As opposed to Turbine that wants to tell people to "Use your brain." Those kinds of weak attacks need to stop. Lot of smart people on Phoronix if we stop the bs name-calling and attacks.

[bob l'eponge]

The main attack described in his article is mostly moot. Unless your laptop is powered on, unlocked, and you're logged in. In that case, none of the solution he's describing would work, since the attacker has full R/W access to your data (whatever the boot protection you've set up). If your laptop is powered off, making a copy of the hard drive will not be harder with his method, nor will be the deciphering of the drive (the keys are different, but the encryption method is the same, so it's the exact same difficulty to crack if you need to find the TPM key or your PKCS derived key). And for appending malicious software to your harddrive, there is nothing that prevent the "security team" to sign and encrypt their /usr officially and copy it to your hard drive offline. You're unlikely to figure out the hash have changed since they are changing anyway upon system software upgrades.

If your laptop is sleeping (thus you're logged out), it's not possible to remove the drive without powering it down (or crashing it, but you'll notice). So the only possible attack would be to break the login prompt password challenge after waking it up. His solution does not change anything to this anyway.

So in the end, his criticism is based on an hypothetical "security magic spell" that would be able to add a software on your encrypted drive without you noticing, and I don't see any way this can be done (currently) except via a TPM backdoor, the only thing he's praising for.

In the end, his solution is bad for 3 more reasons:
1. If your motherboard dies or you want to reuse your disk elsewhere, your data is inaccessible. Sure, you can set up your HDE's key to be a Shamir's key combination of TPM+password+RecoveryKey, with any 2 of them required to unlock it, but in that case, a "security team" will only need to find the recovery key to unlock your drive (because they already have the TPM's secret key...).
2. If your harddrive starts to fail, you'll likely loose everything. Since more HDE with authentication are **build** to fail when corruption to the data occurs, it's exactly what will happen. Without encryption, you'll be able to, at least, recover non corrupted area. So his solution makes your system less reliable for no real added security.
3. Complexity my friend... His solution requires every block to perfectly fit with the next one to work. If one block doesn't fit perfectly (for example after an upgrade), your system is gone and good luck recovering it...

He has good ideas however concerning encrypted home folder/volume, and I think it's the only layer that need encryption, not the full disk. If you need to hide something, run it in a docker on your home folder, or a snap or an appimage, whatever. A true security measure would be to have every encrypted executable on your system signed with some private key and only tested with a public key by the kernel before running them if they match. I don't know if such system exists however.

[Ipkh]

I like the proposal.
It's a shame that Linux doesn't take advantage of the TPM and advanced features of UEFI and Secure Boot. zit seems like once they got a basic booting infrastructure around the shim, no one thought to go keep going and use the remaining security features.

[RahulSundaram]

Good call out. I don't know where I took rust from and why I took it there. Thanks.

I think it was just a general feel I'm getting from the forums and people being so quick for change. Change takes time.

Linux is just a kernel. Mac and Windows are full on out-of-the-box Operating Systems. Just hardly an apples to apples comparison.

We never talk about Linux in the context of Darwin and NT kernel but maybe we should.

You are welcome. As to forum discussions, most forum posters have nothing to do with upstream development and the development that happens in various projects isn't any way influenced or shaped by random people who post in a forum. Every major change does take more time and is much more involved than people seem to realize and the reason why we don't talk about Darwin or NT kernel as much is because a) this forum is more Linux focused b) we don't have as much transparency around what's happening in other kernels so there isn't much for the peanut gallery to whine about. What would definitely help is, if people paused and did some basic reading on a topic before commenting on it thoughtfully instead of a quick knee-jerk reaction to everything but I don't dare hope for that.

[perpetually high]

You are welcome. As to forum discussions, most forum posters have nothing to do with upstream development and the development that happens in various projects isn't any way influenced or shaped by random people who post in a forum. Every major change does take more time and is much more involved than people seem to realize and the reason why we don't talk about Darwin or NT kernel as much is because a) this forum is more Linux focused b) we don't have as much transparency around what's happening in other kernels so there isn't much for the peanut gallery to whine about. What would definitely help is, if people paused and did some basic reading on a topic before commenting on it thoughtfully instead of a quick knee-jerk reaction to everything but I don't dare hope for that.

Well said. And to be honest, it's something we're all guilty of. We're *all* hypocrites. Except some are terribly more hyprocritcal and just flat out lack integrity and a backbone.

Anyways, I enjoyed your posts. Thanks.

One last thing: I meant Darwin/NT kernels in *comparison* to Linux, not so much standalone speaking of them. Though, I think Michael does a good job of bringing it up when he feels it is relevant to Linux or something Linux could do better.

The beauty of Linux and open-source, if we all tackle a little part, we can make the whole thing incrementally better, and as a result, even better the sum of all its parts. But not if people just whine and expect everything on a silver platter. Have zero tolerance for that.

[kiffmet]

A few weeks ago I've been looking into how to add secure boot and some form of tamper protection to my Gentoo installation out of curiosity. I came to the conclusion that currently it's just not worth it, as too much manual labor is required. What's needed is the tooling to make enrolling/maintaining such a configuration less of a pain.

I'd need a program/bootloader that encrypts the /boot partition and unlocks it only when the TPM gives an OK (inc. support for a "recovery password" or another HW key), then have the kernel, modules, initrd, kernel cmdline, and bootloader signed with my own keys for utilizing SecureBoot, aswell as automatically enroll that key into the UEFI keystore. Further, during system bootup, the root partition would only be unlocked two-factor-authentication style: First the TPM needs to give an OK and then it would ask for a password/keyfile/a YubiKey, a combination of these, or whatever.

I'd really appreciate it if setting this up and maintaining it (i.e. after kernel/software updates) could be as simple as editing a single config file and launching a bash script/program as root afterwards, preferrably with some hook to integrate it into package management. Otherwise, being paranoid is just too much of a hassle IMO :P