Live data from Hacker News

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

0pointer.net

21–30 of 102 posts

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

#21
post #9

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

The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?

> platform-specific commands into a single, consistent interface

Consistent interface that only works on one platform and uses all the platform specific commands imaginable to do things that have no reason to be platform specific. And it doesn't even play well with other parts of that same platform.

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

#22
post #9

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

The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?

[deleted]

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

#24
post #16

Earlier quoted context omitted.

Systemd is here to stay at this point. It's not ideal(I much preferred sysV, and then preferred upstart...and so on), but it's what we have. It's also improved greatly from the initial state we received it in. What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gav…

Not to derail, but I've mostly gotten to just living with it. I feel like it was mostly a missed opportunity to do things better; the declarative unit stuff is both over and underspecified, and for anything nontrivial, I always end up with sidecar scripts, anyway, which makes the whole thing just a game of useless boilerplate. And then it started attempting to assimilate other daemons... Like I said, it is what it is…

Yeah this is my exact sentiment. It took a lot easy things and made them require more boilerplate overhead. I'm sure its great for some use cases, but I've never encountered them. I actually like the idea of having a more consistent way to administrate the system, and for some thing systemd does great. But it also involved a lot of real head-scratcher decisions. (What problem was binary log files trying to solve?)

And screw unit files. Is there a helper utility to write and place the unit files for me? That would make me actually shutup about systemd.

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

#25
I am confused at which stage this is happening.

Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk?

AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting.

Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this?

EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.

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

#26
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.

What's the problem though? systemd is included in quite a few initramfs so nothing inherently has changed here.

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

#27
post #25

I am confused at which stage this is happening. Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk? AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting. Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this…

Initramfs I believe. `systemd-cryptenrol` would probably just be a binary like any other and wrap `cryptsetup` which is on your initramfs.

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

#28

Unrelated to unlocking devices...but LUKS is a really nice piece of software for linux. You throw any block device(real or otherwise) to it, and you get a /dev/mapper/ volume that transparently encrypts anything written to it. Other than encrypting my local workstations, you can also use it on VMs from linode/digitalocean/aws/gcp/etc. If you store all your sensitive data beneath /home for example, you can boot the in…

You can even setup SSH to the bootloader to unlock LUKS if it reboots.

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

#29
post #13

As someone that leaned pretty hard into using a Yubikey 5 for GPG/SSH keys over the past year, I am looking forward to giving this a try on my Fedora workstations. If you are interested in a fantastic walk through of using a Yubikey with your GPG/SSH keys check out https://github.com/drduh/YubiKey-Guide I am also really looking forward to the YubiKey Bio getting released too.

If you just want ssh it's even easier to use u2f/fido now since it's built into openssh.

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

#30
post #9

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

The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?

I tinker on my gentoo box and OpenRC is more than capable of everything it needs to do. I don't understand why people's linux fill up with "trial and error custom shell scripts".

Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.

Post reply on HN