[SOLVED] SELinux - confining regular user: Unexpected result

druuna · 03-21-2012, 05:40 AM

Hi all,

I'm rather new to SELinux and decided it was time to get acquainted with this material.

While playing around with confining users I ran into the following unexpected result:

I created a regular user and applied the following commands to restrict this user to the user_u role and check the result:

Code:

# semanage login -a -s user_u tstuser
# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
tstuser                   user_u                    s0                       
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023

If I log in as tstuser all works as expected:

Code:

$ whoami
tstuser

$ id -Z
user_u:user_r:user_t:s0

$ su -
-bash: su: command not found

The following, however, was not what I expected:

After logging in as a different, unconfined user and then log in as tstuser using su - tstuser all the confinement for tstuser is gone.

Code:

$ ssh druuna@192.168.122.100
druuna@192.168.122.100's password: 

[druuna ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[druuna ~]$ su - tstuser
Password: 

[tstuser ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[tstuser ~]$ su -
Password:
[root ~]#

To make sure all settings are applied I:
- logged out all users and redid the above login steps-> same result
- rebooted and redid all the login steps -> same result

Am I overlooking something, 'cause this "feels" wrong.
Or is this by design? And if so, what is the logic behind this?

Using the staff_u role instead of the user_u role doesn't make any difference.

Tests are executed on (virtualized) RHEL 6.2

Noway2 · 03-21-2012, 06:11 PM

I am rather new to SELinux myself, but I think what is happening is that your rules are only temporary unless you use the commands to actually create a (permanent) rule that gets reloaded. I found this link for the CentOS wiki to be quite helpful in understanding SELinux and since your running RH, it should apply to your version too.

druuna · 03-22-2012, 02:13 AM

Hi Noway2,

Quote:

Originally Posted by Noway2

I am rather new to SELinux myself, but I think what is happening is that your rules are only temporary unless you use the commands to actually create a (permanent) rule that gets reloaded. I found this link for the CentOS wiki to be quite helpful in understanding SELinux and since your running RH, it should apply to your version too.

Yes, certain parts of SELinux need to be made permanent to survive a reboot, the setsebool tool is an example (you need to use the -P option to make it stick). Using semanage to set a role does survive a reboot. I did not take the author's word for it, I actually tried and it does stick.

The questions isn't about what sticks when, but why a user role isn't enforced when that specific user doesn't log in using the "noraml" CLI/GUI but uses su (or su -) from a terminal started by a different (unconfined) user (see the last code block in my first post).

I have to assume that there is a lack of understanding on my side, but it does look like a way to circumvent the specific user role that was set.

BTW: Thanks for the link!

Noway2 · 03-22-2012, 07:20 AM

Druuna, thank you for clarifying. Now I understand the problem now and would have to say that it goes over my understanding of SELinux. I too have just begun to try and learn how to use it effectively. Yesterday, I read on Wikipedia that the permissions structure is tied to the inode and that things like moving and replacing files will cause it to break. It sounds like there is something similar at work where the process path doesn't execute the same way when SU is used, but my understanding of SELinux limits me to vague speculation. I'm pretty sure that there are a couple of expert level users here and perhaps one of them can shed some light on this.

druuna · 03-30-2012, 08:37 AM

Hi,

I might have found the reason for the above mentioned behaviour: SELinux - 4.2. Unconfined Processes (RHEL6).

Do read the full chapter when you are interested, but I do believe it boils down to this:

Quote:

Processes running in unconfined domains fall back to using DAC rules exclusively.

Closing this thread. If and when I find additional info I will add it.

unSpawn · 03-30-2012, 10:25 AM

Well I for one didn't realize that was the case. Learned something new. Thanks.