On 10.08.2013 07:22, Stef Walter wrote: > On 09.08.2013 17:44, Lennart Poettering wrote: >> On Thu, 08.08.13 12:15, Stef Walter (st...@redhat.com) wrote: >> >>> Hey guys. I'm trying to figure out details for: >>> >>> http://www.freedesktop.org/wiki/Specifications/login-unlock/ >>> >>> Lennart we talked about this briefly in Brno ... basically the concept >>> is that when systemd does cryptsetup, it'll stash away the password it >>> successfully used in the kernel keyring, and then the PAM stack in GDM >>> will use it to try and log the user in. >>> >>> One thing we should work out is how to avoid having any uid 0 process >>> accessing that password at will. By: >>> >>> 1. Obviously, a kernel keyring timeout. >>> 2. Putting it in a keyring that only certain services have access to. >> >> Hmm, well, what's the point of this part? I mean, on Unix security is >> either bound to UIDs/GIDs, or to MAC labels, we shouldn't attempt to >> introduce half-assed security checks beyond that... > > Fair point. That makes some sense... > > I mean, ptrace() >> allows you to impersonate anybody you like if that someone has the same >> UID you have, so what's the point of doing per-session or per-service >> access control? >> >> I'd just stick this into the keyring of UID 0 with a timeout of 2min or >> so, and that'd be it. > > ... but your conclusion is wrong. It's pretty obvious that a UID 0 > process like openvpn shouldn't be able to get at the user's disk > encryption password (even if it is only for 2 minutes after boot). > > So we should be relying on MAC at the very least. > > But perhaps we should be hashing the password before storage in the > kernel keyring. Hashing with the various forms of crypt + a strong > pbkdf2 hash actually covers the various ways the password would be used.
Actually, as I sent this, I realized it doesn't cover the 'multiple disks encrypted with same password' use case. Stef _______________________________________________ systemd-devel mailing list firstname.lastname@example.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel