pid_eins

pid_eins, 22 days ago

… maybe not quite as popular as docker, but it conquered many other areas, for example build systems and more.

There's one facet nspwan is particularly good at: we use it to showcase new integration features between the host systemd and containers. nspawn for example natively supports propagating credentials down to its payload, or supports sd_notify() ready notfications for the service manager in the payload. It allows binding a host user into the container via --bind-user=, or…

pid_eins, 22 days ago

… authenticated OS images via dm-verity/DDI and there's so much more.

Now, I personally use nspawn daily, for developing systemd, testing integration and many other aspects and a lot more. But sometimes it's not enough for my work. For example, because nspawn directly transitions into the service manager it doesn't go through an initrd, so it cannot be used for test an initrd, even though that's a crucial part of developing an OS.

pid_eins, 22 days ago

It also doesn't bother with a boot loader, since containers after all share the same kernel, there's no boot loader involved anymore. But in systemd we have sd-boot after all, which is a modern boot loader with many security features we need to work with. Per-container TPMs are also not really a thing.

Hence, in a recent systemd version we added systemd-vmspawn. It's a small wrapper around qemu, which has the point of making it as nice and simple to use qemu as it is to use nspawn.

pid_eins, 23 days ago

… to classic passwords and recovery keys) for unlocking the home directories.

Home directories maintained by systemd-homed come at a much higher security level than traditional home directories. Most importantly: you cryptographically unlock your home dir at the moment of login, and unless you logged in your home directory is entirely inaccessible because there's no decryption key available the system could decrypt it with.

An effect of this is that certain things that…

pid_eins, 23 days ago

…traditional UNIX systems allowed do not work on systemd-homed. For example, per-user cronjobs don't really work anymore as long as the user hasn't logged in, because they cannot access the user's home directory. More interestingly though SSH logins into locked home directories so far wasn't supported: ssh authentication works differently from traditional PAM based authentication after all: it entirely bypasses the Linux PAM auth stack (it does run the account and service stacks however)…

pid_eins, 23 days ago

… and instead does authentication via asymmetric key pairs, i.e. those things you traditionally maintain in your .ssh/ directory in the home directory.

And that's a problem for systemd: if systemd-homed cannot hook into the authentication mechanism, ask the user for a LUKS passphrase, or ask them to touch the FIDO2 key or enter its PIN, then it cannot automatically unlock your home directory when you log in via SSH. (If you already logged in before locally, then SSH would work).

pid_eins, 23 days ago

So, what's new regarding this problem in v256? Well, it works now: you finally can log in via SSH directly into your super secure systemd-homed account.

How did we make this happen? Roughly like this: first, we let SSH do its authentication. If that succeeded then we permit the log in to go though, but temporarily provide a slightly different user record for the user, where the login shell in the record is redirected to a small stub tool provided by systemd.

pid_eins, 23 days ago

This stub tool has only one job: ask the user interactively for the unlock password/PIN/touch/… and then execve() the actual user's shell.

Or in other words: one ssh allows a login to go through you'll end up in something that behaves a lot like a shell, but ensures the home directory is unlocked first, before it passes control to the actual shell.

This little stub hence runs without any home dir accessible, but under the user's identity. It's job is to make the home dir accessible, and…

pid_eins, 23 days ago

… then get out of the way, and let the real shell take over.

Howe does this feel from the client side? Basically if you "ssh" into a host like that, the regular SSH authentication takes place. If this succeeds there are now two options:

1. if the home dir alreads has been unlocked, you get the shell directly as on classic UNIX systems.

2. if the home dir as not been unlocked yet, you get a quick prompt to do so, and once that succeeded you get your shell.

pid_eins, 23 days ago

That's the gist of it at least. It's a bit more involved IRL.

Anyway, that's all for today, let's see if I can keep this up and post installment #9 soon.

pid_eins, 23 days ago

@jamesh @Hikari It uses PAM for the session setup and to see if the account is valid. It doesn't use it for authentication (unless you allow password auth, which you hopefully don't) though, and that's the problem we have to deal with in systemd-homed. What's worse, the account and session PAM stacks that SSH runs have a NULL conversation function installed, and hence cannot ask questions either.

pid_eins, 23 days ago

@jamesh For this my focus was on encrypted home dirs of course. I made sure the stub shell is skipped when the home dir is already unlocked. If this isn't skipped on --storage=directory currently then I would consider that a bug, but I must admit I didn't test that combination recently.

pid_eins, 23 days ago

@enkiusz in a systemd-homed world the SSH public key is part of the user record btw, precisely to have it around without having to unlock the home dir.

The bigger problem with ssh logins really was the fact that to unlock the home dir we need the decryption key, and ssh doesn't really make it easy for us to ask for it, hence the little stub shell thing we came up with.

pid_eins, 23 days ago

@simo5 @enkiusz so the operation ssh-agent does for auth is signing a nonce, and thats it. We could shoehorn this into an unlock scheme for disk encryption, but i am not sure this is so great: i.e. take a random value at enrollment time, let ssh-agent sign it with its ssh priv key and then (mis-)use the resulting signature as symmetric disk encryption key. Under the assumption that only the owner of the privkey can generate valid sigs and that sigs have no other inputs this should be safe.

pid_eins, 23 days ago

@simo5 @enkiusz except of course thats sigs are not stable/reproducible, for some key schemes they contain a random nonce, wher this would fall flat.

pid_eins, 23 days ago

@simo5 @enkiusz another idea would be to combine ssh-agent auth with a local tpm. I.e. encrypt the disk encryption key with some key stored in the tpm that it only reveals if a tpm generated nonce can be signed by the client.

This is similar to how chromeos does unlocking via fido2, where also the relevant key is released from the tpm to the os only if the fido2 key can answer a challenge from the tpm.

pid_eins, 23 days ago

@getajobmike i pinned some of them now. But it refuses to let me pin more, hence I figure this is where it ends. Sorry.

pid_eins, 23 days ago

@stebalien if it makes you feel better, we actually always check PK, regardless if the image's signing key is in the kernel keyring or not. we just use different PK action names however.

pid_eins, 23 days ago

@mdione The parent/child relationship of processes across sudo is a problem too, because parents actually do have certain elevated privs over their children even if they run under a different UID. Hence this is actually also something I think we shouldn't do for a tool like run0/sudo: it's a good thing if we break up that parent/child relationship.

pid_eins, 23 days ago

@juliank @mattdm Yeah, something like that might work, but I'd probably not overmount /tmp/ but something else that is private to such a tool, and then direct the editor there.

pid_eins, 23 days ago

@mdione the parent/child relationship is not really about the ability to present a nice tree to users in "ps" output. It implies privileges, and runtime supervision, and that's something I think is better broken up when privs are properly elevated.

pid_eins, 23 days ago

@juliank @mattdm /run/user/1000 is guaranteed to be a private per-user tmpfs that goes away when you log out. That sounds quite OK to me.

But dunno, the way I see it, if your editor places a copy of your potentially secret file in /tmp/ even though it has write access to the dir it is placed in then I think the editor is a bit icky, and shouldn't do that.

pid_eins, 23 days ago

@mdione we might look into that eventually, dunno. Right now the tools are semantically too different. Thus I wouldnt want to claim drop-in compat.