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

[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 (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.

Actually, as I sent this, I realized it doesn't cover the 'multiple
disks encrypted with same password' use case.

Stef