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 placeSo 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 > > > > > 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
signature.asc
Description: PGP signature
