[systemd-devel] keyrings and dbus

[Josef Moellers]

On 13.06.19 12:18, Andrei Borzenkov wrote:
> 13.06.2019 11:11, Josef Moellers пишет:
>> On 12.06.19 17:34, Andrei Borzenkov wrote:
> ...
>>>
>>> If I add pam_keyinit to systemd-user, I do get session keyring for gnome
>>> terminal, but this is really wrong one:
>>>
>>> bor at 10:~> cat /proc/keys
>>> 2133e406 I--Q---     2 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
>>> 2aeff9b2 I--Q---    67 perm 3f030000  1000   100 keyring   _ses: 1
>>> 3c18175c I--Q---    93 perm 3f030000  1000   100 keyring   _ses: 1
>>> bor at 10:~> keyctl show -x
>>> Session Keyring
>>> 0x2aeff9b2 --alswrv   1000   100  keyring: _ses
>>> 0x2133e406 --alswrv   1000 65534   \_ keyring: _uid.1000
>>> bor at 10:~>
>>
>> Not really ... if you look at the keyring IDs (in the first column) eg
>> in a gnome-terminal and in an xterm, you will see that both session
>> keyrings (the "session keyring" in the xterm and the "user session
>> keyring" in the gnome-terminal) link to the very same "user keyring":
>>
> 
> I did not say "user keyring", I said "session keyring". Session keyring
> is different.
> 
> bor at 10:~> keyctl show -x
> Session Keyring
> 0x21a25f31 --alswrv   1000 65534  keyring: _uid_ses.1000
> 0x25f5781a --alswrv   1000 65534   \_ keyring: _uid.1000
> bor at 10:~>
> 
> bor at 10:~> keyctl show -x
> Session Keyring
> 0x279c03fc --alswrv   1000   100  keyring: _ses
> 0x25f5781a --alswrv   1000 65534   \_ keyring: _uid.1000
> bor at 10:~>

I know that. I'm still a bit unsure about how exactly these keyrings
will be used, especially how and where keys are added (they are
retrieved by searching for their description/name).

AAMOF If I log in through eg GDM or KDM or SDDM, then I get a fresh, new
session keyring to which the user keyring is linked. When I then log in
through ssh, I get a fresh, new session keyring, different from the
above, to which the user keyring (identical to the above) is linked.
The session keyrings ("_ses", the first one is a "user session keyring",
named "_uid_ses.1000") differ, but the user keyrings ("_uid.1000") are
identical.

>> Leap-15.1:
>> ssh:
>> Keyring
>>   69871887 --alswrv   1000   100  keyring: _ses
>>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
>> -> Session Keyring (_ses) linked to User Keyring (_uid.<UID>)
>>
>> gnome-terminal(-server):
>> Keyring
>>  219457014 --alswrv   1000 65534  keyring: _uid_ses.1000
>>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
>> -> User Session Keyring (_uid_ses.<UID>) linked to User Keyring (_uid.<UID>)
>>    User Keyring is identical with User Keyring in ssh
>>
>> xterm:
>> Keyring
>>  633373159 --alswrv   1000   100  keyring: _ses
>>  105956722 --alswrv   1000 65534   \_ keyring: _uid.1000
>>
>> All three share the same "user keyring" with ID 105956722!
>> This is the single keyring the kernel maintains for the user ID 1000.
>>
> 
> Your question was about session keyring, not about user keyring.

That's correct, so let's just leave the user keyrings aside, they are
identical up to the ID in all cases: only a single user keyring exists.

>>
>> TL;DR
>> The addition of "session optional pam_keyinit.so force revoke" to
>> /etc/pam.d/systemd-user seems to fix my problem.
> 
> At this point I lost track what problem you solve. You still have two
> processes in user login session (graphical environment) that attach
> different session keyring.
> 
> To quote:
> 
> "We have seen this problem: when you open a gnome-terminal, then the
> shell in that terminal will not have the same keyring (created by
> pam_keyinit.so) as the one eg in an xterm.">
> Adding pam_keyring.so to systemd-user pam configuration does *not* fix
> it in any way.

That is correct. I was under the assumption that when I log into GNOME,
gdm obtains a session keyring ("_ses") This session keyring is then
passed on (recursively) to any process which is a descendant of that
gdm. So I would have expected that every process running within the
GNOME instance (I avoid the word "session" here) would have this session
keyring. So we were quite surprised to see that the shell inside the
gnome-terminal-server didn't. This, as we know now, is a consequence of
the fact that when you run "gnome-terminal", it doesn't fork/exec
gnome-terminal-server itself but it sends a message to systemd--user
instead which then instantiates (fork/exec?) the gnome-terminal-server.
This leads to the shell in gnome-terminal-server to have an unrelated
keyring (of some kind).
It turns out that gnome-terminal-server does not even have a keyring at
all (at least in our SUSE version of systemd) so that's why we see a
"user session keyring" rather than a "session keyring". I understand
that the upstream systemd adds a "session keyring" to each service
started by systemd--user.

Adding pam_keyring.so to systemd-user pam configuration fixes this only
so far in that gnome-terminal-server (and the bash) then have a "session
keyring".

I have had a longer internal discussion with our systemd-maintainer and
in that discussion it appeared that neither systemd--user nor
gnome-terminal-server have a way of subscribing to gdm's "session
keyring", so as long as the starting of gnome-terminal-server happens
unrelated from gdm, then this has to be accepted.


> 
>> The only question which
>> remains is if this has any adverse consequences.
>>
> 
> You cannot use session keyring to share keys between processes that user
> thinks as belonging to the same (login) session.

ACK.
You CAN use the "user keyring" which is attached to the session keyring,
though, as this is unique. But then, we didn't want to talk about those ;-)

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)