danwalsh

Now you can run multiple SELinux users on a machine at the same time. 

semanage login -l looks at the Linux user to SELinux user mappings

As an example, my machine is currently setup like the following.

# semanage login -l

Login Name             SELinux User          MLS/MCS Range           

__default__               guest_u                   s0                      
dwalsh                        staff_u                      SystemLow-SystemHigh           
guest                           guest_u                   s0                      
guest1                         guest_u                   s0                      
pwalsh                         user_u                     s0                      
root                               root                          SystemLow-SystemHigh    
system_u                  system_u                  SystemLow-SystemHigh    


This means that an Linux login account not listed wil login with the guest_u user.  Meaning they can not setuid, use networking, execute in the homedir, or run XWindows.

I also have my account "dwalsh" setup to login as staff_u.  This prevents me from running any setuid apps except for sudo.

I have a coule of test accounts setup guest and guest1, which would login as guest_u.  Note this record is not necessary since I set the __default__ to guest_u.  I have an experimentat account setup for my wife, which is logging in as user_u.

There is a strange entry that describes the system_u account loging in as system_u, but if you looked at my getpwent entries, you would not see system_u.  This account is here just for cron.  Cron uses this to figure out how to run system cron jobs.

Finally we have root setup to login as the SELinux root user.


Now if we look at the SELinux users entries.  semange user -l will list the SELinux user configuration.

# semanage user -l

                             Labeling   MLS/            MLS/                         
SELinux User    Prefix        MCS Level  MCS Range                      SELinux Roles

guest_u               guest        s0         s0                                                guest_r
mytuser_u           mytuser   s0         s0                                                system_r mydbadm_r mytuser_r
root                       sysadm    s0         SystemLow-SystemHigh        system_r staff_r unconfined_r sysadm_r
staff_u                  staff           s0         SystemLow-SystemHigh        system_r staff_r unconfined_r sysadm_r
sysadm_u           user          s0         SystemLow-SystemHigh        sysadm_r
system_u            user          s0         SystemLow-SystemHigh         system_r
unconfined_u    user          s0         SystemLow-SystemHigh         system_r unconfined_r
user_u                user          s0         SystemLow-SystemHigh          system_r user_r
xguest_u           xguest        s0         s0                                                  xguest_r

You can ignore the Prefix column, since Fedora is no longer using prefix, for labeling of the homedir. We default  the prefix to user for all users, this will eventually allow us to use one shared homedir for multiple machines, where on one machine you might be a guest and on another machine you could be staff_t.

The MLS/MCS Level indicatest the sensitivity level that you would login to the machine at, and the MLS/MCS Range indicates the range of sensitivity levels that you could reach for the session.  These fields are usually not important for a targeted policy machine.  However if you plan on administrating the machine, you want to have the full range.  SystemLow-SystemHigh (s0-s0:c0-c1023).  In MLS environments you would modify these fields.

The SELinux Roles field is the critical field, to tell you which role(s) you have access to.  Roles also govern which applications you are able to run.

So if you look at the guest_u SELinux user, you see that he can only run at sensitivity s0 and his only role is guest_r.

staff_u on the other hand has the abiltiy to see process at all sensitivity levels and can transition to the system_r, staff_r, unconfined_r and sysadm_r roles.

There is a file in /etc/selinux/targeted/contexts/files/users/staff_u which is used to select the default role for the user to login as.  In the case of staff_u the default role is staff_r.

In yesterdays blog I described setting up sudo to allow it to transition you to unconfined_r. unconfined_t.  But to get this to work, staff_u needs to be able to reach unconfined_r.  Which is why we added it.  Finally if you sudo to root as staff_u and want to restart a system service, you do not want that system service to run in the unconfined_r or the staff_r, because these roles could either have to much or too little privledge to run a system service,    Selinux policy has a rule that says an unconfined_r:unconfined_t process running an initrc_exec_t labeled file will transition to system_r:initrc_t.  So we need to allow a staff_u user to gain access to the system_r role.

Looking at what happens when you login to the point that you restart a service...

system_u:system_r:gdm_t -> starts your user account as staff_u:staff_r:staff_t.

Then you start up a gnome terminal session, you are still staff_u:staff_r:staff_t

Now you want to execute sudo which is labeled sudo_exec_t

staff_u:staff_r:staff_t -> sudo_exec_t -> staff_u:staff_r:sfaff_sudo_t

sudo looks at it /etc/sudoers file and sees that dwalsh should be started as unconfined_r and unconfined_t

staff_u:staff_r:staff_sudo_t -> staff_u:unconfined_r:unconfined_t

So now I am running as root (uid=0) and staff_u:unconfined_r:unconfined_t

If I want to start the httpd serivice I start /etc/init.d/httpd which is labeled httpd_script_exec_t

# service httpd start

staff_u:unconfined_r:unconfined_t -> httpd_script_exec_t -> staff_u:system_r:initrc_t

Finaly the initrc script executes httpd which is labeled httpd_exec_t.

staff_u:system_r:initrc_t -> httpd_exec_t -> staff_u:system_r:httpd_t