October 9th, 2012

New Security Feature in Fedora 18 Part 4: FreeIPA/SSSD distributes Confined SELinux Users

FreeIPA now supports the distribution of SELinux Users

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:c0.c1023.
The problem with this configuration is that each one of these machines has to be setup individually.  My identity is shared by a directory server and authorization is confirmed by kerberos.  But until now, there was no standard way to setup these confined users on a centralized server.

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.

New Security Feature in Fedora 18 Part 5: Systemd Secures Journald from attack

Forward Secure Sealing (FSS)

Forward Secure Sealing is a new feature of systemd/journald in Fedora 18.

If your machine is cracked, (Did you disable SELinux?) and a hacker gets administrative control, he wants to cover their tracks, by modifying the system log files.  This presents a problem in that you might not know when the machine was hacked and whether any of your log files have been tampered with.  Before FSS  the only way to know your log files have not been tampered with is to store them on a different machine, IE Setup rsysog and auditlogs to be sent to different machines.  With FSS you can verify the journald logs on your system and know if they have been tampered with.  Even better you will have an idea when the hacker started tampering with them, and which part of the logs files are still valid.

The basic idea is you establish a verification ID and store it externally or just use a QR code and store it on a smart phone.

Read Lennart Poettering posting on Google+ For more explanation.