LISA 2009: Rik Farrow on Working with SELinux

LISA 2009: Rik Farrow on Working with SELinux
By Matthew Sacks

Rik Farrow is a security trainer as well as the Chief Editor for USENIX’s ;login magazine. He is delivering training on SELinux at LISA 2009 and spoke with the USENIX Blog Team about his background and the upcoming SELinux training he will be delivering at LISA 2009; Working with SELinux
http://www.usenix.org/events/lisa09/training/tutonefile.html#m8

Q: Rik, please tell us a bit about your technical background.

Rik Farrow: I began working with UNIX systems in 1982, and became interested in UNIX security in 1984. In 1987, I began teaching UNIX Security classes and was doing so internationally by 1989. I focused on security training from 1994 to 2006, a business that involved way too much travel. In 1999, I created a course for internal use by the NSA.

While my major in college was psychology, I worked for my advisor as a lab tech and a programmer. I really got involved with computers a few years after graduation, as soon as microcomputers made it possible to own my own computer. By 1980, I was a self-employed computer consultant, doing some programming and manual writing at first. By the mid-80s, I was consulting in UNIX sysadmin and security.

I was also the technical editor of UNIXWorld Magazine from 1989-1994, and started editing special editions of USENIX ;login: in 1998. I have written hundreds of magazine articles, most about security, as well as two UNIX-related books.

Q: What inspired you to deliver training on SELinux at LISA?

Rik Farrow: I had a contract where I was building a Linux system for installation in a remote site. The system involved using XEN, and when something didn't work, the first thing I did was disable SELinux. I did this based on advice I found on the 'net.

I later found myself wondering why people considered disabling SELinux a useful first step. It didn't help with my problem at all. So I began to investigate.

I also had some minor involvement in getting SELinux integrated into the Linux kernel. During the first Linux Kernel Developers Summit, I spent a lot of time with Peter Loscocco, one of the key developers of SELinux at the NSA. Loscocco wanted SELinux to become a part of the default Linux kernel, and Torvalds was not interested, but wanted a more flexible set of hooks instead proposed by Crispin Cowan. I encouraged Loscocco to go along with this scheme, which later became Linux Security Modules (LSM).

Q: Why is SELinux a good choice for securing Linux systems?
Rik Farrow: SELinux is one of three popular policy engines that work with LSM. There are others, such as AppArmor (in SuSe and Debian) and LIDS, but SELinux is the most widely used. Because of its 'popularity', there is a lot more support for SELinux.

SELinux provides strong isolation for many services and applications. The pre-packaged policy modules do this well out of the box But SELinux alone is not sufficient protection. You still need to practice good security practices, for example, use of strong passwords, proper file/directory ownership/permissions, and patching.

Q: Is SELinux difficult to implement properly?

Rik Farrow: SELinux works well if you stick with the default policy. The default policy is called the targeted policy and focuses on sandboxing services and troublesome applications. You can also download and use the strict policy, but doing so is a lot harder. The targeted policy allows logged in users a lot of flexibility, while the strict policy locks down users as well.

Q: What benefits does a system administrator get by using SELinux?

Rik Farrow: Exploitable bugs in applications are minimized. For example, suppose someone discovers a new bug in BIND's named that allows shell execution. SELinux prevents named from executing /bin/sh, as well as prohibiting reading and writing any files outside of the few files required by normal named functioning. The same is true for sendmail and many other services.

SELinux also confines the Apache httpd, but the problems with Web servers most often have to do with bugs in applications that interface with Apache. For example, the recent exploits in the Wordpress blogging software would have been severely limited in scope by SELinux. But an attacker using an SQL injection attack would still be able to access a backend database, as this permission must be granted by SELinux so the Web server and database can work together. So there are limitations to what SELinux can do, limitations based on allowing an application to work without interference. SELinux can and does prevent applications from doing things they are not normally expected to do, such as execute shells, read or write files outside of the application, etc.

Q: What are some highlights of interest covered in your training?

Rik Farrow: The focus of the course is really making it easier to work with SELinux. Doing so relies largely on fixing problems with file context, something that can be done with chcon and semanage. I also show how audit2allow is used to patch policy in a safe manner. Getting to the point of being able to do these things involves understanding enough about how SELinux works, as well as a little bit of necessary terminology.

I've spent a long time working with UNIX security, some 25 years. This helped me understand both how SELinux works, as well as how best to explain how it works.

Fedora SELinux Home: http://fedoraproject.org/wiki/SELinux

Rik Farrow’s Web Site: http://rikfarrow.com/

Register For LISA 2009: http://www.usenix.org/events/lisa09/registration/