Bug 1124927

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.


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.

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

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

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.