Re: [systemd-devel] Have 'session' keyrings per service

2013-08-09 Thread Zbigniew Jędrzejewski-Szmek
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


Re: [systemd-devel] Have 'session' keyrings per service

2013-08-09 Thread Lennart Poettering
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

2013-08-09 Thread Stef Walter
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

2013-08-09 Thread Stef Walter
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