Linux – Wrong role and type on login

lightdmselinux

I'm on an Ubuntu 14.04 derivative, elementary OS Freya.

I have installed and configured SELinux using the selinux-policy-default package, which contains a lot of modules. I've also added my user to the staff_u SELinux user:

$ sudo semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         SystemLow-SystemHigh *
naftuli              staff_u              SystemLow-SystemHigh *
root                 unconfined_u         SystemLow-SystemHigh *
system_u             system_u             SystemLow-SystemHigh *

For reference, here are the SELinux users:

$ sudo semanage user -l

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles

root            sysadm     SystemLow  SystemLow-SystemHigh           staff_r sysadm_r system_r
staff_u         staff      SystemLow  SystemLow-SystemHigh           staff_r sysadm_r
sysadm_u        sysadm     SystemLow  SystemLow-SystemHigh           sysadm_r
system_u        user       SystemLow  SystemLow-SystemHigh           system_r
unconfined_u    unconfined SystemLow  SystemLow-SystemHigh           system_r unconfined_r
user_u          user       SystemLow  SystemLow                      user_r

After I login, I have a strange type, and I find myself in sysadm_r instead of staff_r:

$ id -Z
staff_u:sysadm_r:gpg_agent_t:SystemLow

I might be able to explain the gpg_agent_t, as I have a script in my Xsession.d which starts gpg-agent, /etc/X11/Xsession.d/90gpg-agent:

: ${GNUPGHOME=$HOME/.gnupg}

GPGAGENT=/usr/bin/gpg-agent
PID_FILE="$HOME/.gpg-agent-info"

if grep -qs '^[[:space:]]*use-agent' "$GNUPGHOME/gpg.conf" "$GNUPGHOME/options" &&
   test -x $GPGAGENT &&
   { test -z "$GPG_AGENT_INFO" || ! $GPGAGENT 2>/dev/null; }; then

   if [ -r "$PID_FILE" ]; then
       . "$PID_FILE"
   fi

   # Invoking gpg-agent with no arguments exits successfully if the agent
   # is already running as pointed by $GPG_AGENT_INFO
   if ! $GPGAGENT 2>/dev/null; then
       STARTUP="$GPGAGENT --daemon --enable-ssh-support --sh --write-env-file=$PID_FILE $STARTUP"
   fi
fi

However, I can't find out why any graphical shells I open have the gpg_agent_t type and why they have the sysadm_r role. In my /etc/sudoers, I've granted access to be able to transition up to the sysadm_r with sudo, but I shouldn't have that by default:

naftuli ALL=(ALL:ALL) ROLE=sysadm_r PASSWD: ALL

If I login with a TTY, everything looks great:

staff_u:staff_r:staff_t:SystemLow-SystemHigh

Why is lightdm or gala giving me this strange type and role? How can I fix it?

I know that there's no policy for either lightdm or gala, I might be writing one. I'm trying to get this system into enforcing mode, I'm currently in permissive because X/gala/lightdm crashes as soon as I setenforce 1.

EDIT: By editing my gpg-agent start script, I'm now logged in as staff_u:sysadm_r:sysadm_t. Also, my session processes look like this:

system_u:system_r:sysadm_t:s0   root      1875  0.0  0.0 292864  5888 ?        SLsl 10:33   0:00 lightdm
system_u:system_r:xserver_t:s0  root      1927  6.3  0.4 396864 74804 tty7     Ssl+ 10:33  12:38 /usr/bin/X -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
system_u:system_r:sysadm_t:s0   root      4699  0.0  0.0 170580  4688 ?        Sl   10:33   0:00 lightdm --session-child 12 19
staff_u:sysadm_r:sysadm_t:s0    naftuli   5067  2.0  0.4 974688 75180 ?        Sl   10:34   4:08 gala

I think that Gala is doing it wrong. It could be lightdm, which is my login greeter, but I'm not sure. Again, this is Ubuntu so SELinux awareness is not likely.

Best Answer

As this is a really good question, and it was of interest for me I did some searches which ended up being not very helpful. Finally I reached out to #selinux on Freenode IRC, and asked how the default selinux role is selected. Luckily the user grift could provide the missing pieces of information to answer your question.

The main component for setting the selinux context is pam_selinux.so which is responsible for setting up the session. The pam module has various configuration options, and can also interactively ask the user for the desired context. In case there is no information during the login, it falls back to use information stored in /etc/selinux/$TYPE/contexts/user/$USERID if not defined, it uses the __default__ context set in contexts/default_contexts.

root@u1604-cnt-host:/etc/pam.d# grep selinux *
lightdm:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
lightdm-autologin:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm-autologin:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
lightdm-greeter:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
lightdm-greeter:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
login:session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
sshd:session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so close
sshd:session [success=ok ignore=ignore module_unknown=ignore default=bad]        pam_selinux.so open
systemd-user:session  required pam_selinux.so close
systemd-user:session  required pam_selinux.so nottys open
root@u1604-cnt-host:/etc/pam.d#

As lightdm uses the same pam_selinux.so calls as login or sshd this should not be the source of the problem.

I've shortly tried to get the desired change working in Ubuntu, but had the impression that the selinux policy was messed up at process level. So I've done some tests on Fedora:

[root@workbench users]# cat /etc/selinux/targeted/contexts/users/staff_u
system_r:local_login_t:s0       guest_r:guest_t:s0 staff_r:staff_t:s0
system_r:remote_login_t:s0      staff_r:staff_t:s0
system_r:sshd_t:s0              guest_r:guest_t:s0 staff_r:staff_t:s0
%<--- snipp ---%<

switching system_r:sshd_t:s0 to guest_r:guest_t:s0 workes fine, the selinux user must have the role assigned in order to work. The sshd process is running under the system_r:sshd_t domain. When trying to switch the default context for staff_u to sysadm_r:sysadm_t|system_r:system_r the login falls back to staff_r:staff_t:s0 when just replacing the guest_r:guest_t part. This is related to the policy for system_r:sshd_t that does not allow a context switch to system_r or sysadm_t.

Setting a non-working combination leads to unconfined_r:unconfined_t which is the default type on Fedora targeted, as default_contexts contains user_r:user_t for system_r:sshd_t but the selinux user had no access to the user_r role during the test.

Some more details on the topic:

https://selinuxproject.org/page/PolicyConfigurationFiles#contexts.2Fusers.2F.5Bseuser_id.5D_File

https://selinuxproject.org/page/RefpolicyBasicRoleCreation#Default_Contexts

Related Solutions

Linux – Myth or reality: SELinux can confine the root user

Reality: yes, SELinux can confine the root user.

This is possible because SELinux do not actually care about the current Unix user: all it sees is a supplementary metadata called the context (which includes, among other fields, a domain field) and which lets SELinux decides whether the requested action can be authorized or not.

What one usually conceives as the root user would be mapped in SELinux as a root Unix user running either the unconfined_t or sysadm_t SELinux domains. It is the classical full-powered omnipotent root user.

However, one could perfectly setup his system to spawn a root shell (I mean root Unix user shell) running the restricted user user_t SELinux domain. As per SELinux policies, such shell would be no different than any other restricted users shells and would have no special privilege on the system, thus effectively confining the root user.

Appart from an experimental point-of-view, doing such thing literally is useless, however similar practice find their way in real world. A classic example would be a database administrator needing to be able to stop/start the database daemons, edit configuration files, etc. Without SELinux, all these actions would require the user to escalate toward root privileges (even if it is normally for a single command line via the sudo tool for instance, however even that may be prone to leaks).

Thanks to SELinux, we could give this user a genuine root shell, but instead of running unconfined_t or sysadm_t domains it will run the dbadm_t domain. This mean that he will have more privilege than a restricted user, but these new privileges will be limited to what is needed to administrate the database server: this user will not be able to tamper with other services, files or run other administrative commands than those strictly required to do his job.

The same way, the web server and other services administrators could also have other root shells running in parallel on the same system, every one will see their current Unix user being root, but thanks to SELinux each one will have effectively different privileges limited to what is needed for their own purposes.

Linux – How to transition into another domain when invoking sudo

You can specify a transition in a custom policy file (.te) like this:

module collectdlocalexec 1.0;

require {
        type collectd_t;
        type user_home_t;
        type unconfined_t;
        type shell_exec_t;
        class capability {setgid setuid };
        class file { execute read open };
        class process transition;
}

allow collectd_t self:capability { setgid setuid };
allow collectd_t user_home_t:file { execute read open };
allow collectd_t shell_exec_t:file execute;
allow collectd_t unconfined_t:process transition;

type_transition collectd_t user_home_t:process unconfined_t;

Assuming that the collection script is located under a user's home directory (and that is labeled with user_home_t).

Best Answer

Related Solutions

Linux – Myth or reality: SELinux can confine the root user

Linux – How to transition into another domain when invoking sudo

Related Question