Joshua Brindle

How to Win At Security

Don’t disable SELinux!

A while back I wrote a post on companies telling their customers to disable SELinux in order to get applications running and why this is a very bad thing. While I don't see the situation getting better in the near term I did see a blog posting today from an SAP employee about using SELinux with SAP. This made me happy :)

Since I don't think his blog software uses trackbacks I'll be contacting him to suggest some changes. Namely he says that SAP would not be able to send SELinux policy modules with their software to customers since it apparently gets installed in many different places.

I'd first like to mention to him (and anyone else reading this) that SELinux policy does not care about paths, only types. The policy part of the module can be the same for every SAP customer, specifying the exact interactions between their software and the rest of the system. The file context part of the module is not compiled and can be generated at install time and added to the policy they distribute with the semodule_package command. After installing the module and labeling the SAP related files everything should work the same.

Next I'd like to mention that, while this is a noble effort and I'm very happy to see enterprise vendors showing their customers how they can use SELinux, this article essentially tells people to audit2allow the SAP related denials into policy without reviewing exactly what those denials were or whether they were appropriate. My status quo encapsulation article is an analysis of this style of policy writing and why it is bad.

If a SAP engineer wanted to create a policy for SAP applications that implemented proper security objectives and have that added to the reference policy I'm sure we'd be more than happy to add it in. There are other options though. IBM has been working with my company, Tresys, to develop a product, Razor, that takes generates policy for Websphere and DB2 by using configuration files that are understandable by the administrators of said applications. More information on the technique that Razor uses to create policies is available in a case study from the 2006 SELinux Symposium. This product can be used to generate policy for all kinds of enterprise applications, including presumably SAP, that implement specific security goals instead of just encapsulating the status quo of the application.

All that said, I'm still glad to see some companies taking initiative and trying to work with their customers instead of against them.