Do you use SELinux?

Latest response

Coming from a long history of using Red Hat Enterprise Linux (RHEL), I have seen SELinux grow. Like many, my first entrance into it was in RHEL 4. Needless to say, I would simply disable SELinux and move on my merry way. Over the years though, I have realized the need for better host-based security methodologies, and using all the tools I can to better protect my assets. This is why I took another look at SELinux. I found many great resources through the Red Hat customer portal by searching for videos on SELinux. There are some great ones by Dan Walsh and Thomas Cameron.


My question for this particular discussion is "Do you use SELinux?"


If so, what are your impressions? If not; what are the blockers you see to implementation?


It's Disabled on our older systems because production came off HP-UX and we thought "traditional" permissions were adequate since (A) SELinux was a bit new and shiny at the time, and (B) the systems are isolated on a restricted LAN, and (C) we didn't have any man-hours or expertise do deal with any down-side.  It's in Permissive mode on current systems to see what messages get generated and determine if it shows any signs of getting cross-wise with Oracle or WebLogic and such.  If no troubles appear then maybe next year some time...


The videos are very helpful.

SEL is great in theory. And, it's a good option when you're running applications that were specifically-designed with SEL in mind. However, trying to make a non SEL-aware application work, absolutely bug-free, can more than double the length of time it takes to qualify that application for production networks. Worse, when you inevitably encounter something that didn't crop up in the pre-deployment qualification process, the application vendor's first statements (once they realize SEL is involved) is generally something to the effect of  "not supported under SEL" or "you need to turn off SEL before we can proceed with this support case". 


One thing that would help our organization with SEL would be if future RHEL releases included a enterprise-grade, SEL-aware replacement for winbind. The winbind in RHEL 5 just doesn't cope well with large, multi-domain AD forrests with hundreds of thousands of objects. That leaves us having to implement third-party AD-integration solutions, few of which are supported under SEL. Since AD integration is a far higher priority for us than SEL, SEL gets disabled on any of our systems that leverage the non SEL-aware AD-integration solutions.

We integrate RHEL with AD via the IPA stack.

Phase 1 is being rolled out right now (IPA as drop-in replacement for Fedora Directory Server).  Phase 2 will be to create trust relationship between AD & IPA once that functionallity is released in Jan/Feb time.

The IPA wins for us are centralised sudo, keys/certs and SELinux policy management - all whilst eventually linking direct back to AD for single sign-on.

As a practice, I use SElinux.


The only time I have not made SEL work is using Veritas File System to host iSCSI targets. (this was early 2012 - that issue may be resolved now).


I still occassionally get "stung" - but checking for SEL exceptions has become a pretty standard troubleshooting task ;-)

This sounds like a bridge-server type solution (standing up a server to act as an intermediary between a set of data consumers and the primary data-source). That is "ok" in smaller environments, but when you're in a really large, distributed (especially the distributed part) environment, the prospect of doubling-up your naming-service infrastructure makes the approach a non-starter.


In the environment I work in, we have AD clusters servicing datacenters all over the world. They're distributed to provide reliable lookup to clients that are frequently connected via unreliable or slow links. They're clustered at each site so as to ensure that, even if both the link and one AD server is down, clients still have something to auth against. Yes, clients could be configured to cache authentication data so as to be more resilient against blackouts of the auth-sources, but our security folks generally frown on that. To service RHEL clients at those distributed sites, I'd have to stand up not only a cluster of "real" AD servers, I'd have to stand up a cluster of IPA servers. That's not a solution that's easy to sell to management, especially if the site doesn't have a virtualization stack to leverage.


While we could move to using something like Centrify, which does work with SEL, if we were to switch off our current AD-integration tool, we'd really rather switch to a native authentication mechanism. We'd tried using the native winbind, previously, but it failed at both SEL and our scalability requirements.

Just a quick query: are you primarily using `audit2allow` for that or are you hand-cranking your policies? If using `audit2allow`, what do you do to ensure that the rules it creates aren't overly-broad? One of our primary concerns with `audit2allow` was that it could end up creating overly-broad exceptions. This was of particular concern with respect to activities by the  more-junior staff (or our hosted clients that had root-privs). The concern being that users of the method might not understand or think to look at the full ramifications of their actions (Google's great, but, often times, people go so far as to learn the quick-fix/workaround without doing the full due-dilligence to ensure that they haven't rendered their security system toothless).

In general , I enable auditd and then I would review /var/log/audit/audit.log.  I then take the suspected exceptions and create a new file and then (like you mentioned) I use audit2allow if I was to create new rules to allow exceptions.  I understand that I am more fortunate than others in that regard.


Fortunately I do not deviate too far away from the expected setup and therefore resolving issues is not terribly demanding.  But you touched on a very important point.. if you are making "custom" or non-standard exceptions, it requires that the people on your team know how to review the contexts, rules, etc.. and why the exceptions were cretaed.  So - in a nutshell and as a genera rulel, I like to use the auditd to identify issues and then update my system to work within the existing rules (rather than modify the defaults).  It would be interesting to get perspective from admins that are in shops that HAVE to actually manage the SElinux with exceptions and some of their experiences with gotcha's. ;-)

Yeah, my responses across this thread-heading are based on a desire to use SEL but trying to find a way of doing so in an environment that can quickly get out of control.


On the face, SEL is a good thing. It just comes down to, if you implement it, how do you implement it in such a way that: A) all the applications you need to host will work fully, correctly and supportably; and, B) how do you educate all the people that have root (the joys of being a hosting environment) such that they don't render the framework meaningless? It's great to be able to tick a box on  a certification sheet that says "SEL enabled" but if someone's hollowed-out its protective capability, all that ticked-box does is give you a false sense of security.

I think you make a fantastic point (that has been echoed through many posts on SELinux I have read) regarding the education of users on how to USE SELinux to it's full capabilities. I know it was mentioned once before, but I'll go ahead and pop a link here for ease of use. One of the best places I have found for some quick educational resources is in the videos provided on the customer portal. Some of the best ones are by Thomas Cameron and Dan Walsh, but your milage may vary.


I find that once that light-bulb goes of regarding the basics of SELinux, most people are a little more receptive to using as intended, instead of just green-lighting everything. That being said, there is still that other big hurdle of supportability with third party application developers who do not supply adequate policies (if any at all) for their applications to work in an SELinux protected environment.



I like that approach to validation of usability with SELinux. Are you finding many instances where it's failing in your environment? Have you taken the time to try and implement custom policies to address any issues you are finding in your audit log?

I'm happy to say that all I've seen were some warnings caused when a DBA moved a configuration file around.  There has been nothing significant at all.  The audit messages are nice, with the inclusion of a GUID tied to the event that leads the way to a relabel or other corrective action.  Nice-- it knocks down the learning curve.