Rate this page del.icio.us  Digg slashdot StumbleUpon

Fedora 9 and Summit preview: Confining the user with SELinux

by Dan Walsh

This one’s a two-fer! Dan Walsh covers the evolution of SELinux from Fedora 2 all the way to the upcoming Fedora 9 launch. Find out how it started and how user access controls will grow in the newest release. As a bonus, this is also a preview of Walsh’s scheduled talk at the upcoming Red Hat Summit. Want more? Check out the schedule of talks and register–and we’ll see you in Boston.

History

When SELinux was first developed, the goal was to confine as many system processes as possible to the least amount of privilege required. Fedora 2 was released with SELinux policy that confined users as well as system processes. We quickly realized that SELinux policy was not mature enough to handle a modern mainstream desktop operating system. After a quick redesign of the policy, we created “targeted” policy, replacing the previously named “strict” policy. The goal of targeted policy was to “target” certain processes in the operating system for confinement and leave the rest of the processes “unconfined.”

Logged-in user’s processes were unconfined in targeted policy. A logged-in user’s process is started by login programs (like login, sshd, or gdm) when the user provides authentication. In Red Hat® Enterprise Linux® 4, there were fifteen targeted applications that were confined, and in Red Hat Enterprise Linux 5 this grew to two hundred.

In Red Hat Enterprise Linux 5, we still did not confine the user. Strict policy was still provided, but few people used the confined user components. Multi Level Security (MLS) policy–which was developed for Red Hat Enteprise Linux 5–attains the highest level of security possible for a main line operating system used in military environments. It provides confinement for the users. MLS, however, only supports servers, so X-Windows applications did not benefit from this confinement.

The MLS development forced us to concentrate more on confining users, and we realized that we could take advantage of this confinement within targeted policy.

Customers/Partner engineers that were looking to work with MLS policy kept asking: How would you write policy for a logged in user who could only talk to a single port? How about a user who could only read a certain directory?

The two types of logged-in users we had developed for strict and MLS policy were user_t and staff_t. This was a problem because these users had basically the same interfaces/transitions and pretty much the same access.

staff_t was able to transition to sysadm_t, which was sort of a poor mans unconfined process. But trying to build a confined user policy out of either of these user types was impossible, since you needed to take lots of privileges away.

I reexamined the policy and decided it was necessary to create a least privileged user, a user that could login to the system with no access other than to read/write his home directory and use /tmp. This user would not be allowed to access the network, or run any setuid applications.

Customers also requested that the user not be able to execute files in his home directory. With this type of user as a base, customers could slowly add privileges to meet their needs.

The guest_t and xguest_t user types

In Fedora 8, we introduced the guest_t and xguest_t user types. The guest_t user has only the privileges necessary to login to a system via a terminal (Login, sshd, rshd, rlogind, and telnet). The xguest_t user has only the privileges required to login to an X-Windows system.
Once we had created these users, we began to find more possible uses for them. For example, at Red Hat, I have ssh access to people.redhat.com and people.fedoraproject.org. We ssh to these accounts and copy files there to set up http web pages, like so:

http://people.redhat.com/dwalsh

Files at this site are actually just files in my home/public_html directory on people.redhat.com. When I ssh to these machines, I really should not use the network to leave them, and I do not need to run any setuid applications while I am on them. So setting up these machines where all users are guest_t would make sense.

xguest_t also comes in handy for use on desktop machines. I have blogged about the use of xguest to confine my wife. [ Ed note.: No wives were harmed in the writing of this article. ] I extended xguest_t to transition to xguest_mozilla_t when running firefox. The xguest_mozilla_t domain is allowed to access http ports but nothing else. The xguest_t account allows me to lock down the system enough so that I know what processes are connecting to the internet. If the user downloads a spam application, it will not be allowed to run in the home directory, nor can it connect to the mail ports.

Other users have suggested using xguest_t for running games and other untrusted software applications. You could also set up an xguest user account to allow others to “borrow” your machine. In Fedora 8 and 9, there is an xguest rpm, which setups a kiosk mode user.
This “xguest” user can log in to your system from the console without a password when SELinux is in enforcing mode. The xguest rpm also sets up pam_namespace to create temporary home directories and /tmp directories, which are destroyed when the user logs out. We think this is an excellent way to run a kiosk machine. The login user can only browse the web (using firefox) and can not leave any apps around to attack other users that log into the system. Everything that user does on the machine is erased when they log out, so no one could grab any password information that might have been left behind.

You can try out xguest by executing:

# yum install xguest

The user_t SELinux user type

For Fedora 9, we combined the strict policy with the targeted policy. We have enhanced the user_t and staff_t SELinux user and now allow you to setup these users in a targeted policy system.

The user_t SELinux user is the standard SELinux user. At Red Hat, we have a distribution of Red Hat Enterprise Linux that is given to all non-engineers by the IT department. Sales people, support, administration, and management staff are given machines installed with a version of Red Hat Enterprise Linux but are not usually given the root password. These are machines for people who do not want to administer their own boxes. The IT department is in charge of updating the software on these boxes and maintaining the security. If users want to add software or modify their machines they have to contact the help desk for an update.

Accounts like these should be set up to use the user_u SELinux user. user_u is a complete login user account, unlike xguest, and it has full networking so that the user can connect to any network port. It does not have the ability to run setuid applications without a transition.

setuid applications are executables that have a special flag set on them. This flag tells the kernel to run the application with the identity of the owner of the application rather then the identity of the person executing the program. Usually setuid apps are owned by root, so running as setuid application as a normal user allows you to gain privileges. Over the years, many setuid applications have had vulnerabilities that allowed root exploits of the system. user_t would not be allowed to run any of these applications.

Since the users of this machine have no reason to ever become root, they do not have the ability to run su, sudo, userhelper, or any other application that requires setuid. Even if you had a setuid shell program on your system, user_t would not be allowed to execute it. Additionally, user_t processes are not allowed to read a lot of system space, so you are somewhat protected from “snooping eyes” looking at how the system is running.

If you have a setuid application that you want the user to be able to run, you can write policy to allow the user_u account to transition to a different domain to execute the code. For example, xlock uses pam to verify the users password. pam executes /sbin/unix_chkpwd, a setuid application. policy allows a transition from user_u:user_r:user_t -> user_u:user_r:chkpwd_t, which can run as root.

Like xguest , the user_u account can be set to disallow execution of programs in the home directory or /tmp.

setsebool -P allow_user_exec_content=0

If you want to set up your system to try out the user account, you can execute the following command as root:

# semanage login -m -s user_u USERNAME

or

# usermod -Z user_u USERNAME

If you want to add a user with user_u, you can execute:

useradd -Z user_u USERNAME

If you want all users on your system to default to user_u you would execute:

# semanage login -m -s user_u __default__

The staff_t SELinux user type

The staff_t user is for users who need to do some system administration, but do not need to be fully unconfined. This is the user that I log in as every day. Staff_t is similar to user_t in that it has full networking and is only allowed to run setuid applications via a transition. staff_t has a transition to sudo so you can write policy to allow the staff_t user to transition to a confined root user via the sudo command. If I run any other setuid application, it will fail, including su.

I actually have a transition defined between the staff_t to unconfined_t. When I become root, I become the unconfined_t user. This allows me to manage my machines any way I want, but requires me to go through sudo to gain the privilege. We have a webadm_t policy available in Fedora 9 that can also be used for a “confined” root user.

My sudoers file has the following line in it:

dwalsh	ALL=(ALL) 	TYPE=unconfined_t ROLE=unconfined_r ALL

To only allow this user to administer apache server I could use:

dwalsh	ALL=(ALL) 	TYPE=webadm_t ROLE=webadm_r ALL

To try out the staff account, execute the following command as root:

# semanage login -a -s staff_u -r s0-s0:c0.c1023 USERNAME

or

# usermod -Z staff_u USERNAME

Configure the staff_u user to allow it webadm_r and/or unconfined_r by executing:

# semanage user -m -R"unconfined_r webadm_r staff_r" staff_u

My next SELinux article will cover using the SELinux GUI to define additional SELinux users or extend the existing users. Also, I will be presenting this information at the Red Hat Summit and hope to be handing out xguest/kiosk liveCDs. If you have any questions or ideas, please come to my talk and let me know.

About the author

