Interviews/SELinux

SELinux

We all appreciate that when we turn on our Linux systems they're pretty secure. Thanks to continuing improvements to SELinux, it is increasingly easy for users to take advantage of this powerful security tool. Read on to find an interview with Daniel Walsh, the principal developer of SELinux in Fedora from Red Hat, where he tells us more about what SELinux does and how it's improved in Fedora 8. Also included are some screenshots which show-off the new policy creation GUI.

Digg it

If you enjoy this article, consider giving it a digg :D

http://digg.com/linux_unix/Easier_security_in_Fedora_8

Screenshots

File:Interviews SELinux SELinux-config.png

SELinux's improved system-config interface

File:Interviews SELinux SELinux-Policy-GUI.png

SELinux's brand-new policy creation GUI

References

• http://fedoraproject.org/wiki/Security/Features
• http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/

Developer Interview

#!html
<div style="float: right; background: #eeeff1; border: 2px solid silver; padding: 1em; margin: 1em">

Daniel Walsh

Location: Westford, MA

Profession: Principal Software Engineer, Red Hat

IRC Nick: dwalsh

Age: 46

Blog: http://danwalsh.livejournal.com

Interviewed by: JonathanRoberts

#!html
</div>

To start, if you could explain to us the major benefits that using SELinux delivers? We all know it's a security feature with a pretty fantastic reputation, but how does it work?

Standard UNIX access control has rules that define what a user can do, on objects like files/directories and devices. The user has discretion over objects that he owns, he can change the the permissions on a directory to world writable. All applications that a user owns inherits all the rights of the user. This includes the root user, so applications that are run by root can do everything that root can do on the system. SELinux allows you to define rules about how an application can run. It defines all the access rules that are required by an application and no more. For example you can define rules that say a particular apache script can only read/write files in a certain directory, and if the cgi script has a bug and can become compromised, the kernel will prevent the process from doing anything but reading and writing the directory. SELinux can control access to files/directories/devices/network ports other forms of IPC.

During the Fedora 8 release cycle, quite a lot of work has gone into SELinux; perhaps one of the most visible developments is the new policy generation GUI. Could you describe to us what this will allow users to do; what work went into creating it; and whether or not this feature will be available upstream for other distributions to use?

We have made major enhancements to system-config-selinux including the addition of the selinux-polgengui, This tool allows you to generate a SELinux policy framework. It attempts to generate the most common policy for your particular domain. It is a wizard that will ask you a series of questions, and generate you the files necessary to build policy as well as a script to compile, build and relabel the application you are trying to confine. Once you have written your policy template, you can run tests to generate AVC messages, then you can use the enhanced version of audit2allow to generate additional policy rules. This enhanced audit2allow takes AVC messages and searches through the reference policy interfaces for a better match. This makes for better policy and simplifies the process.

Another of the new features coming to SELinux for Fedora 8 is the ability to lock-down user accounts. What particular use cases will benefit most directly from this?

In Fedora 8 we have combined the features of strict policy with targeted. Up to now there have always been three policies, targeted, strict, and MLS. Targeted was the default, and its goal was to lock down network facing daemons, and pretty much matched strict policy for confining all apps that are run by the system. Strict policy also could confined users. MLS policy is used by certain parts of the government for guarding information flow. Preventing Secret Processes from reading Top Secret data.

In Fedora 8 we have combined strict and targeted policy so that you can run confined users along with the unconfined users. 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".

When I worked on the merge, I also looked to create new user types. I call them the guest and xguest users. These are the least privileged users you can have on a system. guest_u SELinux user is a user account that can not run any Setuid applications, can not communicate on the network, can not execute files in its home directory or /tmp, and it can not use XWindows. So why would I want guest? Well I see this user being used on accounts, where you allow a user to ssh and configure their public_html account, or only run a single application like a git user account. xguest_u is similar to guest_u except it can work on an Xwindows machine. I have designed xguest_u to be useful in a kiosk environment. You can set up a xguest account to allow users to login without a password and then use the machine. The user account can not run setuid apps, can not connect to the network, except through Firefox. The account can not execute files in the home directory.

The policy generation tool defined above has the ability to create additional user types based off the guest and xguest types. So if you want to setup a guest account that can only send mail, you would use the tool to generate policy for an xguestmail_u user account and add the ability to connect to port 25.

Similarly if you wanted xguest to be able to chat you could define a user account xguest_xchat_u which could connect to port 194.

One other feature that is significant in SELinux this time around is the power to separate root access; could you explain to us exactly what this means?

Finally Fedora 8 is introducing the concept of confined root user accounts. So you can define policy for a web administrator. When you could login to a machine as guest account and then use sudo to become root, but when you were root, you would only be able to admistrate files/directories owned by httpd. Watch http://danwalsh.livejournal.com for more info on this for descriptions on how to do this.

Are you happy with the way development has gone during this release cycle? Are there more changes/developments you'd like to see get integrated into later releases?

The number one new feature I am looking to add to Fedora 8 is the xguest package, which will setup a machine to run as a kiosk. This package will not only setup the xguest_u account described above but adds additional safeguards such as a temporary home directory and temp directories, which get destroyed on logout. Preventing someone from reading information left by you, or leaving an application to watch the next person to use the kiosk. I envision setting up a livecd image with this that could be used at libraries, universities, coffee shops ...

In Fedora 9 we want to work on simplifying the policy. I would like to see better handling of redirection of standard in/out. We plan on adding the concepts of the permissive domain. This will add a command to allow users to turn off the enforcement of policy on one domain (process) rather then entire system. This enhancement will allow creation of policy modules without having to put the machine in permissive mode, and allow people to ship their policies into the production without having to worry about them blocking a critical feature, Then after running the app in the permissive domain for a couple of months and fixing all the avc's you could feel confident turning the domain back to enforcing.

We want to add a lock down wizard mode to the GUI so it can walk you through locking down booleans to make the machine more secure, and potentially executing security STIGS.

Finally, if you could tell us a little bit about yourself? How you became interested in free software originally? What you like to do with your spare time!?

I have been working in Software and Unix for the last 25 years or so. I have been at Red Hat for the last 6 years. I have been interested in open source since I worked at Digital Equipment and used a lot of the GNU tools for development. The first time I had a bug and someone submitted a fix for it, I was hooked. Developing software in a community is the best way to develop software. SELinux has a large community of developers in industry, government, university and in the public. Although were always looking to expand the community.

In my spare time, I enjoying coaching my kids in sports and following sports teams. I am an avid Boston Sports Fan. And with the Red Sox, Patriots and hopefully the Celtics, I have a lot to be happy about.