Re: [systemd-devel] Have 'session' keyrings per service
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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have 'session' keyrings per service
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. Remember the goal we're trying to acheive. If cryptsetup and gdm (well its pam stack) were running at the same time we'd set this up so it just passed the password over directly, and not stored somewhere all UID 0 processes could access it (ie: essentially broadcast). However there is a temporal gap between the two, and thus the kernel keyring becomes a transfer mechanism. With something like the disk encryption password, it's worth adding another layer that needs to be broken before the raw password is exposed. Will research pre-hashing further. Cheers, Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have 'session' keyrings per service
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... 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. > The second is why I'm writing... > > I'm thinking about the idea of defining a named session keyring per > systemd unit (kernel 'session keyrings' have nothing to do with user > login sessions, overloaded term, :S ). What's the point really? what would this provide us with that labeling keys would not do anyway? > On its own this makes a lot of sense, since we essentially make a > per-cgroup keyring for services, which becomes really useful. It sounds very wrong to me to introduce a new concept of access control here on the lower level. We try hard to map everything back to UID/GID+label, for example in the journal, where we break up the journal into individual files so we can reuse fs access control... My simplistic approach for all of this would look like this: a) rip out all plymouth-based password caching logic from systemd b) instead, cache all keys we read from the kbd in the kernel keyring for UID 0 with an expiry of 2min or so. c) Add a tiny PAM module to systemd that can provide the cached keys (or one of them) as PAM auth tok. Then, add the latter to the gdm autologin PAM config snippet. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have 'session' keyrings per service
On Thu, Aug 08, 2013 at 12:15:59PM +0200, Stef Walter wrote: > So perhaps cryptsetup would put the password in its own named keyring, > and then gdm.service would have: > > [Service] > Keyrings=@cryptsetup > > Which tells systemd to link the cryptsetup keyring into the gdm > (session) keyring. That makes gdm be able to find and use keys in the > cryptsetup keyring. > > I think I've figured out a way to implement the above. But anyone > already thought about this? Other use cases? Sounds pretty cool. If you can get this working with this approach that would be great. If there are any limitations, they should become apparent after the first implementation. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Have 'session' keyrings per service
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. The second is why I'm writing... I'm thinking about the idea of defining a named session keyring per systemd unit (kernel 'session keyrings' have nothing to do with user login sessions, overloaded term, :S ). On its own this makes a lot of sense, since we essentially make a per-cgroup keyring for services, which becomes really useful. Then also have the ability to in a .service file to define additional named keyrings that are searchable for the service. So perhaps cryptsetup would put the password in its own named keyring, and then gdm.service would have: [Service] Keyrings=@cryptsetup Which tells systemd to link the cryptsetup keyring into the gdm (session) keyring. That makes gdm be able to find and use keys in the cryptsetup keyring. I think I've figured out a way to implement the above. But anyone already thought about this? Other use cases? Cheers, Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
