Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 04:30:36PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > > > 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 > > > > > > > shell (via container-shell@.service) as well as with a systemd > > > > > > > --user > > > > > > > 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. > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > 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) > > > > > > > &
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > > 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 > > > > > > shell (via container-shell@.service) as well as with a systemd > > > > > > --user > > > > > > 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. > > > > > > > > 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 > > > > > > > > > > > > > > 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) > > > > > > > > > > > > > > Running machinectl shell .host locally doesn't seem to work: > > > > > $ 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.
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > 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 > > > > > shell (via container-shell@.service) as well as with a systemd --user > > > > > 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. > > > > > > 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 > > > > > > > > > > > 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) > > > > > > > > > > > Running machinectl shell .host locally doesn't seem to work: > > > > $ 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 de
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > 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 > > > > shell (via container-shell@.service) as well as with a systemd --user > > > > 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. > > > > 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 > > > > > > > > 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) > > > > > > > > Running machinectl shell .host locally doesn't seem to work: > > > $ 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
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > 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 > > > shell (via container-shell@.service) as well as with a systemd --user > > > 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. > > 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 > > > > > 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) > > > > > Running machinectl shell .host locally doesn't seem to work: > > $ 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_fi
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > 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 > > shell (via container-shell@.service) as well as with a systemd --user > > 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. 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 > > 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) > > Running machinectl shell .host locally doesn't seem to work: > $ 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 > > Ideally, I'd like to get rid of security_compute_user() entirely, take > the logic for determining user context entirel
Re: pam_selinux and systemd
On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > 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 > shell (via container-shell@.service) as well as with a systemd --user > 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.
pam_selinux and systemd
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 shell (via container-shell@.service) as well as with a systemd --user 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 -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature