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

[Stef Walter]

On 09.08.2013 17:44, Lennart Poettering wrote:
> On Thu, 08.08.13 12:15, Stef Walter (stefw at 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