Chris's Wiki :: blog/linux/SELinuxBeyondSaving

SELinux is beyond saving at this point

May 25, 2016

SELinux has problems. It has a complexity problem (in that it is quite complex), it has technical problems with important issues like usability and visibility, it has pragmatic problems with getting in the way, and most of all it has a social problem. At this point, I no longer believe that SELinux can be saved and become an important part of the Linux security landscape (at least if Linux remains commonly used).

The fundamental reason why SELinux is beyond saving at this point is that after something like a decade of SELinux's toxic mistake, the only people who are left in the SELinux community are the true believers, the people who believe that SELinux is not a sysadmin usability nightmare, that those who disable it are fools, and so on. That your community narrows is what naturally happens when you double down on calling other people things; if people say you are an idiot for questioning the SELinux way, well, you generally leave.

If the SELinux community was going to change its mind about these issues, the people involved have had years of opportunities to do so. Yet the SELinux ship sails on pretty much as it ever has. These people are never going to consider anything close to what I once suggested in order to change course; instead, I confidently expect them to ride the 'SELinux is totally fine' train all the way into the ground. I'm sure they will be shocked and upset when something like OpenBSD's pledge() is integrated either in Linux libraries or as a kernel security module (or both) and people start switching to it.

(As always, real security is people, not math. A beautiful mathematical security system that people don't really use is far less useful and important than a messy, hacky one that people do use.)

(As for why I care about SELinux despite not using it and thinking it's the wrong way, see this. Also, yes, SELinux can do useful things if you work hard enough.)

Comments on this page:

By dac.override at 2016-05-25 09:09:08:

SELinux just celebrated its 15th anniversary. Android decided to adopt the technology and is actively contributing to the project.

SELinux has problems, Yes. It is misunderstood. Considering what it does, SELinux the framework, is remarkably simple.

People generally do not complain about SELinux, they complain about how it is used to enforce often complex security policy, generally designed and written by third parties. One distribution decided long ago to take advantage of SELinux by enforcing their policy onto customers systems. They thought that they would be able to bring SELinux to the masses by maintaining the security policy on their behalf. That is a very difficult, and somewhat unrealistic but noble goal. Considering the circumstances they did a good job, but it is not good enough in my view. It gives the framework a less-than-optimal reputation.

I now also believe that no or a very small, non-intrusive policy should be implemented instead with a focus on providing a base to take away the barrier of entrance to the extent possible for people that do want to take advantage of this fine technology, and to not stand in the way of the audience that truly does not appreciate SELinux.

The problem is not SELinux, the problem is the security policy that SELinux enforces. If you have not designed it then it is very hard to understand it and to work with it. In Android you are not "allowed" to work with it, but in GNU/Linux you have to be able to work with any policy enforced by default or you have to remove the policy so that SELinux disables itself.

Essentially it is just a matter of disabling SELinux or use the framework to enforce your own policy so that it can be as simple or complex as YOU want.

I believe that your beef is not with SELinux the framework, but instead with how a certain distribution decided to use it. SELinux itself will not do anything unless you tell it to by feeding it instructions.

Another issue with SELinux was its userspace component. It had many real usability issues. A new policy compiler and policy language was developed to address these issues (SECILC/CIL). This is a big improvement for the audience that actually uses (not merely tolerates) SELinux. Unfortunately, few currently take advantage of these improvements.

I am defending SELinux the framework, and not a certain distribution. I think that this distribution should rethink its strategy and I expressed that on the official mailinglist. It is probably too late for this since now they rely on SELinux policy to enforce additional security for various products other than Linux (svirt, openshift, docker etc etc)

Push comes to shove though, Just disable it if you do not want it, and move on.

By Kevin Beranek at 2016-05-25 10:57:10:

Speaking of pledge on linux, I just came a cross a brand new effort attempting exactly that: https://notabug.org/rain1/linux-seccomp-pledge/

By Twirrim at 2016-05-25 12:42:50:

I would love to see something like SELinux become useful and practical.

The theory is great. The implementation isn't. Amongst many of the hassles involved with it, it's still, 15 years on, possible to have SELinux silently block operations. I've seen it happen in the last week, and I've fought it every time I've tried to give SELinux the good ol' college try. I'm not sure how it's possible to have logging not be so integral in the blocking process in the application to the extent where that is even possible, but it has somehow been managed.

I don't mind things being blocked, per se, I do mind if you do it silently. That results in days of wasted time trying to fix bizarre and unexpected behaviour.

By AJ at 2016-05-25 13:24:00:

For what it is worth you have some dead picture links on: https://utcc.utoronto.ca/~cks/native-habitat.html

By Jesse D at 2016-05-25 21:05:06:

It hasn't been such a big deal leaving it enforcing on RHEL, a few tweaks here and there but no pain points. It seems to have polarized people like systemd, but it hasn't affected me enough to really care either way (with both of them).

By Richard at 2016-05-30 00:13:12:

I agree with the above comment that its fine on RHEL. Packages have sain default policies and when additional functionality is needed the things you need are probably switches that can be toggled at the selinux layer.

Here is an example of applying existing tomcat policy to a non-rhel app. First we listed policy of files for installed similar RH packages, and determined the appropriate types. Then we applied those types to the new app path. Then we used restorecon to apply the changes. Done.

semanage fcontext -a -t tomcat_exec_t /data/maleta/bin semanage fcontext -a -t tomcat_exec_t /data/maleta/bin.X86_64_LINUX semanage fcontext -a -t tomcat_exec_t /data/maleta/java semanage fcontext -a -t tomcat_exec_t /data/maleta/lib semanage fcontext -a -t httpd_sys_content_t /data/maleta/html semanage fcontext -a -t httpd_sys_content_t /data/maleta/ImageFiles semanage fcontext -a -t httpd_sys_content_t /data/maleta/records restorecon -v -r /data/maleta

Finding clear information about how to do it and how to debug it could be easier. It is part of RHSCA courses but I have a feeling most people will not want to do that. I would not say selinux is broken or beyond saving.

By Richard at 2016-05-30 00:15:17:

Lets try that again...

semanage fcontext -a -t tomcat_exec_t /data/maleta/bin 
semanage fcontext -a -t tomcat_exec_t /data/maleta/bin.X86_64_LINUX
semanage fcontext -a -t tomcat_exec_t /data/maleta/java 
semanage fcontext -a -t tomcat_exec_t /data/maleta/lib 
semanage fcontext -a -t httpd_sys_content_t /data/maleta/html
semanage fcontext -a -t httpd_sys_content_t /data/maleta/ImageFiles
semanage fcontext -a -t httpd_sys_content_t /data/maleta/records 
restorecon -v -r /data/m

Written on 25 May 2016.

«	How fast fileserver failover could matter to us

Why SELinux is inherently complex