danwalsh

When I first started working on SELinux about a couple of hundred years ago, or so it seems, SELinux was used to confined "logged in" users.  I define a "logged in" user as a user who has used credentials (Username/Password) to login to a system via a login program like login, xdm or sshd.
   
When we first shipped SELinux in Fedora Core 2, we went out with the example policy from NSA, later renamed "strict" policy, and it was a disaster.  Hundreds of bugs per day, and everyone was clamoring how to turn off SELinux.   Fedora Core for the most part is a single user OS and that user does not want to be confined.   Also  much to my chagrin  people all over the world did not want to setup their machines the way Dan Walsh wanted them to.  :^(  Strict policy and confining of users requires file context to be setup correctly in the users home directories.  Labeling for these home directories proved to be very difficult to maintain.   Finally using SELinux to confine something requires a "security policy", by this I mean you need to define what access you want an application/user to have.  

For example; everyone wants to confine the web browser.  But no one agrees on how the web browser should be confined.  Should it only be allowed to view web pages?  Should it be allowed to run helper applications?  If I launch OpenOffice from inside the web browser, should I allow a transition from firefox_t to ooffice_t?  Or stay in firefox_t?  If still in firefox_t, and the user uses the open button in ooffice, what should happen?   When the web browser downloads a file to disk should it be able to place it anywhere?  Should it be able to upload files from anywhere on the system?  On the modern desktop, applications like the mail program have embedded web browsers, how should they react?  How should applications interact?

Since almost no one agrees on these, it quickly became apparent that confining "logged in users" was not going to work on a general purpose OS.  This is when we decided to re-look at policy and "Target" the domains that we wanted and new how to confine.  Targeted policy was born.

SELinux has all this power that we were not taking advantage of...

So now as we ship Red Hat Enterprise Linux 5 and Fedora 7 (No more core), I have begun to look into how we can start to confined certain types of "logged in users" in a targeted policy system

A little background:

SELinux has a feature called RBAC which stands for Roles Based Access Control.  The idea here is to control what a user can do by the roles that he is assigned.  SELinux uses type enforcement to control the "transitioning" from one role to another.  In Strict and MLS policy you would use the newrole command to switch from one role to another.  The newrole package is available in policycoreutils-newrole.

During the past few months I have been noticing a discussion of handling a "guest" account.  The kernel policy source repository system uses "git" and "git" requires a account on the server to be able to manipulate the repository.  So if you want to allow a kernel maintainer to update the source code repository you need to set him up an ssh account.  Similarly at "Red Hat", most of engineering has small accounts on people.redhat.com, where we can upload files and make them available to the public.  http://people.redhat.com/dwalsh is my home page at Red Hat.  I ssh into this account and can change my directory.  Terminal servers and other shared home/directory servers are other examples. 
The users on these systems need to be able to log onto the system, run a few commands and that is about it.  They probably should never run a setuid app.  They probably don't need to network out of the box.

I have been experimenting with the guest policy. http://people.redhat.com/dwalsh/SELinux/users/guest.te

You can copy this policy file onto your machine, and execute the following commands to set it up.

Copy guest.te to its own directory.  In that directory execute

# Compile and load the policy
make -f /usr/share/selinux/devel/Makefile
semodule -i guest.pp
# Setup guest_u SELinux user
semanage user -a -P guest -R guest_r guest_u
# add user with this SELinux mapping
useradd -Z guest_u guest
# In FC6 useradd -Z is not supported
# semanage login -a -s guest_u guest
# restorecon -R -v ~guest
# set the guest password
passwd guest
# Now there are a couple of files that you need to edit to tell the login programs that guest_r:guest_t are valid logins.
echo "guest_r:guest_t" >> /etc/selinux/targeted/contexts/default_type
echo """
system_r:sshd_t:s0    guest_r:guest_t:s0
system_r:local_login_t:s0    guest_r:guest_t:s0
""" > /etc/selinux/targeted/contexts/users/guest_u
# If you only want ssh access don't add the local_login line.  The guest user would not be able to login via xdm.

Now you should be able to login to the system as the guest user and have very limited access.  Beware
as you attempt to do certain activities you will be generating AVC messages that will trigger setroubleshoot.  But try it out and let me know what you think.  I will be posting other policies for confining user space in future blogs.

I have not upstreamed this policy but plan on working with upstream to make creating a new "logged in user type"  as

userdom_unpriv_login_user(myuser)

Then if you want to add additional privs to this user you would just add additional interfaces.
For example adding networking would just be

userdom_basic_networking_template(myuser)