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

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

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.

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