A thread on the OpenBSD-misc mailing list compared the security of SELinux in the 2.6 Linux kernel to what's available in OpenBSD. The general opinion was that SELinux and its policy language are too complex, leading Damien Miller to note, "every medium to large Linux deployment that I am aware off has switched SELinux off. Once you stray from the default configurations that the system distributors ship with, the default policies no longer work and things start to break." Ted Unangst summarized, "the problem with security by policy is that the policy is always wrong."
Darrin Chandler suggested, "security should not be grafted on, it should be integrated into the main development process. I'm sure the patch maintainers are doing their best, but this doesn't change the fundamental flaw in the process. It's not a flaw of their making, it's inherent in the situation. But it's still a flaw." It was pointed out again that SELinux is part of the 2.6 kernel via LSM, to which Jason Dixon noted, "SELinux is a button. Buttons are easy to turn off. Darrin went on to say, "compare that to a complete operating system (OpenBSD) where security is part of code quality, and part of the normal mainline development." The security features in OpenBSD that were then discussed included propolice stack protection, random library mappings, proactive privilege separation, W^X, and systrace.
From: Douglas A. Tutty
Subject: OBSD's perspective on SELinux
Date: Sep 22, 8:34 am 2007
Hello all,
I'm running OBSD on my older boxes but still Debian on my big box (not
ready yet).
Linux has SELinux in its 2.6 kernel and debian has gone ahead and
compiled SELinux into the libraries, although the SELinux policies
aren't ready on debian yet. The whole focus seems to be to make Linux
"more secure". I'm not sure what to make of it. I figure that if you
want secure, you switch to OBSD.
Could someone who knows both the details of OBSDs security enhancements
and the details of SELinux comment?
Please note: this is _not_ a troll, flame-ware-tinder-box, whatever.
I'm genuinly interested.
Thanks,
Doug.
From: Damien Miller
Subject: Re: OBSD's perspective on SELinux
Date: Sep 24, 8:09 pm 2007
On Sat, 22 Sep 2007, Douglas A. Tutty wrote:
> Hello all,
>
> I'm running OBSD on my older boxes but still Debian on my big box (not
> ready yet).
>
> Linux has SELinux in its 2.6 kernel and debian has gone ahead and
> compiled SELinux into the libraries, although the SELinux policies
> aren't ready on debian yet. The whole focus seems to be to make Linux
> "more secure". I'm not sure what to make of it. I figure that if you
> want secure, you switch to OBSD.
>
> Could someone who knows both the details of OBSDs security enhancements
> and the details of SELinux comment?
In terms of mandatory access controls, OpenBSD only has systrace.
Every medium to large Linux deployment that I am aware off has switched
SELinux off. Once you stray from the default configurations that the
system distributors ship with the default policies no longer work and
things start to break. In my admittedly limited experience, this happens
very quickly.
If the policy language was halfway sane then this wouldn't be so bad -
a skilled administrator could adjust the policy. Unfortunately:
1) skilled administrators are hard to come by, and their time is usually
better spent *not* tweaking brittle mandatory access control policies
2) the SELinux policy language is nowhere near sane.
OpenBSD's systrace suffers from #1 - it is a generic problem with these
sorts of access control mechanisms, and it is one reason why it has never
been enabled by default. The brittleness is a real problem - I use
systrace for a few things and often need to update my policies because
of software upgrades or libc changes. Oh, and "skilled administrator"
means someone deeply familiar with the Unix system interface - not a
just a graduate of certification course de jour.
The Linux solution to #2 seems to be to add various wizards and other
abstraction between the administrator and the policy, rather than tossing
the horrid mess and replacing it with something more comprehensible.
I'm sure you could use SELinux to improve the security of a system but
it would require quite a bit of time and effort, both initial and ongoing.
-d
From: Chris Kuethe
Subject: Re: OBSD's perspective on SELinux
Date: Sep 24, 7:52 am 2007
On 9/22/07, Douglas A. Tutty <dtutty@porchlight.ca> wrote:
> Could someone who knows both the details of OBSDs security enhancements
> and the details of SELinux comment?
A capsule summary of the situation is:
OpenBSD aims to improve security by taking advantage of easy-to-use,
hard-to-disable, low-overhead technologies.
yes, you can disable propolice if you need to, but you have to know how.
yes, you can disable random library mappings, but you have to know how.
yes, you can disable W^X, but you have to try.
you could turn off the security features, but why would you, since
they don't get in your way, and they don't slow you down all that
much. i've not seen SELinux installations (or similar technologies)
that are easy to use correctly...
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
From: Ted Unangst
Subject: Re: OBSD's perspective on SELinux
Date: Sep 22, 11:50 am 2007
On 9/22/07, Douglas A. Tutty <dtutty@porchlight.ca> wrote:
> Linux has SELinux in its 2.6 kernel and debian has gone ahead and
> compiled SELinux into the libraries, although the SELinux policies
> aren't ready on debian yet.
rhetorical question: why aren't the policies ready?
the problem with security by policy is that the policy is always wrong.
exercise for the reader: find somebody using SELinux. ask them to
describe their policy over the phone. then repeat it back to them.
did you get it right?
From: Darrin Chandler
Subject: Re: OBSD's perspective on SELinux
Date: Sep 22, 9:00 am 2007
On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote:
> Linux has SELinux in its 2.6 kernel and debian has gone ahead and
> compiled SELinux into the libraries, although the SELinux policies
> aren't ready on debian yet. The whole focus seems to be to make Linux
> "more secure". I'm not sure what to make of it. I figure that if you
> want secure, you switch to OBSD.
>
> Could someone who knows both the details of OBSDs security enhancements
> and the details of SELinux comment?
I don't know all the details, and especially not the SELinux details,
but that won't stop me from commenting.
Not long ago I was talking with a Linux person about security, and they
pointed me to a set of patches that did a lot of nifty stuff. Good
stuff, like the things you find OpenBSD doing. But it's not in the
mainline kernel, it's a set of patches.
Security should not be grafted on, it should be integrated into the
main development process. I'm sure the patch maintainers are doing their
best, but this doesn't change the fundamental flaw in the process. It's
not a flaw of their making, it's inherent in the situation. But it's
still a flaw.
Compare that to a complete operating system (OpenBSD) where security is part of
code quality, and part of the normal mainline development.
--
Darrin Chandler | Phoenix BSD User Group | MetaBUG
dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/
http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
From: Jason Dixon
Subject: Re: OBSD's perspective on SELinux
Date: Sep 22, 9:20 am 2007
On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote:
> On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote:
>> Linux has SELinux in its 2.6 kernel and debian has gone ahead and
>> compiled SELinux into the libraries, although the SELinux policies
>> aren't ready on debian yet. The whole focus seems to be to make
>> Linux
>> "more secure". I'm not sure what to make of it. I figure that if
>> you
>> want secure, you switch to OBSD.
>>
>> Could someone who knows both the details of OBSDs security
>> enhancements
>> and the details of SELinux comment?
>
> I don't know all the details, and especially not the SELinux details,
> but that won't stop me from commenting.
>
> Not long ago I was talking with a Linux person about security, and
> they
> pointed me to a set of patches that did a lot of nifty stuff. Good
> stuff, like the things you find OpenBSD doing. But it's not in the
> mainline kernel, it's a set of patches.
>
> Security should not be grafted on, it should be integrated into the
> main development process. I'm sure the patch maintainers are doing
> their
> best, but this doesn't change the fundamental flaw in the process.
> It's
> not a flaw of their making, it's inherent in the situation. But it's
> still a flaw.
>
> Compare that to a complete operating system (OpenBSD) where
> security is part of
> code quality, and part of the normal mainline development.
If I could add one thing to Darrin's comment (of which I agree
completely), it would be this:
SELinux is a button. Buttons are easy to turn off.
---
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net
SELinux complexity.
I can't help but to agree about that the complexity of the configuration of SELinux makes it VERY hard to use and configure right. It's a beast of it's own in the kernel and the error log entries provided by SELinux are a challenge too. It's too easy to burn several hours figuring out why access to "/" was denied and then finally get away when "/" isn't "/" it's the root directory of the filesystem where you have your file, so if "/db" is a new filesystem on a different disk it may be displayed as "/" in the log.
The policy database isn't easily manipulated and the commands available may suddenly barf with "permission denied" or something without an apparent reason or explanation.
What's needed is to make SELinux easier to use and ability to set permissive mode for a single application instead of the whole system. It should also be possible to switch between strict and permissive mode without rebooting. (but an option to lock the system into strict mode shall still exist.)
In all - make SELinux much more user-friendly and the use will spread.
TOMOYO linux is much better. SElinux is really tooo complex
TOMOYO linux has a second proposal submitted.
it really seem to be much user freindly, and its provides the security features that most of the linux users want. wish TOMOYO linux be accepted to the standard kernel soon.
Not just Tomoyo
And there is also SMACK and Apparmor, also both being simple over Selinux.
Horses for courses
I think that comparing SELinux to OpenBSD default security is sort of pointless. The frameworks are designed to solve different problems and hence it is impossible to do a fair comparison.
OpenBSD has done a great job of pioneering certain approaches to common security issues. Hence as a basic foundation of proper security, it is a good place to start. However, complex security needs can only be accomplished properly using different machines, physical or virtual (preferably physical).
SELinux is aimed at an entirely different set of problems-- that of the enforcement of security policies traditionally met using machine separation. It is a complex set of tools designed to solve a complex problem. But it is not, nor should it be, a foundational piece of security (it is more like the walls of a house than the foundation). SELinux doesn't handle buffer overflows, etc. And it won't suddenly make a non-secure box properly secure.
In an ideal world, one would have both sets of tools available. Oh well, maybe some day.
Security-oriented Linux
Security-oriented Linux distributions, such as RHEL and Hardened Gentoo, already use ProPolice (non-executable data, address space layout randomization and stack protectors), *and* SELinux. They've been doing this for years. Yet OpenBSD developers are hyping their OS as if it was the benchmark for security.
Hey, even Windows Vista does that now!
Security by obscurity...
...is the OpenBSD way. Everybody knows that things like "W^X" can easily be circumvented once you have a working buffer-overflow.
Correction
Unless I am misunderstanding you, W^X cannot be circumvented when it is combined with address space layout randomization (which it is in OpenBSD). W^X prevents the attacker from executing the stack, while address space address randomization prevents him from returning to libc functions (a.k.a ret2libc attacks) because he cannot predict the address of any functions.
The Linux equivalent of W^X is PaX and Exec Shield (both of which also do address space randomization), or on processors which support it, native NX bit support in the kernel (still vulnerable to ret2libc because it's designed to be as simple as possible).
Still doesn't help against
Still doesn't help against ret2text.
And, as you mentioned, those features are present in Linux, making the whole OpenBSD<->SELinux an apple to oranges comparison.
W^X and ASLR circumvention
W^X makes some attacks infeasible, as does the stack protection in OpenBSD's gcc (and now gcc mainline). These don't thwart *all* attacks; return-to-library and return-to-executable attacks are still possible. That's where ASLR comes in, but it only makes these attacks difficult and non-deterministic. If an attacker is provided with many opportunities to attack an application with an identical address space layout (e.g. a forking server) then they can perform a brute force attack to the location of useful return locations. That's why we have modified OpenSSH to re-execute itself (thereby re-randomising it address space) rather than serving each connection with a forked instance (which would inherit the same address space each time).
If I wanted a fair
If I wanted a fair comparison of OpenBSD and SELinux, the last place I would ask would be the openbsd-misc mailing list.
Nor on a Linux mailing list,
Nor on a Linux mailing list, either. Where would you ask for a fair comparison?
Anywhere that knows about
Anywhere that knows about computers yet has no vested interest in either OBSD or Linux, Try the following:
Amega mailing list
Computer security mailing list
Magic 8 ball
Actually I imagine there is a risk of Linux bias by default* as it's better known than OBSD, but less bias than a Linux mailing list.
Alternatively ask the LKML and the OBSD mailing list, then compair the two conflicting awnsers.
* But not if you ask the magic 8 ball
Well, the poster even
Well, the poster even says:
This story is flamebait. :(
Flamebait...
Almost anything is flame bait to the right person.
There are many well considered statements in that thread, as well as some useless trolling as always. Take the good stuff and leave the rest. When I read the messages I was fairly impressed with the responses. There's some good information in there, and the evaluations of the effectiveness of one approach vs. another in real-world situations is something to pay attention to, since our machines must live in the real world to be useful.
The patch sets I referred to are not SELinux, and someone replied with more better info about those patches. I think my points were valid, even if they were something of an aside to the SELinux issue.
You would of course come to
You would of course come to KernelTrap. :)
There is no "fair" comparison between apples and oranges. If you're not interested in reading the whole thing, just skip to the conclusion below.
The listed features in OpenBSD (stack protectors, address space randomization and W^X) are preventive measures. SELinux is a framework for security policies and does not pretend to be anything else. It is somewhat comparable to systrace alone. Just like people might turn off SELinux, they could avoid configuring/enabling systrace.
Security policies may (a) restrict access to legitimate but untrusted users, or (b) contain possible damage when some part of the system has been compromised. Preventive measures simply prevent certain classes of bugs from being exploitable, but that's where their applicability ends. These are also available in the Linux world.
Both of these approaches should be used together, as does OpenBSD, and Linux distributions such as RHEL, Hardened Gentoo, and others. Regrettably, non-security-oriented Linux distributions often don't provide either.
Now, for the SELinux vs. systrace comparison:
systrace, as a user-space syscall wrapper, is inherently vulnerable to race conditions. Regardless of what it is configured to intercept, systrace's restrictions can be bypassed; note "status: unpatched" in http://secunia.com/advisories/26479/ and refer to the USENIX paper for more details. SELinux is not vulnerable, since it hooks into the correct places in the kernel, and does not read data from user space twice.
I cannot compare the effectiveness of the default policies on either OpenBSD or SELinux-enabled distributions, but I certainly agree that SELinux can be quite difficult to configure. The effectiveness of default policies should also be taken into account when comparing the two, unfortunately but I am not in the position to do that.
Conclusion:
LOL, OBSD trolls talk about
LOL, OBSD trolls talk about SELinux...
is OpenBSD still talking
is OpenBSD still talking about the broken by design systrace as a security feature? hahaha
Yes, they still do. They
Yes, they still do.
They have built up a huge hive mind around the hive queen Theo - although this time the queen decided to send some minions instead of talking herself.
I guess it's too much for
I guess it's too much for the trolls to read the man page...
yeah, labeling others as
yeah, labeling others as trolls must really give you a warm feeling. i refered to systrace as a security tool because of the article, and in the man page you can read right at the top: systrace - generate and *enforce* system call policies, only to find in the Bugs section that you can't really enforce anything.
I guess posting wrong
I guess posting wrong statements gives you a warm feeling. The OBSD team refers to systrace as a tool, and it's on by default only for ports...think of it as lint.
Probably ending with "hahahahaha" or referencing "hive queen theo" doesn't make you much of a non-troll, either.
I'll correct myself before
I'll correct myself before you do; systrace isn't on for ports by default. It's a switch you turn on.
Did you even read the posts?
Did you even read the posts? If you'd done a bit of digging, you would have found more replies still. Things like SELinux have their uses; but they just aren't as effective as secure, efficient code. It's about limiting damage. To defend SELinux, one of the posters argues that (summarized) "What if I need to run a program as root, and I don't have the source." The response is, of course "Why as root? If you can't read the source and it requires root (if root == true or somesuch nonsense) then you deserve what happens to your box."
While SELinux and systrace have uses, they're overhyped as a security feature and often used as a band-aid to existing security problems. If you don't trust the programs that require superuser access, then fix the programs - don't just slap in SELinux and ignore the problem.
If you cared about attacking OpenBSD at all, you'd at least do some reading, where you'd discover that they DON'T recommend the use of systrace. It's not enabled, and the reason it's not being rewritten and fixed is because none of them feel that it's enough of a security feature to warrant that amount of work.
And I really don't see why you think everyone worships Theo. Don't believe me, look at the source code for OpenBSD yourself. If it was as bad as some people claim it to be, then more security holes would be found! As it is, a number of people like you seem to get off on attacking OpenBSD users. You're the one exhibiting Hive Mind mentality. Theo isn't mentioned at all, and many of the posts are reasonable responses that raise a number of security concerns and provide insight.
I'd even stake money on many of the Linux kernel developers agreeing with the points raised. They're aware of security problems in their code, but it's just not a focus for them. They're content with security that's "good enough", and would likely agree that SELinux is often used as a band-aid; instead of being a more effective, secure administrator and not running untrusted programs or auditing code, they slap in SELinux and call it a day.
And then, apparently, they resume their holy jihad against OpenBSD users, if some of the posts here are any indication. It's my comedy for the day. Apparently I'm a part of a hive mind for appreciating the security of OpenBSD.. :)
It seems that gun-nuts who
It seems that gun-nuts who love M16 (OpenBSD) laugh about those that run around with a katana (Linux).
I guess in many ways, a M16 is really better.
But what they actually dont get is, there is MORE THAN ONE WAY TO LOOK AT SOMETHING. And that includes security.
It seems they have built up a religious cult around that and Theo leads the way while the cult members talk about "Linux" but forget that there is more than one way to do it on Linux (given that many distributions act differently).
As a user, there is always a trade-off when using something, rising complexity vs. the feel of invincibility.
You could hate Ubuntu for many things, but one thing it did was to create new interest among the Windows folks.
OpenBSD elite attitude never bothers about this at all.
One big problem with carrying a M16 around is that you need ammunition for your fancy M16 too. Without it,
you can use it as some club-like weapon but a katana is a lot better in this situation ...
This discussion on their mailing list is one little more stone in a bigger rock lining "OpenBSD rocks, Linux sucks"
"SELinux is a button. Buttons are easy to turn off."
"Compare that to a complete operating system (OpenBSD) where security is part of code quality"
"find somebody using SELinux. ask them to describe their policy over the phone. "
In fact, if you look at these lines, you see that they aren't interested in discussing, they are interested in praising their religion. It is a big, ugly troll cult. :)
If one has to use BSD, please let it be NetBSD or FreeBSD. They have less religious trolls on board, different to the not trolling hive-mind of Borgs that built up OpenBSD behind their hive queen Theo.
I wonder who is the troll.
I wonder who is the troll. The only argument you have is "they are a cult and defend their OS".
Erm...
"One big problem with carrying a M16 around is that you need ammunition for your fancy M16 too. Without it,
you can use it as some club-like weapon but a katana is a lot better in this situation ... "
I dunno, I'd think that the M16 would make a better "cluc-like" weapon than would a katana...
But a katana would make a
But a katana would make a better close combat weapon than an M16.
The situation was fighting without ammo, not fighting with a club so katana > M16,
comparing katanas and M16s
Wow! There has been innovative progress in useless comparisons by the OBSD & Linux camps. No mere "apples vs. oranges", no, they have moved beyond produce. Who would have pitted the katana versus an M16? Who I ask you?
Revolutionary! Astounding! Magnifique!
Keep up the good work!
That reply made my day. ;-)
That reply made my day. ;-)
AppArmor
So, I wonder where AppArmor (which is being built into the next version of Ubuntu, and appears to have been created by SUSE) falls into comparison with these two? Have these guys quoted from the OBSD mailing list ever even heard of it?
BTW, the TOYOMO stuff mentioned above seems interesting too :)
AppArmor is a different
AppArmor is a different security approach called path based access control. Here you can read about weaknesses of this security model
http://securityblog.org/brindle/2006/04/19/security-anti-pattern-path-ba...
All security approach have weaknesses
When people disable SE Linux because it's "too complex", this is a weakness too.
The article was interesting, but you should have precised that it was written by a SE Linux developer, a competitor in a way.
"When people disable SE
"When people disable SE Linux because it's "too complex", this is a weakness too."
Yeah, agree.
Users should know that there are user friendly tools designed to manage SELinux policies etc.
system-config-selinux
http://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-buildin...
setroubleshoot
http://danwalsh.livejournal.com/7212.html
and a few other
SELinux is _not_ a security expert thing anymore.
Re: AppArmor
> BTW, the TOYOMO stuff mentioned above seems interesting too :)
Really? :)
Then, I'd like to introduce you TOMOYO Linux LiveCD (Ubuntu 7.04 with TOMOYO Linux kernel).
You'll never understand TOMOYO Linux's policy learning mode until you see it.
1) burn the disc, 2) set it to your PC and ... 3) boot it.
http://tomoyo.sourceforge.jp/wiki-e/?TomoyoLive
And then there is also
And then there is also FreeBSD, with it's Mandatory Access Control and several pluggable MAC modules to choose from. One can also have several of them at the same time.