Bug 1124927 - on SELinux enabled system su does not change context
Summary: on SELinux enabled system su does not change context
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-30 16:08 UTC by (GalaxyMaster)
Modified: 2018-10-31 12:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-31 12:22:17 UTC


Attachments (Terms of Use)

Description (GalaxyMaster) 2014-07-30 16:08:12 UTC
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

How reproducible:

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

Actual results:

[root@centos ~]# semanage login -a -s sysadm_u r_galaxy^C[root@centos ~]# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[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
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[galaxy@centos ~]$

[Now, I'm logging in as galaxy]

[galaxy@centos ~]$ id -Z
user_u:user_r:user_t:s0
[galaxy@centos ~]$

Expected results:

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.

Additional info:

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.

Comment 1 (GalaxyMaster) 2014-07-30 16:18:30 UTC
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.

Comment 3 (GalaxyMaster) 2014-07-31 02:38:12 UTC
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.

Comment 4 Karel Zak 2014-09-22 09:53:32 UTC
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]

Comment 5 Daniel Walsh 2014-09-24 12:29:33 UTC
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.

Comment 6 (GalaxyMaster) 2014-09-24 15:40:02 UTC
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.

Comment 7 Daniel Walsh 2014-10-12 10:46:29 UTC
Well we did not understand what the use case way. sorry.

Comment 8 Daniel Walsh 2014-10-12 10:55:03 UTC
Why not just script this.


selinuxsu

#!/bin/sh
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
staff_u:staff_r:staff_t:s0-s0:c0.c1023

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.

Comment 9 (GalaxyMaster) 2014-10-12 22:55:19 UTC
Daniel,

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

Comment 10 (GalaxyMaster) 2014-10-12 22:57:05 UTC
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).

Comment 11 Miroslav Grepl 2014-10-13 08:31:09 UTC
(In reply to Daniel Walsh from comment #8)
> Why not just script this.
> 
> 
> selinuxsu
> 
> #!/bin/sh
> 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
> staff_u:staff_r:staff_t:s0-s0:c0.c1023
> 
> 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.

Comment 14 Karel Zak 2018-10-31 12:22:17 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.