User: Password:
Subscribe / Log in / New account

SELinux conceptual complexity

SELinux conceptual complexity

Posted Jul 10, 2008 4:24 UTC (Thu) by anchorsystems (subscriber, #40101)
Parent article: SELinux and Fedora

It seem that the biggest problem with SELinux is that
it has been designed from the most complex conceptual
model, as required to represent most classical security
models, rather than just starting with the simplest model
required to add basic MAC.

And this complexity makes every other aspect of it a
nightmare to work with.

I'm guessing that most people and policies don't make
use of the user, role, sensitivity, or categorisation.

Having all those aspects hidden and disabled when not
used to allow SIMPLE policies that rely on just
type/domain and transition rules would help understanding

(Log in to post comments)

Not really

Posted Jul 10, 2008 6:53 UTC (Thu) by khim (subscriber, #9252) [Link]

Take a look on frustrated user just above. Biggest problem with SELinux was not the fact that it's complex but simply the fact that it works differently then plain Linux.

I could not get postgres to start, even though I've installed it that way dozens of times is THE ONLY real problem with SELinux - but any security solution which will allow you to do things in exact same way you did it "dozen of times" is totally, utterly USELESS. Because security solutions are designed to stop attacker and till we'll have reliable telepathy-based function is_Attacker(3) security solutions will hurt admins from time to time - or will not hurt attackers at all...

Not really

Posted Jul 10, 2008 7:19 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, yes, but when it hurts normal admins it has *failed*: that's a false 
positive, because it's blocking someone who is *not* an attacker.

Not really

Posted Jul 10, 2008 7:34 UTC (Thu) by edomaur (subscriber, #14520) [Link]

What I think is utterly useless, is the way error messages are written. The "access denied"
message doesn't give enough information to really help. Generally speaking, I do not work with
SELinux because it is too much work to do the easy part of securing a server. But when I have
no choice and _must_ use SELinux, one of the first thing I do is tagging its error messages
with a nice "[SELINUX]" sticker. Much headache can be avoided...

There is also the problem of the complexity of SELinux : ok, this is a very good security
framework, but it is too hard to explain and to use to/by a casual sysadmin (which is somewhat
common). If someone doesn't want to be bothered with learning the intricacies of SELinux, he
will just disable the policies, or switch to a distro without SELinux enabled by default. 

Not really

Posted Jul 10, 2008 10:16 UTC (Thu) by lysse (guest, #3190) [Link]

Heh - can't help thinking of the state of American airports here... perhaps there are a couple too many "security-first" people who would class such high visibility as a success? ;)

Not really

Posted Jul 10, 2008 8:50 UTC (Thu) by jschrod (subscriber, #1646) [Link]

No, the problem of that PostgreSQL denial was not that the admin was unfamiliar with SELINUX and that it doesn't work different than on plain Linux.

The problem is actually many-fold, and can be nicely illustrated by the example that you cited:

  1. SELINUX forbids to use standard installation schemes. (Here: symlinking the location of a database to a different filesystem while keeping ownerships.) The security-related related disadvantage of that standard installation scheme is not obvious and there is no explanation delivered to the sysadmin why it is done that way and how to mitigate that problem / realize that standard installation scheme with SELINUX.
  2. The error message that are caused by SELINUX are worthless to identify the root cause of the problem. AFAIK, this is a configuration problem, but configuration problems are real problems, too.
  3. SELINUX documentation is often uncomprehensible for experiences Unix sysadmins with many decades of working experience, even if they try hard. IMNSHO, this is not a problem of the sysadmins, this is a problem of SELINUX.
  4. SELINUX proponents don't accept SELINUX's share of blame, but blame the user instead and imply that he isn't willing to adapt to new ways. And that even if the user tells them that he spent hours or even days trying to work out the new way. In fact, they tell their users that they are dumb. Guess what? Users don't like being (implicitly) called dumb. These proponents don't even seem to see that they alienate potential users with that behaviour and are actually one of the biggest dangers for SELINUX uptake.
Well, my 0.02 EUR on that topic.

Not really

Posted Jul 10, 2008 13:39 UTC (Thu) by kh (subscriber, #19413) [Link]

I have been thinking that the traditional Unix security model has strength because of its

1) It is easy for any normal sysadmin to understand

2) It is easy to audit

3) It is easy to edit 

Maybe there is a wealth of tools and custom scripts out there for selinux that I am not aware
of, but I do not think they exist because selinux is too difficult to completely

I also do not understand why any type of selinux (or any other security) error should be
anything other than noisy and verbose, especially when installed by default on a desktop. Does
selinux give silently logged errors that should be ignored by an average user?

Not really

Posted Jul 10, 2008 14:20 UTC (Thu) by jschrod (subscriber, #1646) [Link]

I agree with you mostly.

Concerning the error messages, in my experience, it is even worse: Not only are they not
sensible for an average desktop user, they are not even sensible for an experienced sysadmin
user! Therefore, using SELINUX on a desktop system is doomed to cause great pains for the user
community. (It bothers me only on an abstract level, though. On the desktop, I use SUSE...

But I don't think that the traditional Unix security model (easy as it is) can survive in the
long run. In our Internet-connected age the environment and associated threat model got more
complex, and such simple solutions won't be adequate in the long run. But I don't have any
idea how one can teach compartimentation and MAC to run-of-the-mill sysadmins and end-users
who are forced to be their own sysadmins.

Not really

Posted Jul 10, 2008 18:03 UTC (Thu) by dpquigl (guest, #52852) [Link]

2) I would like to have seen the error that he was getting from postgres but I have a feeling
if you ran it through one of the several tools it would have become apparent that postgres
didn't have permission to follow symlinks. However, this stems from needing to know that there
is a difference between symlinks and directories so even if it was clear in the message it
would need further explanation.

3) I agree that SELinux documentation is lacking at the moment but there are several efforts
currently going on to work on this. I have been preparing a series of tutorials and
presentations for educating people about the security model SELinux implements and how to
configure a machine in non-standard ways such that it still works with SELinux. Also there is
now someone working full time to generate documentation for SELinux.

4) We have seen this complains come up quite a few times and we can't figure out where it
comes from. Have you had personal experience with someone in the community treating you this
way? When I first started learning about SELinux I had many questions and the community was
very helpful and didn't make me feel stupid for asking them. If you have specific examples of
this I'd be glad to see them. It is possible that this might be a residual complaint from the
early days of SELinux that has hung around like some of the other complaints people have about

Not really

Posted Jul 10, 2008 18:12 UTC (Thu) by dpquigl (guest, #52852) [Link]

I forgot to mention, if there is anything you would like to see in the SELinux documentation
feel free to send suggestions to the mailing list and we will see about integrating them into
the documentation list.

Not really

Posted Jul 15, 2008 8:24 UTC (Tue) by mauvaisours (guest, #6130) [Link]

I've been hurt by SELinux some years ago, when installing a server that I needed for a quick
demo. At that time, I was only semi-aware that RH had turned SELinux on by default. So when
things got wrong (from my point of view), I was completely baffled. 

The big black point of SELinux is that it does not show up in standard commands [ls, ...], so
that the message you get is "permission denied", but you have no way of knowing why. 

And the documentation was (is?) so thin on the subject that all I could do (at the time) was
just shut it down, and as I was too busy, I never looked at it again, and I disable it on all
new installs.

So my guess would be : 
1/ Write an extensive documentation
2/ Make people read that doc (it's not that hard. I would.)
3/ Include that documentation on standard distros.
4/ Turn SELinux on by default.

It was done in the wrong order.

Not really

Posted Jul 15, 2008 18:44 UTC (Tue) by nix (subscriber, #2304) [Link]

Hah, I wish. It is *very* hard to get most people to read any 
documentation at all, generally because they don't care about SELinux (or 
any security system protecting against *potential* threats) until it 
causes problems, by which point things have already gone wrong. (If 
they're not running it they may suddenly start caring when they get 
rooted, but that, again, is too late.)

Nobody knows how to resolve this particular dilemma :(

Not really

Posted Jul 15, 2008 19:38 UTC (Tue) by mauvaisours (guest, #6130) [Link]

I agree that nobody knows how to resolve this dilemna, but pushing a new undocumented security
model to users is certainly not the way to go.

Re: Not really

Posted Jul 11, 2008 16:03 UTC (Fri) by jmmc (guest, #34939) [Link]

Also wanted to back up  dpquigl  in response to your #4 point...

At absolutely NO point have I ever encountered a response about SELinux from anyone (lists,
irc, etc) who was condescending to me or considered my inquires 'simple' or 'stupid'. I think
this comment is overly harsh in that regard.

Heck, I've learned quite a bit just in the 50+ or so comments here today - thanks again to OFE
(Our Favorite Editor, JC for even keeping this topic important, which it is, imho).

Lastly, I support SELinux 'policy ON by default'. Kudos to RedHat for being persistent on this
matter. I was trained that good policy on *NIX was always 'deny by default, allow by approved
request' from well before the SEL era...and default SEL is violating that principle ? ?

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds