Re: keyrings and dbus

[Josef Moellers <jmoellers@xxxxxxx>]

On 12.06.19 17:34, Andrei Borzenkov wrote:
> 11.06.2019 15:32, Josef Moellers пишет:
>> On 11.06.19 13:27, Mantas Mikulėnas  wrote:
>>> On Tue, Jun 11, 2019 at 1:58 PM Josef Moellers <jmoellers@xxxxxxx
>>
>>>     The point is that in the gnome-terminal case, pam_keyinit.so is not
>>>     involved.
>>>
>>>
>>> It is. The systemd --user instance (from which dbus-daemon and
>>> gnome-terminal-server descend) has its own PAM stack and can call
>>> pam_keyinit.so if needed.
>>
>> Strange thing is, that it already does!
>>
>> /etc/pam.d/systemd-user:
>> session  optional       pam_keyinit.so force revoke
>>
> 
> I checked on vanilla Tumbleweed VM and systemd-user does not have
> pam_keyinit.

I stand corrected: I added it as part of checking whether that would
help ... which it doesn't.

> And yes, I observe exactly the same behavior you described.
> Unfortunately things are more complicated:
> 
> bor@10:~> cat /proc/keys
> 12cf2039 I--Q---    93 perm 3f030000  1000   100 keyring   _ses: 1
> 32af49bd I--Q---     1 perm 1f3f0000  1000 65534 keyring   _uid.1000: empty
> bor@10:~> keyctl show -x
> Session Keyring
> 0x0e2f1b64 --alswrv   1000 65534  keyring: _uid_ses.1000
> 0x32af49bd --alswrv   1000 65534   \_ keyring: _uid.1000
> bor@10:~>
> 
> 
> So there is user session keyring, but gnome-terminal (and any process
> spawned by it) are not attached to it.
> 
> If I add pam_keyinit to systemd-user, I do get session keyring for gnome
> terminal, but this is really wrong one:
> 
> bor@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@10:~> keyctl show -x
> Session Keyring
> 0x2aeff9b2 --alswrv   1000   100  keyring: _ses
> 0x2133e406 --alswrv   1000 65534   \_ keyring: _uid.1000
> bor@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":

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.

> so now there are two session keyrings, some of processes (that for all
> practical purposes *do* belong to the same user session) are attached to
> one keyring, some to the other. Which makes it impossible to actually
> use session keyring to share keys.

If keys are attached to the "user keyring", then, indeed, they can (and
will) be shared as shown above!

> 
> The first session keyring is created by gdm in this case (specifically
> gdm-autologin), second - by systemd-user.

What puzzles me at the moment is that I tried to reproduce this issue on
my Leap 15.1 VM and IT DOES NOT REPRODUCE ANY MORE:

josef@linux-7gwm:~> grep . xterm gnome-terminal
xterm:Session Keyring
xterm:0x1d40e70e --alswrv   1000   100  keyring: _ses
xterm:0x333d487a --alswrv   1000 65534   \_ keyring: _uid.1000
gnome-terminal:Session Keyring
gnome-terminal:0x3f058f6f --alswrv   1000   100  keyring: _ses
gnome-terminal:0x333d487a --alswrv   1000 65534   \_ keyring: _uid.1000

Both isnatances have, at the top, a "session keyring" and none has a
"user session keyring".

This is due to the pam_keyring invocation I added to
/etc/pam.d/systemd-user. When I remove that line (eg by commenting it
out), a "user session keyring" is created instead of the "session keyring":

josef@linux-7gwm:~> keyctl show -x
Session Keyring
0x3ba37617 --alswrv   1000 65534  keyring: _uid_ses.1000
0x0c90f0bf --alswrv   1000 65534   \_ keyring: _uid.1000

It appears as if the "systemd --user" caches the contents of the
"/etc/pam.d/systemd-user" file or maybe even runs through it only once
upon startup (of systemd --user).

you wouldn't know, perchance, if there are any other processes started
by the "systemd --user" instance of my user?

TL;DR
The addition of "session optional pam_keyinit.so force revoke" to
/etc/pam.d/systemd-user seems to fix my problem. The only question which
remains is if this has any adverse consequences.

Josef

Josef
-- 
SUSE Linux GmbH
Maxfeldstrasse 5
90409 Nuernberg
Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel