pam_selinux and systemd

Post by Dominick Grift
pam_selinux requirements are generally pretty simple: its used to
associate a context with a login shell.
With systemd things have becomes a bit more complicated.
systemd uses pam_selinux to associate a context with both a login
instance.
Ideally one would not associate a login shell context with a systemd
--user instance because a systemd --user instance needs permissions
that do not make sense for a login shell to have.
I am not aware of any way to make pam_selinux associate a context
based on variable like for example: if its a login shell then
associate this context , and if its a systemd --user instance then
associate that context
This is an issue for me currently because if users are allowed to
"host-shell" (machinectl shell .host) then they are able to open a
shell with the context of the systemd --user instance and escape
their shell restrictions
For now I can just block host-shell access with polkit but I am
trying to figure out what it would take to address this challenge
with pam_selinux

The logic for determining a security context from pam_selinux (using
libselinux get_ordered_context_with_level) can take the source/from
context (i.e. the context in which the caller of pam_selinux is running
) into account as a factor in selecting which context to use, since it
checks reachability (transition permission) as part of
security_compute_user(). So that's a possible approach if you can
distinguish what contexts are reachable for systemd --user vs login
daemons.

What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Running machinectl shell .host locally doesn't seem to work:
$ machinectl shell .host
Failed to get shell PTY: Access denied

Ideally, I'd like to get rid of security_compute_user() entirely, take
the logic for determining user context entirely to userspace, and
simplify it significantly, both in libselinux and in pam_selinux.
That's been discussed previously on the list.

Dominick Grift

2017-09-07 13:22:42 UTC

The challenge here is that the source/from context is the same whether systemd --system spawns a login shell on behalf of a login user or whether systemd --system spawns a systemd --user instance on behalf of a login user

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.

machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user

So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?

$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
Password:
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user

So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash

I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux

So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Post by Stephen Smalley
Ideally, I'd like to get rid of security_compute_user() entirely, take
the logic for determining user context entirely to userspace, and
simplify it significantly, both in libselinux and in pam_selinux.
That's been discussed previously on the list.

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 13:30:47 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

So to answer your question as to whether i would be able to block this access without polkit:

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 13:35:36 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?

Actually, It probably the absence of polkit that is causing this

Post by Dominick Grift
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 13:50:02 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

So that will be my short term solution. Eventually I would like to figure out a way to make this work though.

That would require, i suspect, that pam_selinux be modified somehow so that systemd --system spawns -bin/sh (ex. sysadm.id:sysadm.role:sysadm.subj:s0) with a different context than when it spawns /usr/lib/systemd --user (ex. sysadm.id:sysadm.role:sysadm_system.subj:s0)

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 13:56:36 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

So that will be my short term solution. Eventually I would like to figure out a way to make this work though.
That would require, i suspect, that pam_selinux be modified somehow so that systemd --system spawns -bin/sh (ex. sysadm.id:sysadm.role:sysadm.subj:s0) with a different context than when it spawns /usr/lib/systemd --user (ex. sysadm.id:sysadm.role:sysadm_system.subj:s0)

Actually that wont work because then a user service unit in ~/.config/systemd/user with a ExecStart=/bin/sh -c /bin/id wouldnt work anymore ...

mind bending...

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 14:30:36 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

So that will be my short term solution. Eventually I would like to figure out a way to make this work though.
That would require, i suspect, that pam_selinux be modified somehow so that systemd --system spawns -bin/sh (ex. sysadm.id:sysadm.role:sysadm.subj:s0) with a different context than when it spawns /usr/lib/systemd --user (ex. sysadm.id:sysadm.role:sysadm_system.subj:s0)

Actually that wont work because then a user service unit in ~/.config/systemd/user with a ExecStart=/bin/sh -c /bin/id wouldnt work anymore ...
mind bending...

I imagine that some start to wonder whether it is worth confining systemd --user instances in the first place.

One reason that i find kind of compelling is socket activation

systemd --user also supports socket activation (actually dbus --user is socket activated but so can be many others)

That means that systemd --user needs to be able to create sockets on behalf of socket activated entities with setsockcreate, but besides that systemd --user would also need to be able to bind sockets to ports on behalf of for example tcp socket activated entities

--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Dominick Grift

2017-09-07 14:59:55 UTC

Post by Stephen Smalley
What SELinux permissions are required to host-shell? Can you block
that via SELinux policy rather than just polkit?

Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this doesnt use pam_selinux, only machinectl shell .host makes systemd --system use pam_selinux to determine the pam characteristics to associate with the login shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container (no pam), and "machinectl shell .host" makes machinectl tell systemd --system to spawn a login shell on the host (where systemd --system is using pam_selinux)

Post by Stephen Smalley
$ machinectl shell .host
Failed to get shell PTY: Access denied

Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
==== AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
==== AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183 scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0 tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500 pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ? Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to associate "sysadm_systemd.subj" with the login process, but that type is for the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj on cmd.shell.cmd_file that eventually makes the transition work when manually running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file) -> sysadm.subj) not realizing that the shell initially ends up with sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in sysadm_systemd.subj in the first place

Yes i would be able to do this by just not allowing the systemd --user instances to execute a shell

So that will be my short term solution. Eventually I would like to figure out a way to make this work though.
That would require, i suspect, that pam_selinux be modified somehow so that systemd --system spawns -bin/sh (ex. sysadm.id:sysadm.role:sysadm.subj:s0) with a different context than when it spawns /usr/lib/systemd --user (ex. sysadm.id:sysadm.role:sysadm_system.subj:s0)

Actually that wont work because then a user service unit in ~/.config/systemd/user with a ExecStart=/bin/sh -c /bin/id wouldnt work anymore ...
mind bending...

I imagine that some start to wonder whether it is worth confining systemd --user instances in the first place.
One reason that i find kind of compelling is socket activation
systemd --user also supports socket activation (actually dbus --user is socket activated but so can be many others)
That means that systemd --user needs to be able to create sockets on behalf of socket activated entities with setsockcreate, but besides that systemd --user would also need to be able to bind sockets to ports on behalf of for example tcp socket activated entities

for reference:

https://github.com/DefenSec/dssp2-standard/issues/6