The Strengths and Weaknesses of selinux

If you use or administer Red Hat Linux or a derivative of it, such as CEntOS then you have likely heard of or come across SELinux. SELinux is not universally loved and has a reputation for being something that admins learn just enough about to turn off lest it break their system at some inopportune moment. Is this reputation fair? Should we be making the effort to learn to use it properly or is it best left on the shelf? The following is based on my own experience learning to administer selinux in preparation for the Red Hat Certified System Administrator (RHCSA) exam for RHEL7 and conversations with system administrators (and in some cases Red Hat staff) about that experience. I am not attempting to give a technical overview of SELinux here. This paper is an evaluation of the implementation of selinux as used by Red Hat and the principles they advise for its use.

In summary

This paper shows that

  • selinux is complicated (perhaps unavoidably)
  • Only some of the appropriate utilities and documentation are installed by default
  • The recommended approach is to break your system and then clean up your mess rather than to get it right first time
  • Red Hat recommend the use of tools for administering selinux that will leave the system in an inconsistent state- difficult to audit and likely to break at some future point

Each of these points is discussed in more detail below.

What did I bring to my study of selinux?

My starting position was using Linux for 15 years at home and in the cloud whilst I worked principally outside the IT field. I have compiled my own kernels, set up my own servers, etc., etc. Although I have used (Pre RHEL) Red Hat 7.3 and 7.4 long ago and used Debian for several years, these days I prefer Ubuntu (with Cinnamon). I thus have a good deal of familiarity with Linux but had not used selinux before. The RHCSA syllabus includes basic selinux administration but I found it by far the most difficult part of the course. It is not universally popular and not made available by default in all distros. Other commercially supported Linux distributions use alternative security frameworks such as AppArmor. I understand the intended purpose and that Red Hat are very keen on it. I also understand that it has a reputation for being really hard to work with and for people turning it off as a result. Basic selinux administration skills are required for an RHCSA certification however. It doesn’t actually matter what you think of selinux in this context, no skills = no cert.

First Impressions

Coming to selinux as an outsider it is clunky, finicky and inelegant. The tools and documentation are poorly named with a view to even finding the man pages and mostly not installed by default. There are bits and pieces of it in scattered different places with different naming paradigms. It’s a mess frankly. For all the complaints about systemd for example, it is reasonably consistent and well documented by default. I initially doubted that people who actually want to get stuff done have time for this and felt that surely a lot of the goals of selinux could be accomplished with stuff like chroot and containerisation. One thing that became quite clear to me from conversations with other knowledgeable people is that people typically see selinux as an all or nothing proposition. There was little nuanced discussion pitching it against, say apparmor or grsecurity. I haven’t administered apparmor but Suse and Ubuntu both support it by default instead of selinux and I wouldn’t write Suse off as anything less than a serious distro- for example the New York Stock Exchange runs on Red Hat, The London Stock Exchange runs on Suse.

What is selinux?

Selinux is not something that can be described briefly. Red Hat’s own introduction can be found here Perhaps the most useful paradigm is thinking of it as a framework for managing access control- to files and other resources- in Linux that go far beyond standard file permissions or aces control lists.

Is selinux really that complicated?

The short answer would be yes! Although this is perhaps unavoidable since it does so much. Red Hat do realise the reputation of selinux being complicated. When I was trying to get my head around it a lot of people referred me to Thomas Cameron’s presentation ‘Security-enhanced Linux for mere mortals - 2015 Red Hat Summit’ and accompanying slides. This is 50 minutes long and basically the same presentation as he gave on the topic in 2013. For a response to the naysayers that RH concede that selinux is complex, or that this was only true many years ago, Thomas says in this:

  • Slide 16 at 7:25 in video: Multi Level Security is ‘out of scope’ for a 50 minute introductory presentation and ‘[selinux] Can be very complex’
  • Slide 205 at 49 minutes: It’s much easier to use SELinux today than it was just a few months ago

These AREN’T arguments against using selinux but they do show that RH realise the reputation, whether you think it deserved or not. It’s possible to explain other frameworks like, e.g. ACLs, completely in much less time than selinux. From even an expert admin’s point of view, reviewing a given installation for compliance to a specific policy set can be pretty tedious.

A worked example

Some people have suggested that it’s not that difficult to use audit2allow or semanage etc. and I think for me this really underlines the problem the problem for me with selinux. Let’s consider a scenario: Scenario: set sshd to run on a custom number port, lets say port 443 to deal with port blocking for clients on public Wi-Fi networks

  1. Edit /etc/ssh/sshd_config to set new port
  2. systemctl restart sshd

Variation One:

By default at this point sshd won’t work and it won’t tell you why. If you want to use setroubleshooter; sealert; semanage; audit2allow etc. then you have to install these tools. There are problems with this: First the names for the packages containing these tools: policycoreutils and policycoreutils-python. These are non obvious and not clearly linked to selinux (yes I know about yum whatprovides). I would really question (some of) them not being installed by default, especially on ‘server with graphical desktop’. Secondly and more seriously in my view, this is remedial - you are expected to ‘break’ your system and then review the error. Not especially useful if you can only connect to your box on ssh in the first place. Yes you can set selinux to ‘permissive’ but this is not the default and of course all of the time that you are doing that, selinux is not doing anything.

Variation two:

Let’s suppose that I decide to implement some quality management and do the job right the first time, rather than making a mess and clearing it up again. Should be easy no? Well actually not really. Yes I can use the GUI policy tools in advance, if I have GUI available. Let’s be traditional and assume I have just command line. sshd is a basic server application provided by the distro right? And selinux is ‘enforcing’ by default. So let’s look at the man pages- which aren’t there for this scenario. Here’s what you need to do according to Sander van Vugt in his RHCSA/RHCE RHEL 7 book (substitute ‘sshd’ for ‘httpd’):

Exercise 21.3 Installing SELinux-Specific Man Pages

  • Type man -k _selinux. You’ll probably see just one or two man pages.
  • Type yum whatprovides */sepolicy. This shows you the name of the RPM that contains the sepolicy binary, which is policycoreutils-devel.
  • Type yum -y install policycoreutils-devel to install this package….
  • …. Type man -k _selinux | grep http to find the man page that documents SELinux settings for the httpd service and scroll through it. Notice that it is a complete list of all that you can do with SELinux on the httpd service.

One can then man sshd_selinux | grep port to find out how to do it right before getting it wrong. Never mind that by default RHEL 7.0 has all its man pages installed but not indexed, neither saving space nor making it easier to use the system – this seems to be fixed in 7.2 and onward – hence break in above quote. The user wanting the proper selinux documentation available is expected to install dev libraries for a non-obviously selinux related package and manually install the relevant man pages. Clearly this is not intended to be a mainstream scenario. In either variation you need to install non default packages to address the issue

Many people suggest using either audit2allow with restorecon and/or chcon to deal with selinux access violations, especially after reviewing them with sealert. For example, in his much-referenced (in previous thread) presentation ‘Security Enhanced Linux for mere mortals’ from June 2015 Red Hat Summit, Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX, references chcon twice: Slide 49: How Do I Deal With Labels? _You can use SELinux aware tools like chcon or restorecon to change the context _of a file (more on this later). Slide 121 (discussing referencing a known-good file): Real World Examples Use that information as arguments for the chcon (change context) command

How well do these tools work?

Thomas Cameron doesn’t mention audit2allow here but the other 2 tools (chcon and restorecon) work against each other. Consider the following written by Sander van Vugt in ‘Red Hat RHCSA/RHCE 7 Cert Guide: Red Hat Enterprise Linux 7 (EX200 and EX300) (Certification Guide)’

Setting Context Types

You can use two commands to set context type:

  • semanage: This is the command you want to use. The semanage command writes the new context to the SELinux policy, from which it is applied to the file system.
  • chcon: This command is for use in specific cases only and normally should be avoided. The chcon command writes the new context to the file system and not to the policy. Everything that is applied with chcon is overwritten when the file system is relabelled, or the original context is restored from the policy to the file system. Do not use this command!

