Re: systemd.exec(5) PAMName= with libselinux

[Dominick Grift <dominick.grift@defensec.nl>]

Dominick Grift <dominick.grift@defensec.nl> writes:

> Stephen Smalley <stephen.smalley.work@gmail.com> writes:
>
>> On Mon, Jul 21, 2025 at 4:53 AM Dominick Grift
>> <dominick.grift@defensec.nl> wrote:
>>>
>>>
>>> systemd has an identity directive called PAMName= which allows you to
>>> run a unit with a specified PAM stack. The issue here is that in this
>>> case the "session leader" is always systemd.
>>>
>>> Thus you get into issues with pam_selinux because since systemd is for
>>> example always associated with "init_t" you can't really specify log
>>> SELinux identity foo_u in with foo_r:foo_t:s0 if this PAM stack is used
>>> and log SELinux identity foo_u in with bar_r:bar_t:s0 if that PAM stack
>>> is used.
>>>
>>> This previously was not a big issue since this feature is pretty niche
>>> but with the advent of `run0` it became an issue since that relies on
>>> PAMName=
>>>
>>> The problem is that pam_selinux is often already used to start the
>>> systemd --user instance, for example:
>>>
>>> /etc/selinux/TYPE/contexts/users/foo_u (/etc/pam.d/systemd-user):
>>> system_r:init_t:s0 foo_r:foo_systemd_user_instance_t:s0
>>>
>>> So you can't add the following because it would conflict
>>>
>>> /etc/selinux/TYPE/contexts/user/foo_u (/etc/pam.d/run0):
>>> system_r:init_t:s0 foo_r:foo_shell_t:s0
>>>
>>> Ideas? Suggestions?
>>
>> I probably don't understand your question, but systemd --user
>> instances on my Fedora system are running in the user's context, not
>> in init_t. If you have two processes with the same context logging in
>> as the same user, then there isn't any way to distinguish and it is
>> unclear on what basis you would distinguish.

Here is a log from the pam_selinux pam_close_session issue:

kcinimod@nimbus ~ $ getenforce && id -Z && ls -alZ `tty`
Enforcing
wheel.id:wheel.role:user.subj:s0
crw-------. 1 kcinimod tty wheel.id:wheel.role:user.ptytermdev:s0 136, 8 Jul 23 21:12 /dev/pts/8
kcinimod@nimbus ~ $ run0
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start transient unit 'run-p655631-i655931.service'.
Authenticating as: kcinimod
Password: 
==== AUTHENTICATION COMPLETE ====
🦸 root@nimbus:/home/kcinimod# getenforce && id -Z && ls -alZ `tty`                                                                                                                            
Enforcing
sys.id:sys.role:sys.user.subj:s0
crw-------. 1 root tty sys.id:sys.role:sys.ptytermdev:s0 136, 10 Jul 23 21:13 /dev/pts/10
🦸 root@nimbus:/home/kcinimod# systemctl --user --machine=kcinimod@.host daemon-reload                                                                                                         
🦸 root@nimbus:/home/kcinimod# getenforce && id -Z && ls -alZ `tty`                                                                                                                            
Enforcing
sys.id:sys.role:sys.user.subj:s0
crw-------. 1 root tty wheel.id:wheel.role:user.ptytermdev:s0 136, 10 Jul 23 21:13 /dev/pts/10
🦸 root@nimbus:/home/kcinimod# journalctl --grep "pam_selinux\(login"                                                                                                                          
Jul 23 21:13:23 nimbus (sd-pam)[655719]: pam_selinux(login:session): Setting file context "sys.id:sys.role:sys.ptytermdev:s0" failed for /dev/pts/10: Operation not permitted
🦸 root@nimbus:/home/kcinimod# exit
logout
kcinimod@nimbus ~ $ getenforce && id -Z && ls -alZ `tty`
Enforcing
wheel.id:wheel.role:user.subj:s0
crw-------. 1 kcinimod tty wheel.id:wheel.role:user.ptytermdev:s0 136, 8 Jul 23 21:14 /dev/pts/8
kcinimod@nimbus ~ $

>
> Lets take refpolicy as a reference here.
>
> https://github.com/SELinuxProject/refpolicy/blob/main/config/appconfig-mcs/staff_u_default_contexts
>
> line one. Basically that causes pid1 to execute a systemd --user
> instance for staff_u users using pam_selinux and user@UID.service which
> has the PAMName= directive set to systemd-user (this tells systemd to
> use the /etc/pam.d/systemd-user pam configuration)
>
> systemd --user instances are very intrusive and one might not want to
> run it in the user login shell domain for this reason.
>
> The PAMName= directive can use used to run all kinds of things with a
> session. the `run0` functionality is one (PAMName=run0 ->
> /etc/pam.d/run0) but it could be anything. Simply use PAMName= in a
> service unit to tell systemd what PAM config to use.
>
> I am not very familiar with pam but one thing that came to my mind which
> i am sure is not very robust is to make the pam_selinux syntax a bit
> more "smarter" by using something similar to name-based type transition
> rules. For example to differentiate between PAMName=systemd-user and
> PAMName=run0:
>
> /etc/selinux/TYPE/contexts/users/staff_u
> system_r:init_t:s0 staff_r:user_systemd_t:s0 "systemd-user"
> system_r:init_t:s0 staff_r:staff_t:s0 "run0"
>
> So that we can some how tell the login program (systemd in this case)
> use the line that corresponds to the name of the pam config file
> (PAMName=)
>
> Its a tough issue to solve but here is yet another touch issue:
>
> systemd refuses to support pam_session_close. pam_selinux relies on this
> to reset the tty label. The process that deals with pam_session_close
> (sd-pam) runs unprivileged and that means that when the session closes
> that the terminal context cannot be reset because the process does not
> have the permission to reset the label (does not run as root)
>
> I brought this issue up here:
>
> https://lists.freedesktop.org/archives/systemd-devel/2025-July/051561.html
>
> kindly read follow the url in that link to read more.
>
> These are complicated issues and we were able to look away for over ten
> years but people are noe starting to use functionality that relies on
> this pam functionality to work properly (run0 is one feature but another
> feature is package postinstallation scriptlets entering session of other
> users to reload their systemd instance (so that it picks up upgraded
> user service units) for example: systemctl --user --machine
> kcinimod@.host daemon-reload
>
>>
>>>
>>> --
>>> gpg --locate-keys dominick.grift@defensec.nl (wkd)
>>> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>>> Dominick Grift
>>> Mastodon: @kcinimod@defensec.nl
>>>
>>

-- 
gpg --locate-keys dominick.grift@defensec.nl (wkd)
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift
Mastodon: @kcinimod@defensec.nl