Dan Walsh has over 20 years experience in the computer field. He has spent most of his career working on Security Applications and platforms. He spent several years working on the Athena Project while at Digital Equipment Corp. Dan was also involved in designing and developing the AltaVista Firewall and AltaVista Tunnel (VPN) Products. He has worked for Netect developing HackerShield, a Vulnerability Assessment Product. Netect was acquired by BindView, where he continued working on HackerShield and developed a new product, BVControl for UNIX. At Red Hat, Dan has led the SELinux project, concentrating mainly on the application space and policy development. Dan Graduated with a BA in Mathematics from the College of the Holy Cross and a MS in Computer Science from Worcester Polytechnic Institute.

17 responses to “Fedora 9 and Summit preview: Confining the user with SELinux”

  1. Markus McLaughlin says:

    This was a great article to read and I am wondering if these rules will be further refined in Fedora 10, which I think will be the BEST Fedora OS yet. Provided that older WIndows (98 to XP) games can be played on WINE and multimedia won’t be ignored in that release! I still have not seen an “imovie” or an “iphoto” like software on Fedora, I am hoping someone will come up with such programs!!!

    I would like a request for an interview with the coders of Fedora 9 for my Linux Blog soon…

    Markus McLaughlin
    Hudson, MA, USA

  2. Rob Visser says:

    Interesting stuff.

    Are there any plans to have a full X-windows support with MLS turned on?
    X-windows being marked with levels. Copy paste from a low to a higher level?

    Regards,
    Rob Visser

  3. Dan Walsh says:

    Yes we are working on getting the X-Windows XACE support to work with SELinux in Fedora 10. Hopefully it will get turned on by default.

  4. Writing policy for confined SELinux users | linuxine says:

    [...] Last month, I wrote about confining the user with SELinux. I explained that–as of Fedora 9–SELinux supports the concept of the confined user and comes with 5 confined user types defined. [...]

  5. “Writing policy for confined SELinux users” - Red Hat Mag | ThomasNicholson.com says:

    [...] I found this in my security feeds yesterday.  I’m currently teaching a security policies and procedure class, from a management perspective so this is something currently on my mind.  For any of my students working with Linux here is an article about writing policies in SELinux to manage users.  The article is from Red Hat Magazine and is focused on Fedora and provides links to other articles about SELinux for those new to it. [...]

  6. Basavraj says:

    Oh yes Selinux is very secure method to apply policies to the different users in network. But I am always facing some problems in applying these policies to the different users can you suggest me how make it easy so easily apply and also give me what are the troubleshooting areas in that.

  7. Dan Walsh says:

    Basavraj, please contact me on the Fedora-list or directly with questions on SELinux. I would need to know more about what problems you are having and how you would like to confine your users.

  8. qjfselenfa says:

    Hello my friend, your site is very good! http://xmsubdjptympn.com

  9. ericdes says:

    semanage login -m -s user_u __default__
    leads to this error message:
    ——————————
    libsemanage.validate_handler: MLS range s0-s0:c0.c1023 for Unix user __default__ exceeds allowed range s0 for SELinux user user_u (No such file or directory).
    libsemanage.validate_handler: seuser mapping [__default__ -> (user_u, s0-s0:c0.c1023)] is invalid (No such file or directory).
    libsemanage.dbase_llist_iterate: could not iterate over records (No such file or directory).
    /usr/sbin/semanage: Could not modify login mapping for __default__
    ——————————

    Any idea why it fails?

  10. Dan Walsh says:

    Try:

    # semanage login -m -s user_u -r s0 __default__

    __default__ currently has an MCS/MLS range of s0-s0:c0.c1023
    but the user_u SELinux user is only allowed to use s0.

  11. ericdes says:

    Thank you, it’s working now.

  12. Aleksander Adamowski says:

    After unloading the unconfined module on Fedora 8, I cannot launch screen from the root account:

    # screen
    -bash: /usr/bin/screen: Permission denied

    What’s funny, nothing is logged even when I disable dontaudit globally using “semodule -DB”. When I “setenforce 0″, screen launches fine.

    What’s even funnier, I were able to get screen working for unprivileged users after mapping them to user_u using _default_.

    So now, although I have the most privileged context of root:system_r:sysadm_t, I cannot launch screen like the unprivileged users can.

  13. Dan Walsh says:

    I am not a big fan of sysadm_t, I call it the drunken unconfined_t, it can pretty much do anything on the system it wants but stumbles around a lot. So I would not advise removing the unconfined.pp file. I have no idea why it would not be logging to /var/log/audit/audit.log

    I tried running screen from sysadm_r:sysadm_t on Fedora 9 and it seems to work.

  14. Aleksander Adamowski says:

    The “removal of unconfined.pp” idea is from an interview with your own self (http://fedoraproject.org/wiki/Interviews/SELinux):

    “So in Fedora 8 you can setup login users to be user_t, staff_t and they can reach sysadm_t, just like in strict policy. The default user account will remain unconfined. If you want to remove the ability to run unconfined processes you can just remove the unconfined module. “semodule -r unconfined”.”

    I didn’t get the memo that it is no longer kosher in Fedora 9.

    The fact is, it’s very hard to scrap together consistent knowledge about changes in SELinux in consecutive Fedora releases.

    It’s extremely difficult to track all those changes that break backward compatibility with my custom SELinux modules. I have to gather it from all around the web (your LJ blog, interviews and Red Hat magazine articles, the mailing list and so on). The object permission macros are changing (e.g. r_file_perms -> read file perms), domains come and go, tools change in behaviour, and there’s no single place to track those – only by trial and error (when something breaks).

    Ideally it should be in the release notes for Fedora, but the SELinux section usually contains some canned information that comprises only links to trivial, incomplete or outdated information, e.g.:

    http://docs.fedoraproject.org/release-notes/f8/en_US/sn-Security.html#SELinux

    http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Security.html#SELinux

    Note that these release notes sections are identical; the last link leads to documentation that has stopped being updated in the FC5 era.

  15. Ganesh Neupane says:

    One of the great trekking to do before you dies:

    Mt. Everest, standing mightily at 8848m. Are the World’s highest peak and the ultimate Himalayan dream for many trekkers. Everest trek (with more time for acclimatization) enables you not only to witness Mount Everest but also the 4th & 5th highest peaks. Lhote at 8516m., Makalu 8467m., as well as numerous other giant peaks. This region is truly the roof of the World.
    Besides, trek goes through the heartland of the Sherpa (Mountain peoples) who are of Tibet origin and passes numerous charming villages, many with picturesque gompas that are spectacularly set amidst its mountainous surrounding. Before reaching the Everest Base camp, the trail follows the Khumbu Glacier with huge ice pinnacles soaring to unbelievable height.
    Fly to Lukla and following the Dhuda Koshi river valley through beautiful pine and rhododendron trees. The jagged, Icy & snow capped peaks of Thamseku 6623m. & Kushum Kanguru 6369m, tower above the trail. A steep climb then leads us to Namche Bazaar 3345m. Were we taking our first stop for rest (Acclimatization). Get way of Everest Base camp or Everest region for adventure trekking or climbing any peaks.
    On the trail to Thyanboche, those with a keen eye will be rewarded with sightings of musk deer, thar (Mountain goat) Impeyan Pheasant. Thyangboche monastery is set in a beautiful location with chortens adorned with player flags and mani walls a constant remainder of the local Buddhist cultural. Views of Mt. Everest 8848m., Lhotse 8516m.,Ama Dablam 6856m, Thamserku 6623m., Kangtenga 6779m., as well as many tiny mountain in this region.

    Ganesh Neupane
    Monterosa Treks and Expedition
    mail: monte@mos.com.np
    http://www.monterosa-nepal.com

  16. Dan Walsh says:

    We have hired a doc person who is working on updating all of the Fedora SELinux information. So this should change. All module changes should be carried forward r_file_perms still exists, even though the preferred method is read_file_perms. If you have a backward compatibility problems with your modules from one release to another that is a bug. But Fedora is where we do our most active and fast paste development. Red Hat Enterprise Linux is for slower more stable environment.

    I have never really supported strict policy and the move to a merge, I felt gave us the best bang for the buck.

  17. Pamela M says:

    I found your site and read a few of your other posts. Keep up the good work. I just added your RSS feed to my Google News Reader. Looking forward to reading more from you down the road!

    Great sources for my research, many thanks; I found much info to lead me on my way. Your site is about the only thing I’ve been able to find to offer guidance on this subject. Thank you for creating the web site. I hope you can help direct me toward additional information and/or places where I can find more of this info.