Note: You might want to know why, if you should not use it, that I mention it. Well, you’ll often see the chcon command still being referred to in the documentation, which might give the impression that it is a useful command. It is not, because if your file system is relabelled, all changes applied with chcon are lost. File system relabelling actions can take you by surprise if you are new to SELinux, and you will fail your exam if by accident a file system relabelling is happening on a file system where you have applied SELinux context with chcon. So, I repeat: Do not use it.

Tip: The semanage command is not installed by default. Fortunately, there is yum whatprovides. Type yum whatprovides */semanage to find the RPM containing semanage, and then install it.

It doesn’t take very long to show empirically that Sander is correct regarding chcon, e.g. change the document root for apache, use chcon on the new directory to get it working, then restorecon and it’s goodnight Vienna. Thomas Cameron references semanage only briefly in his presentation- in slides 51 and 52 in overview and with a single ‘Real World Example’ from slide 155. He doesn’t mention that it may not be available in a default install, e.g. on a new CentOS 7.2 system:

#cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
#yum whatprovides semanage
policycoreutils-python
#yum groupinfo core | grep policycore*
policycoreutils
#yum groupinfo base | grep policycore*
<nothing>
#yum groupinfo Server\ with\ GUI | grep policycore*
<nothing>
#yum whatprovides sealert
setroubleshoot-server
<Not included with any of the default groups>

Strangely semanage and audit2allow do appear to be installed on this system although sealert does not

Conclusion and recommendations

The documentation needs to be installed by default! As do some of the management tools People saying ‘read the documentation’ (or the Fedora documentation) are somewhat missing the point- in the setting of an RHCSA exam and many production environments you only have distro default install/media and repos. It’s great that the documentation is available for Fedora, I’m sure I can Google it too. It needs to be installed in RHEL systems, by default. Returning to my earlier scenario of changing the default port for ssh server: I’d really like to hear an adequate justification as to why when I select a ‘server’ installation, selinux is present and enforcing by default and sshd is present by default along with the vanilla sshd man pages BUT the sshd_selinux man pages are not and I have to mess about installing dev packages and policy tools myself. How is this OK? It’s not uncommon to have ssh as the only route of admin communication to a server. The man pages and tools for chmod; setfacl; etc., are installed by default and I would be expected to set attributes correctly the first time using these tools. This is true even when ACLs aren’t in use or even when they can’t be used on a given system. The appropriate tools should be recommended and caveats emphasised for those that generally aren’t appropriate Red Hat’s own top representatives, together with the majority of common wisdom advise the use of tools to administer selinux that effect an inconsistent state (variation between actual context and policy) that;

  • Makes the system difficult to audit effectively for compliance to policy (both selinux and corporate policy)
  • Is liable to break the system on use of restorecon or other relabelling operation such as the text book example of resetting the passwords on a system where the root password has been lost.

I’m not disputing that there are valid use cases for chcon but I cannot see that a non-persistent change will be useful in the majority of cases. RH are keen to point out the -P flag for setsebool but there is no equivalent flag for chcon. Why are they not promoting the use of semanage or at least pointing out that chcon is not persistent? The problem with the paradigm Selinux is intended to be used by people with separate testing and production environments with the expectation that people will deliberately create a problem and/or break their system, then ‘switch off’ selinux to fix the mess, using non default installed tools, before switching it back on on their testing system and rolling out to production. Of course whilst selinux is in ‘permissive’ mode (e.g. for audit2allow), the box is not protected. This to me is the core issue- with an attitude like this, selinux is always going to be seen as problematic and/or unnecessary- because the expected route is to create problems and treat selinux as unnecessary -‘hey you can just switch it off whilst you work out how to fix it’. A sensible system would not expect users to turn it off to fix it in this way and would encourage people to do things right in the first place. Nobody turns off standard file permissions or ACLs for instance When even the world masters (as in master teachers) for selinux are advising a remedial approach rather than a quality one, we cannot be surprised that it’s seen as a source of problems. It should be encouraged and expected to do it right the first time rather than mess up (deliberately) and correct after the act. One can only hope that selinux (or it’s successor framework) address the issues of implementation and approach described here for future versions.

Get in touch