Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User bus breaks kernel "session" keyrings #1299

Closed
grawity opened this issue Sep 18, 2015 · 4 comments
Closed

User bus breaks kernel "session" keyrings #1299

grawity opened this issue Sep 18, 2015 · 4 comments

Comments

@grawity
Copy link
Contributor

grawity commented Sep 18, 2015

#1232 reminded me of an issue with the user bus model and kernel keyrings. It is similar to the problem with environment variables, but seems a bit harder to work around.

In short: Bus-activated apps cannot access credentials (e.g. SMB passwords) from the session keyring, as they belong to a different session.

  • In the past, gdm would first log me in, open a PAM session (invoking pam_keyinit to create a session keyring), and then launch the dbus-daemon instance for that session. All my programs, whether directly launched or bus-activated, would hold the same session keyring.

  • Now dbus-daemon is launched by systemd --user and holds a different session keyring (obtained through its own PAM stack). So any credentials seen by regular session programs are not seen by bus-activated programs, and vice versa.

    (For example, if I use pam_cifscreds to add my login password as a SMB password, it works fine from an xterm (spawned directly by WM), but not from gnome-terminal (bus-activated).

[I guess this is not exactly new, as tmux and urxvtd would also have the same problem... but these are explicit, whereas the user bus is set up without the user's knowledge.]

@poettering
Copy link
Member

you are referring the kernel keyring here? I figure the lesson is that a concept of a "session" keyring is just crazy, and nobody should use them...

@kaysievers
Copy link
Contributor

Right, separating sessions from each other makes no sense security-wise on any usual workstation setup. Tools should switch to user-owned data instead of session-speficic data. The concept of sessions is not meant to carry any credentials or other data, it is only the user who owns everything.

CIFS:
https://git.samba.org/?p=cifs-utils.git;a=blob;f=pam_cifscreds.c
uses:
KEY_SPEC_USER_SESSION_KEYRING (UID-session keyring)
while it should probably switch to:
KEY_SPEC_USER_KEYRING (UID-specific keyring)

@poettering
Copy link
Member

I am tempted to simply close this issue here. I really think that keys should be shared among sessions of the same user, and hence should be attached to the user, and not any session... I think this is something to fix in samba, not in systemd...

@kousu
Copy link

kousu commented Aug 16, 2022

For the sake of searchers like me who stumble on this thread, I've written a patch that implements

keys should be shared among sessions of the same user, and hence should be attached to the user

for SMB passwords at https://www.spinics.net/lists/linux-cifs/msg25901.html

It's incomplete since it only touches the userland so far, and since I don't know if the SMB maintainers have any interest in it. But it's out there. Maybe if you run into this like I did you can build on it to get a working solution. Or maybe I'll finish it one day, get my hands dirty in the kernel, but I've never done that and I'm not promising it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants