'Re: pam_selinux and systemd'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    Re: pam_selinux and systemd
From:       Dominick Grift <dac.override () gmail ! com>
Date:       2017-09-07 14:59:55
Message-ID: 20170907145955.GB8005 () julius ! enp8s0 ! d30
[Download RAW message or body]


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

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



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


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic