Wrong role and type on login

Question

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.

Not sure if somebody tries using SELinux in Ubuntu. If you want to use SELinux where it works, I would recommend you Fedora or CentOS. You basically answered yourself about the `gpg_agent_t`. The role is probably part of the transition. Did you check if it works for you when you skip the `gpg-agent` or start it usual way as `eval $(gpg-agent --daemon)` with your options? — Jakuje, Dec 28 '15 at 08:48
I'll modify it and see what happens. I know I'm kind of out on a rope here with Ubuntu+SELinux, but I'd like to learn more about SELinux and I'm on Ubuntu for now. — Naftuli Kay, Dec 28 '15 at 19:45
Okay, so that fixed my login issue with getting the wrong type. I'm still getting `staff_u:sysadm_r:sysadm_t:SystemLow` from `id -Z`. — Naftuli Kay, Dec 29 '15 at 21:07
This is pretty naughty to debug and search where does it. You should be able to see SELinux context of the processes if you do `ps auxfZ`. How do the processes related to your session look like (basically under `lightdm` and `X`)? It should be possible to trace if it is originally with wrong context or it breaks somewhere on the way or if it was not even correctly set (also possibility). — Jakuje, Dec 29 '15 at 21:20
Updated the question with more details, thanks for your help @Jakuje. — Naftuli Kay, Dec 29 '15 at 21:54
@Jakuje Is there a way to write a script for my X session which will simply drop down to `staff_r` and `staff_t`? Am I allowed to drop down in permissions without a password? — Naftuli Kay, Dec 29 '15 at 22:12
Just checked with my Fedora on second computer (different DM, types, policy). Important is transition between `system_u` running `lightdm` and `staff_u` running your `gala` (which happened), but in the same point, also the rules and types should have change (it might be missing from policy, since it is not default Ubuntu). There would probably be some kind of [`setcon`](http://linux.die.net/man/3/setcon) or `setexeccon` call around that place which drops the privileges or the `sysadm` might not have the privilege to do so. It is probably the limit what I can help with. — Jakuje, Dec 29 '15 at 22:21
Theoretically, I could add a script in /etc/X11/Xsession.d that runs setcon to drop my privileges, but I don't know if it would be allowed to do that. As `sysadm_r`, can I drop to `staff_r`? You can DM me on [Twitter](https://twitter.com/rfkrocktk) and we could debug this offline and figure out the answer then post back. — Naftuli Kay, Dec 29 '15 at 22:42

score 2 · Answer 1 · answered Jul 01 '18 at 20:40

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

The first paragraph of your answer indicates that you had help with this answer. That’s OK — in fact, that’s great — but if part of your answer came from somebody else (including from a reference site, or even a book) you should (1) clearly identify what parts of the answer you didn’t originate, (2) identify your source(s) (what you copied from); if at all possible, provide a link, and (3) to the extent possible, identify the original author. This should, at a minimum, include a link to a home / profile page; the person’s real name would be nice to have, but is not required. — G-Man Says 'Reinstate Monica', Jul 01 '18 at 21:19
Thank you for your feedback. IRC is a chat type communication way, and the mentioned user did not provide a realname. The input coming from him was related to the explicit configuration file, and the pam_selinux module. The question I raised in the IRC channel was completely different than the original question raised here, but it indeed provide a detail of information that helped me linking it with what I already knew. — hargut, Jul 01 '18 at 21:36
1) The location of the configuration file(s) `/etc/selinux/$TYPE/contexts/user/$USERID` and the `pam_selinux.so` module name originated from the chat correspondence. 2) No content, except mentioned in 1), was copied. And I was not able to find a link to a IRC logs for that channel. In case someone needs the exact details, I currently still have the log. 3) I had already pointed out the chat location, including the nickname of the helpful person. There was no real-name, no homepage or profile. — hargut, Jul 01 '18 at 21:51

Wrong role and type on login

1 Answers1