SELinux's problem of keeping up with general Linux development

July 14, 2017

Fedora 26 was released on Tuesday, so today I did my usual thing of doing a stock install of it in a virtual machine as a test, to see how it looks and so on. Predictable things ensued with SELinux. In the resulting Twitter conversation, I came to a realization:

It seems possible that the rate of change in what programs legitimately do is higher than the rate at which SELinux policies can be fixed.

Most people who talk about SELinux policy problems, myself included, usually implicitly treat developing SELinux policies as a static thing. If only one could understand the program's behavior well enough one could write a fully correct policy and be done with it, but the problem is that fully understanding program behavior is very hard.

However, this is not actually true. In reality, programs not infrequently change their (legitimate) behavior over time as new versions are developed and released. There are all sorts of ways this can happen; there's new features in the program, changes to how the program itself works, changes in how libraries the program uses work, changes in what libraries the program uses, and so on. When these changes in behavior happen (at whatever level and for whatever reason), the SELinux policies need to be changed to match them in order for things to still work.

In effect, the people developing SELinux policies are in a race with the people developing the actual programs, libraries, and so on. In order to end up with a working set of policies, the SELinux people have to be able to fix them faster than upstream development can break them. It would certainly be nice if the SELinux people can win this race, but I don't think it's at all guaranteed. Certainly with enough churn in enough projects, you could wind up in a situation where the SELinux people simply can't work fast enough to produce a full set of working policies.

As a corollary, this predicts that SELinux should work better in a distribution environment that rigidly limits change in program and library versions than in one that allows relatively wide freedom for changes. If you lock down your release and refuse to change anything unless you absolutely have to, you have a much higher chance of the SELinux policy developers catching up to the (lack of) changes in the rest of the system.

This is a more potentially pessimistic view of SELinux's inherent complexity than I had before. Of course I don't know if SELinux policy development currently is in this kind of race in any important way. It's certainly possible that SELinux policy developers aren't having any problems keeping up with upstream changes, and what's really causing them these problems is the inherent complexity of the job even for a static target.

One answer to this issue is to try to change who does the work. However, for various reasons beyond the scope of this entry, I don't think that having upstreams maintain SELinux policies for their projects is going to work very well even in theory. In practice it's clearly not going to happen (cf) for good reasons. As is traditional in the open source world, the people who care about some issue get to be the ones to do the work to make it happen, and right now SELinux is far from a universal issue.

(Since I'm totally indifferent about whether SELinux works, I'm not going to be filing any bugs here. Interested parties who care can peruse some logs I extracted.)

Comments on this page:

Interesting comments Chris.

I would be interested in up stream app developers publishing things about their application, including what it should be doing. This information would probably make it much easier for SELinux maintainers to keep the applicable SELinux policies up to date.

Aside: I'd like to see the same for network traffic and web methods & URLs. I think that the same type of information could be consumed by firewall administrators and WAF administrators. - All for very similar reasons.

By Anon at 2017-07-19 02:45:33:

I also agree the only way this scales is if upstreams are the ones maintaining the policies. What you ideally need is some declaration of "my program does this" which is abstract no matter what security system you use (Linux's SELinux, Apparmor, OpenBSD's pledge, FreeBSD's capsicum) and creates some lowest common denominator starting point. The problem is some of these systems involve the program doing things itself so aren't really compatible with the others...

By cks at 2017-07-19 08:33:37:

I don't think upstreams can do this well even in theory (and if we can do this at all), for two reasons. First, what a program does is actually a composite from multiple sources: the program, the libraries it uses (and their specific versions), the compile-time options used to build all of the code (including library versions in use), and even configurations made on the local system to things like /etc/nsswitch.conf. Upstream knows about only one of those. Second, without a way of completely verifying these assertions of program behavior, you're asking upstream to write what are essentially a form of code comments with all of the issues that that implies.

(I wrote a longer version of this here.)

Written on 14 July 2017.
« Understanding the .io TLD's DNS configuration vulnerability
Link: ZFS Storage Overhead »

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

Last modified: Fri Jul 14 01:19:14 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.