What the SELinux community should be doing

June 10, 2013

Beyond a new errno value for SELinux I don't have any specific technical suggestions for things to do to SELinux to make it work better. Instead I think that the real next steps are social ones (because the most pressing issue is a social one). As it stands the SELinux community is simply not ready to start fixing any technical problems because they clearly do not understand the real problems.

The community's first job should be to understand the real problems that exist, both with SELinux and in general, and to think deeply about how and whether SELinux can solve them (and if there are some problems that SELinux cannot solve and should gracefully bow out from). One vitally important thing here is to actually shut up and listen to the significant number of sysadmins who have problems with SELinux (I say 'shut up' because the last thing the SELinux community needs right now is yet another round of their toxic mistake).

Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models). If it cannot solve real problems for people it needs to at least not get in the way. The current situation that many sysadmins are experiencing is that SELinux does not solve real problems and it also gets in the way. The SELinux community needs to fix that (and the answer is not 'lecture sysadmins more' aka 'user education', that's the toxic answer). Step zero of fixing it is understanding how and why SELinux is not helping sysadmins and that requires actually listening to them when they tell you.

(Trust me, if you start genuinely listening people will give you an earful. The SELinux community will probably not like what it hears and think that some of it is wrong, but shut up and listen. It doesn't matter what reality is; what matters here is what sysadmins perceive and believe. Only once you genuinely understand someone's perspective can you begin thinking carefully about how you might change it. You might also come to the uncomfortable conclusion that there is truth in their position.)

My personal view is that the SELinux community should also consider the idea that SELinux is only a good fit for certain sorts of machines. It may be that part of the solution is actually a recommendation that people should normally turn SELinux enforcement off on some sorts of systems.


Comments on this page:

From 194.176.241.90 at 2013-06-10 04:24:34:

I would like to use SElinux in certan situations, e.g. a few months ago I migrated a company's logging system to use TCP/TLS transport, replacing their old UDP/plain transport. The benefit was to comply some government regulation.

Dealing with SElinux was difficult because I couldn't easily find answers to questions like:

- How SElinux affects logging in general? What details do I need to pay attention to?

- Where can I find the documentation? I know there are labels, booleans and and a ruleset surrounding logging and SElinux, but where are all these stuff documented? I know there are supposed to be man pages about these but what exact man pages should I read? How can I find out the names of the man pages?

Later in the project, after asking questions around the web I reached the phase where I had to deal with best-practice questions, like:

- Which is the better way to deal with custom application logs, creating a new label and allowing syslog processes access to it or simply labeling custom logs as log_t?

I have to say it was definitely difficult to find answers to these questions. It is possible, but it takes a lot of time. And I can imagine, if I need to build an apache web server farm the next time, I have to go through this painful procedure again :-(

My suggestion to the SElinux guys is to provide meaningful documentation about their software. I know they are improving, but there is still a lot of room to reach general usability.

From 216.105.40.123 at 2013-06-10 06:24:14:

"Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models)."

This is just a whole lot of FAIL.

You are basically asking the SELinux community to accurately predict the future exploits and only put in the bits of least privilege that will stop those particular exploits. This is Ranum's "enumerating badness".

Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.

From 82.197.216.4 at 2013-06-10 08:22:31:

""Put another way, SELinux needs to solve real problems and by 'real problems' I mean problems that are actually affecting people in the real world (not theoretical possibilities of threat models)."

This is just a whole lot of FAIL."

Totally agree. SELinux does not solve problems. SELinux enables one to solve problems.

SELinux is a Flexible MAC security framework

From 46.144.78.131 at 2013-06-10 08:23:23:

the documentation is right where you would expect it to be:

general doc site for RHEL: https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/?locale=en-US

Inside that page, search selinux: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html

Also nice howto run confined services: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/index.html

Not so hard to find I think ;-)

As to the real problems it should be addressing, if you do not know them by now, just disable the stuff.

By cks at 2013-06-10 08:39:42:

I mean 'real problems' here in a more general sense than I think you are taking it. Firewalls are actually a great example because the introduction of firewalls solved several general problems that people were having, such as 'we have insecure internal machines that keep getting attacked from the Internet'.

(One mark of solving a real problem, one that people are actually having, is that you can tell lots of stories about real, actual bad stuff that your solution prevented. I do not think that SELinux can do that today; as I've said before, today SELinux is a backup.)

'Least privilege' is a technical detail. People do not care about technical details; they care about having their problems solved. If you do not solve their problems and you cause them problems, you will get thrown out. If SELinux focuses on technical details instead of solving problems that people are having, it will continue to fail in any number of situations and the SELinux community can look forward to years of sysadmins telling each other 'oh, SELinux, ha, almost everyone disables that first thing'.

(See social problems are the real problems and computer security is people for more on this general issue. I keep banging on this drum because it is very important for actually getting security.)

From 82.197.216.4 at 2013-06-10 08:46:07:

Let me just expand a little on my previous comment:

Compare SELinux to network firewalls:

1. Netfilter in the Linux Kernel < -- > SELinux in the Linux Kernel 2. iptables utilities and libraries < -- > SELinux utilities and libraries 3. iptables configuration < -- > SELinux policy configuration

People often judge SELinux on its stock configuration. Just like some might judge netfilter on a the stock iptables ruleset.

That is not fair.

The rules/policy are just configuration, and it should be obvious that there is not one-size-fits-all iptables configuration or SELinux policy configuration.

Because each environment has its on properties and requirements.

Default rule sets are shipped so that at least some level of protection can be provided out of the box, but a responsible system administrator is expected to adjust the rules/policy to the environments properties and requirements.

netfilter and selinux framework gives us the attributes we need to solve our specific network and system challenges.

People tend to judge SELinux on how it is configured, but SELinux is so much more.

SELinux enables one to address challenges in a wide array of scenarios because it is flexible and configurable, but the keyword here is enables, and only you can identify threats to your environment, properties of your environment and your requirements.

From 194.176.241.90 at 2013-06-10 09:15:31:

The "Managing Confined Services" document is really good - however it has zero information about syslog/rsyslog. :-(

I know that as SElinux is evolving its documentation is evolving as well and I think it will be really-really good in a few years - however the current state is still a bit sloppy :/

From 207.172.69.99 at 2013-06-10 09:16:52:

This sounds remarkably like the problems of GNOME 3 and the Debian systemd folks.

In both cases, the immediate response to any suggestion that people aren't happy with their software is to ask for a list of problems, admit to the most minor issue, and then deny that anything else is a real issue: people just don't know enough, haven't tried it, and haven't read the docs.

So if there are three situations like this, there are probably more.

Is it endemic to open source projects? Or perhaps to software projects in general?

-dsr-

By cks at 2013-06-10 11:12:41:

dsr: I think that what you note is endemic to anything that humans do, not just software. My guess is that it is in part a variant of the sunk cost fallacy.

From 129.97.109.15 at 2013-06-10 11:32:20:

Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.

Really? I run into this 2-3 times a week for our network firewalls. Admins here live with them because they don't have a choice, but there's a certain number of them who, if given the choice, would happily enable from any to any, any application, and carry on.

MP

From 128.101.135.18 at 2013-06-10 14:39:35:

Nobody had this much heartburn when firewalls were put in and they had the same issues including silently blocking stuff/dropping packets. But user education WAS the key in that case and everyone learned to live with them. It's the same thing. Block everything, allow only what is necessary. Learn the tools.

Really? I run into this 2-3 times a week for our network firewalls. Admins here live with them because they don't have a choice, but there's a certain number of them who, if given the choice, would happily enable from any to any, any application, and carry on.

MP

SELinux != Firewall.

Bigger shops have a person, or handful of people that manage the border firewall. Software packagers have also been forced to include directions for making a hole for the software through the firewall.

There is nothing like that for SELinux. Many software packages can get away with "disable SELinux" as the first install step. Even RedHat does not show a commitment to SELinux. RedHat could force packages to come with SELinux configurations out of the box.

From 82.197.216.4 at 2013-06-10 15:19:24:

"There is nothing like that for SELinux. Many software packages can get away with "disable SELinux" as the first install step. Even RedHat does not show a commitment to SELinux. RedHat could force packages to come with SELinux configurations out of the box."

You must be joking..

1. Red Hat shows leadership by enabling SELinux by default 2. Red Hat has SELinux security built into libvirt, openshift and other major technologies 3. Red Hat has people working full time on SELinux 4. Red Hat includes SELinux in their training courses and certification 5. Many operating system components have extensions to SELinux (dbus, xserver, systemd, and others)

It seems that it is really hard to grasp the concept of computer system security and mandatory access control.

The idea of MAC is that policy is governed centrally, and in many cases is transparent to the application layer. You cannot trust packagers ( or anyone for that matter ) to make security decisions for you.

What does a run of the mill application coder know about security? About your environment?, your requirements?

Written on 10 June 2013.
« SELinux should have its own errno value
The good and bad of IPS (as I see it) »

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

Last modified: Mon Jun 10 01:17:07 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.