Description of problem:
It is expected that when a root user switches under a non-privileged account that the SELinux context would be also changed.
Version-Release number of selected component (if applicable):
util-linux 2.23.2-16.el7, but the problem is likely in the selinux-policy-targeted
Steps to Reproduce:
1. create a system, non-privileged user and associate that account with the user_u SElinux user (useradd -m galaxy ; semanage -a -s user_u galaxy)
2. login as root
3. su - galaxy
4. id -Z
5. login as galaxy
6. id -Z
[root@centos ~]# semanage login -a -s sysadm_u r_galaxy^C[root@centos ~]# id -Z
[root@centos ~]# su - galaxy
Last login: Thu Jul 31 01:42:34 EST 2014 from 10.0.2.2 on pts/0
[galaxy@centos ~]$ id -Z
[Now, I'm logging in as galaxy]
[galaxy@centos ~]$ id -Z
It's expected that "id -Z" after switching from root to galaxy would show "user_u:user_r:user_t:s0", otherwise any files/directories created will inherit the wrong file context and any processes started will also inherit the wrong exec context.
It was discovered when I tried to set pam_namespace up for users. Currently this functionality seems to be also broken since pam_namespace is only defined in /etc/pam/login, while it should be defined for all user transitions, I believe.
I made some typos:
* "semanage -a -s user_u galaxy" in the "Steps to Reproduce" should be "semanage login -a -s user_u galaxy"
* I've copy-and-pasted from a CentOS VM, but it's the same in RHEL and FC since they have the same upstream
* Also I erroneously copy-and-pasted a bit more than intended.
The very same issue is with runuser from the same util-linux package, runuser also does not change the context when runs a command under a different user name.
Yeah, pam_selinux is missing in /etc/pam.d/su-l and /etc/pam.d/runuser-l. You can try to change the configuration (see for example /etc/pam.d/login to see how to use pam_selinux).
Frankly, I'm not sure if we want to change the configuration as I'm not sure about possible negative effects to existing use-cases (scripts). It's also guestion if we want to change selinux context on the fly by "su -" at all.
[CC selinux guys]
That is intentional. I am not sure why there is a runuser-l since runuser does not use pam.
user_t should not use su. He should be using sudo if at all.
If you know the root password then confinement of users makes little sense.
You should setup sudo to do transitions.
We usually use staff_t for an admin user to become unconfined_t or sysadm_t, or other confined admin.
Well, I'm trying to avoid sudo as much as possible - it's not usually installed on our systems. The reason is quite simple 'sudo' is escalating privileges, i.e. crosses privilege boundaries. /bin/su on our systems is chmod'ed 0700 so only root can execute it to drop their privileges. What I was asking here though is to fix a tool to _lower_ privileges. Right now I'm doing the following:
1. created a transition from unconfined_t -> user_t
2. su - account (where account is user_r:user_t:s0)
3. exec runcon user_u:user_r:user_t:s0 bash
This kind of fully switches root to the user, but it's cumbersome. Just imagine that there is a shared server, multiple users, and users ask to investigate an issue under their account. We don't want to pollute their home directories with files labeled root:unconfined_r:unconfined_t as it would be if we just do 'su - their_account'.
P.S. Re: passwords - this is another reason why we don't use sudo -- password usage is prohibited by our policies, so no system account has a password. All users are logging in using ssh keys.
It's a pity that the ticket is simply closed without even considering the usage scenario.
Well we did not understand what the use case way. sorry.
Why not just script this.
exec runcon user_u:user_r:user_t:s0 bash
The problem with putting pam_selinux into su or su-l pam config, is the policy and transitions are not written correctly to get everything to work the way you want.
You could enhance the script with something like
selinuxdefcon dwalsh system_u:system_r:local_login_t:s0
To figure out the correct process label to run for a particular user. This might be soemthing we could add to the libselinux or policycoreutils package.
It's already scripted on our side, but thanks for some additional ideas you provided.
The ticket itself is not about how to make it work on our systems (we kind of can manage this ourselves), but to address the issue at large: there is a set tools that claim to do something (e.g. su, runuser, etc.) and when you use them on a SELinux enabled system they do not perform the way they are supposed to perform. This is the problem.
I believe that when a user uses 'su' to change from root to a non-privileged account the following should be handled: transition to the corresponding destination role, type, and security contexts (keeping the SELinux user intact). This way we still have the audit trail for the original user, yet we almost fully become the designated non-privileged account.
I also believe that this should be addressed on the distribution level and the policy and not with the scripts. The transition from unconfined_t -> user_t seems to be reasonable and should be allowed (all in all, the unconfined_t type is virtually unrestricted domain so dropping privileges should be fine).
Sorry, made a typo in "transition to the corresponding destination role, type, and security contexts" should have been "transition to the corresponding destination role, type, and security categories" (contexts -> categories).
(In reply to Daniel Walsh from comment #8)
> Why not just script this.
> runser $@
> exec runcon user_u:user_r:user_t:s0 bash
> The problem with putting pam_selinux into su or su-l pam config, is the
> policy and transitions are not written correctly to get everything to work
> the way you want.
> You could enhance the script with something like
> selinuxdefcon dwalsh system_u:system_r:local_login_t:s0
> To figure out the correct process label to run for a particular user. This
> might be soemthing we could add to the libselinux or policycoreutils package.
Yes, we can add it here but still not sure if we want to have this functionality a part of su.
I'm going to close this old bug.
It seems we do not have any conclusion after 4 years and the problem is probably not painful enough to fix in RHEL 7.7 update.