Confined SELinux Users was introduced a while ago. The basic idea is to give users different access depending on the machine they log into.
Using myself as an example, I regularly login to 5 different machines, not including VMs. My Laptop, My Test machine, shell.devel.redhat.com, people.redhat.com and people.fedoraproject.com.
- people.redhat,com and people.fedoraproject.com: I should login as guest_u:guest_r:guest_t:s0. These machines are used to share content via the Web Servers. I should be only allowed to modify my home directory. I should not have access to the network, setuid applications like su and sudo, or be able to build and execute code in the home directory.
- shell.devel.redhat.com. This machine is a shared developer shell machine, to be used by all developers. I should be allowed to execute content in the home directory and maybe setup and test networking applications, since this is a development machine. But I am not an administrator, I should not be allowed to execute su or sudo. user_u:user_r:user_t:s0-s0:c0.c1023 would be a good SELinux user label for this machine.
- My Laptop and test machines, (holycross and redsox), should either be setup to use unconfined_t or staff_t. In my case I run them with staff_u:staff_r:staff_t:s0-s0:c0.c1023, and administrator processes as staff_u:unconfined_r:unconfined_t:s0-s0:c
One big advantage of FreeIPA is it adds identity to machines. FreeIPA knows the difference between dwalsh on people.redhat.com versus dwalsh on shell.devel.redhat.com. The FreeIPA team added the ability to store SELinux Users definitions based on User/Machine mappings.
In Fedora 18 you will be able to setup confined users using the FreeIPA gui.
At Red Hat we could setup a user/machine mapping like all users on people.redhat.com will login with the SELinux user/level guest_u:s0.
SSSD plays a large role in assigning the SELinux User/Level from IPA to the user process at login.
When a user logins to a box say through sshd, sshd uses the pam stack. One of the first pam modules used is pam_sss. pam_sss sends a request to SSSD telling it that dwalsh is logging in. SSSD contacts the FreeIPA server and asks what SELinux User/Level should dwalsh get when he logs in. SSSD takes the string returned and creates a file in /etc/selinux/POLICYTYPE/logins/dwalsh. During the session of the pam stack, the pam_selinux module is called. pam_selinux reads /etc/selinux/POLICYTYPE/logins/dwalsh and tells the kernel to launch the user process with the SELinux User specified in FreeIPA, for example guest_u:guest_r:guest_t:s0.
Currently SSSD only supports FreeIPA for this transaction. In the future it could be modified to use other sources for SELinux information.
Note: In FreeIPA you can set up a set of the Host Based Access Control rules. These rules define which users (and groups of users) have access to which machines (and groups of machines) via which login services (like ssh, ftp, sudo, su etc.) The administrator can reuse the user-host associations defined in the HBAC rules to define SELinux user mapping rules. This helps to avoid duplicate management and express a notion: user set X can access set of hosts Y and would get SELinux user Z.I have been asked many times when I have given the Confined SELinux Users talk, about how would you manage confined users in a large environment, now we have a solution.