Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

0pointer.net

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#91

Post by vaduz »

mo2art wrote: post #89

How is this superior to clevis? https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... https://m.youtube.com/watch?v=Dk6ZuydQt9I

It enables you to use a token that is portable and removable, which TPM2 chips are not. This has an advantage that it can be carried and secured separately, even if the device has to go into insecure storage like a hotel safe. You need to trust your FIDO2/PKCS11 device to be secure, though.

Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not.

It's all about trade-offs and trust.

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#92

Post by guenthert »

inetknght wrote: post #17
westmeal wrote: post #9

Systemd is a horrific abomination at this point it just never ends...

I concur. Here, read my take on systemd: https://systemd.software/index.html

Can't get there using Chrome (v.69) on a Chromebook: "systemd.software uses an unsupported protocol. ERR_SSL_VERSION_OR_CIPHER_MISMATCH"

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#93

Post by guenthert »

iio7 wrote: post #47

I see absolutely no use for this what so ever. I wish systemd would just concentrate on being an init system rather than being a Swiss army knife! GRUB and cryptsetup handles unlocking just fine!

Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd.

In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd just because they can.

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#94

Post by noahbliss »

Hey all, as it was mentioned in the article, a significant remaining issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. Current distribution implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the integrity of the initramfs, which can be repacked to include malicious code that will execute during boot, potentially intercepting your LUKS key.

There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev

I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit.

https://github.com/noahbliss/mortar

https://safeboot.dev

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#95

Post by inetknght »

Arnavion wrote: post #75
inetknght wrote: post #38

Earlier quoted context omitted.

> "View > Page Style > No Page Style" Just turn on reader-mode in your browser. Or prefix the url with `about:reader?url=`. > that shortly thereafter redirects to the freedesktop.org site Specifically, it redirects to the systemd documentation part of the freedesktop.org site. There's also a bunch of other documentation redirects for the stuff I use. That's what index.html describes. Try finding the documentation onl…

>Try finding the documentation online to write a systemd service. Google finds tons of useless results [...] The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*` This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.

You have to know that you're looking for `systemd.service` in the first place.

If you search for `man service` you get linked to SysV init scripts [0] and are led astray if you don't know that sysv init scripts aren't systemd.

If you search for `man systemd` you get linked to a huge man page [1] which isn't approachable to a novice. There isn't an `EXAMPLE` section like there are on other man pages and searching for `example` doesn't reveal any commands to run. It doesn't describe where you can find an example service (unless you magically know that a "system unit" is a service and there's even a gotcha to that: it doesn't have a `files` section to describe where files are at (contrast with `man ssh_config` or `man nginx`) and it is absolutely not clear that the directory is hidden behind an obscure `pkg-config` invokation. Good luck discovering other services you can learn from by reading their service files!

If you managed to do `man systemctl` [2] you reach equally poor documentation. Again, no `files` section and this time not even a mention of `pkg-config`. There's a ton of mentions of environment variables (why does the _system_ need environment variables???). It describes how to "list" units but doesn't describe that it _won't_ list your user units (or, won't list the system units if you do --user). It doesn't describe how to _create_ a unit. It doesn't clearly walk you through the steps (again, there are no examples) so it's up to you to figure it out and hope you don't fuck up your system.

If you search for "just" `systemd`, you arrive at systemd.io [3]. Again, this site is not approachable to a novice! There's just lots and lots of reading. A _lot_ of reading. There's a few "examples" scattered everywhere in the form of an example command to run and a description of what it does. But _nowhere_ is there a single example with everything tied together into a single Hello World style solution.

[0] https://linux.die.net/man/8/service

[1] https://man7.org/linux/man-pages/man1/systemd.1.html

[2] https://man7.org/linux/man-pages/man1/systemctl.1.html

[3] https://systemd.io/

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#96

Post by nickik »

guenthert wrote: post #93
iio7 wrote: post #47

I see absolutely no use for this what so ever. I wish systemd would just concentrate on being an init system rather than being a Swiss army knife! GRUB and cryptsetup handles unlocking just fine!

Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd. In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd…

Grub is basically a second OS. People who say 'systemd is large and should just do one thing' and then say 'this can be solved with GRUB' blow my mind.

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#97

Post by nickik »

arianvanp wrote: post #88
mnd999 wrote: post #23

This means systemd needs to live on an unencrypted volume though, right? Seems like a bit of a weakness given how much systemd can actually do. I went with LUKS1 which grub can unlock.

systemd-boot measures the bootloader, initramfs, kernel and kernel-params state into the PCR registers of your TPM. SecureBoot state is also measured. You can configure through systemd-enroll to configure the TPM to only unlock the cryptokey if those measurements are consistent. If somebody changes your systemd binary in the initramfs; this causes the TPM PCR register to change; and will cause the system to not be ab…

Do you have a good tutorial for all these processes? This is something I thought would be awesome for a while, but there are a lot of moving parts. I also thought all the hardware was not yet support to do all of this.

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#98

Post by Arnavion »

inetknght wrote: post #95
Arnavion wrote: post #75

Earlier quoted context omitted.

>Try finding the documentation online to write a systemd service. Google finds tons of useless results [...] The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*` This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.

You have to know that you're looking for `systemd.service` in the first place. If you search for `man service` you get linked to SysV init scripts [0] and are led astray if you don't know that sysv init scripts aren't systemd. If you search for `man systemd` you get linked to a huge man page [1] which isn't approachable to a novice. There isn't an `EXAMPLE` section like there are on other man pages and searching for…

>You have to know that you're looking for `systemd.service` in the first place.

Yeah, because that's the thing you want help with.

No shit `man service` and `man systemd` aren't going to give you help for systemd services that easily.

Also, apparently you assume the user is simultaneously stupid enough to not put "systemd" and "service" in the same search query, but is meant to know to visit `https://systemd.software/service` even though it too contains both those words.

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#99

Post by guenthert »

nickik wrote: post #96
guenthert wrote: post #93

Earlier quoted context omitted.

Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd. In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd…

Grub is basically a second OS. People who say 'systemd is large and should just do one thing' and then say 'this can be solved with GRUB' blow my mind.

Sorry, didn't mean to promote grub, which sure has its own issues.

If the boot-loader is meant to decrypt the root fs however, it won't be trivial and GRUB might be the best bet. At least it isn't listening on network ports ...

Re: Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

#100

Post by kdtsh »

unqueued wrote: post #72
kdtsh wrote: post #70

Earlier quoted context omitted.

I think dropbear is what sits under earlyssh. I'll look into dropbear-initramfs, if it's easier to work with than earlyssh that is a big plus in my book. edit: early-ssh is hosted at https://github.com/gheja/early-ssh . Not to knock early-ssh by saying it's difficult to work with too - it's a great piece of software which has made my life a lot easier.

If you like early-ssh, I would like to suggest checking out better-initramfs. No dependency on systemd, easy to modify and build. I think it can do everything early-ssh can do. I use it to boot a variety of LUKS encrypted btrfs machines. Disclosure: I'm a contributor. https://github.com/slashbeast/better-initramfs

Nice! Starred, will definitely keep that in mind, thanks a lot.
Post reply on HN