One of SELinux's important limits

July 23, 2014

People occasionally push SELinux as the cure for security problems and look down on people who routinely disable it (as we do). I have some previously expressed views on this general attitude, but what I feel like pointing out today is that SELinux's security has some important intrinsic limits. One big one is that SELinux only acts at process boundaries.

By its nature, SELinux exists to stop a process (or a collection of them) from doing 'bad things' to the rest of the system and to the outside environment. But there are any number of dangerous exploits that do not cross a process's boundaries this way; the most infamous recent one is Heartbleed. SELinux can do nothing to stop these exploits because they happen entirely inside the process, in spheres fully outside its domain. SELinux can only act if the exploit seeks to exfiltrate data (or influence the outside world) through some new channel that the process does not normally use, and in many cases the exploit doesn't need to do that (and often doesn't bother).

Or in short, SELinux cannot stop your web server or your web browser from getting compromised, only from doing new stuff afterwards. Sending all of the secrets that your browser or server already has access to to someone in the outside world? There's nothing SELinux can do about that (assuming that the attacker is competent). This is a large and damaging territory that SELinux doesn't help with.

(Yes, yes, privilege separation. There are a number of ways in which this is the mathematical security answer instead of the real one, including that most network related programs today are not privilege separated. Chrome exploits also have demonstrated that privilege separation is very hard to make leak-proof.)

Comments on this page:

By Ewen McNeill at 2014-07-23 02:33:49:

It seems to me there's a reasonable analogy with "firewalls only act at network boundaries": the result of the near ubiquitous deployment of system/enterprise firewalls is that systems mostly get compromised by means other than unexpected connections from the Internet (eg, application vulnerabilities -- including things like Heartbleed).

Yet at this point I think few would argue that packet filtering is not a good idea. (There are some who very vigorously argue that stateful firewalls are not a good idea, with considerable merit in some situations -- state exhaustion is a real thing. But IME even they are generally in favour of stateless packet filters.) It doesn't solve everything, but it does reduce the attack surface (at least from the "outside" -- crunchy outside, and soft chewy centre :-) )

Ultimately I want to like technology like SELinux. And do try to leave it (or AppArmor, etc) enabled on systems unless it becomes infeasible to persuade it to let legitimate users do legitimate things. But I do wish it wasn't seen as a cure all (and was even easier to manage...). It will help with some problems (particularly digging further into the system than the toe hold). But not everything. I look at it as a "process firewall".


PS: See also Docker and SELinux -- unlike what some people apparently believe root in a Docker environment isn't completely isolated, even with SELinux.

By Zev Weiss at 2014-07-23 16:06:57:

While for the most part I'd agree, there do exist some things SELinux does that are "intra-process" (if you will), such as the execstack/execmem restrictions.

Written on 23 July 2014.
« What I know about the different types of SSH keys (and some opinions)
What influences SSH's bulk transfer speeds »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jul 23 00:24:23 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.