systemd.exec(5) PAMName= with libselinux

systemd.exec(5) PAMName= with libselinux

[Dominick Grift]

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?

-- 
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

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

[Stephen Smalley]

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.

>
> --
> 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
>

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

[Dominick Grift]

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

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

[Dominick Grift]

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

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

[Dominick Grift]

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

> 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

Found a hint: its using the session from /etc/pam.d/login for this (PAMName=login)
and I am not sure if that is right.

I edited /etc/pam.d/login and appended nottys to the pam_selinux open
call just to test and the results look promising.

Need to figure out why its using /etc/pam.d/login for this because that
seems less than optimal.

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 24 07:21 /dev/pts/8
kcinimod@nimbus ~ $ run0
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start transient unit 'run-p680430-i680730.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 24 07:21 /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 sys.id:sys.role:sys.ptytermdev:s0 136, 10 Jul 24 07:21 /dev/pts/10
🦸 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 24 07:25 /dev/pts/8




> 🦸 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

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

[Rahul Sandhu]

Hi,

I think this is solveable but this is going to need a new field added to
default_contexts + $selinux_root/$policy_type/contexts/users/*. I had a
look around tonight, couple notes:

1. We can't really change (and shouldn't change) the function signature
   for get_ordered_context_list (3) and friends.  However, we shouldn't
   need to do that (see point 2).

2. So long as get_ordered_context_list (3) and friends still can parse
   the user context files, we should be fine.  They all seem to rely on
   the same underlying function to parse those files, get_context_user,
   so along as we update that to support multiple "fields", and to just
   ignore extra fields, then that should be okay. This should mean that
   backwards compatability should not be a problem at all.

Then, we adapt pam_selinux (8) to use getseuserbyname (3) to lookup all
fields it needs manually (without using any of the libselinux helpers
for that). Alternatively, we could add a helper to libselinux for that
that supports the new "fields" so that we don't break compatability. If
that's a desired route, any suggestions for that?

One concern I do have (and something I'm trying to keep in mind) is
ensuring that libselinux doesn't have a dependency on PAM, or at least
that our entire user login flow is completely dependent on PAM such
that it's impossible or hard to replace it, given that we don't have it
as a hard dependency right now, and I would be cautious to make it one.
However, we are just adding a field here, so although we can have that
new field by *convention* be for a PAM login stack, other software is
free to interpret as it wishes.

Another option would be to try and deprecate default_contexts, given
that it seems to be showing some age in terms of no longer being enough
for one of the major pieces of software in today's landspace (systemd),
and introducing a new file that supports a configuration format with
some kind of KV system so we have named "fields". However, myself I am
not convinced that this is needed or worth it right now, but of course
open to ideas and suggestions.

Thoughts?
Rahul

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

[Stephen Smalley]

On Sun, Sep 28, 2025 at 10:29 PM Rahul Sandhu <nvraxn@gmail.com> wrote:
>
> Hi,
>
> I think this is solveable but this is going to need a new field added to
> default_contexts + $selinux_root/$policy_type/contexts/users/*. I had a
> look around tonight, couple notes:
>
> 1. We can't really change (and shouldn't change) the function signature
>    for get_ordered_context_list (3) and friends.  However, we shouldn't
>    need to do that (see point 2).
>
> 2. So long as get_ordered_context_list (3) and friends still can parse
>    the user context files, we should be fine.  They all seem to rely on
>    the same underlying function to parse those files, get_context_user,
>    so along as we update that to support multiple "fields", and to just
>    ignore extra fields, then that should be okay. This should mean that
>    backwards compatability should not be a problem at all.
>
> Then, we adapt pam_selinux (8) to use getseuserbyname (3) to lookup all
> fields it needs manually (without using any of the libselinux helpers
> for that). Alternatively, we could add a helper to libselinux for that
> that supports the new "fields" so that we don't break compatability. If
> that's a desired route, any suggestions for that?
>
> One concern I do have (and something I'm trying to keep in mind) is
> ensuring that libselinux doesn't have a dependency on PAM, or at least
> that our entire user login flow is completely dependent on PAM such
> that it's impossible or hard to replace it, given that we don't have it
> as a hard dependency right now, and I would be cautious to make it one.
> However, we are just adding a field here, so although we can have that
> new field by *convention* be for a PAM login stack, other software is
> free to interpret as it wishes.
>
> Another option would be to try and deprecate default_contexts, given
> that it seems to be showing some age in terms of no longer being enough
> for one of the major pieces of software in today's landspace (systemd),
> and introducing a new file that supports a configuration format with
> some kind of KV system so we have named "fields". However, myself I am
> not convinced that this is needed or worth it right now, but of course
> open to ideas and suggestions.
>
> Thoughts?

I'm not overly concerned with requiring use of pam_selinux and/or
replicating its logic in whatever authentication system is in use by a
given Linux distribution for user context computation/selection.
Others (particularly distro maintainers) are welcome to speak up if
they disagree.

I'm also fine with incremental evolution here rather than wholesale
rip-and-replace, but since you would be the one doing the work, it's
more a question of what you want to take on IMHO.