For some time there have been two mainstream Mandatory Access Control (MAC) [1] systems for Linux. SE Linux [2] and AppArmor [3].
In late 2007 Novell laid off almost all the developers of AppArmor [4] with the aim of having the community do all the coding. Crispin Cowan (the founder and leader of the AppArmor project) was later hired by Microsoft, which probably killed the chances for ongoing community development [5]. Crispin has an MSDN blog, but with only one post so far (describing UAC) [6], hopefully he will start blogging more prolifically in future.
Now SUSE is including SE Linux support in OpenSUSE 11.1 [7]. They say that they will not ship policies and SE Linux specific tools such as “checkpolicy”, but instead they will be available from “repositories”. Maybe this is some strange SUSE thing, but for most Linux users when something is in a “repository” then it’s shipped as part of the distribution. The SUSE announcement also included the line “This is particularly important for organizations that have already standardized on SELinux, but could not even test-drive SUSE Linux Enterprise before without major work and changes“. The next step will be to make SE Linux the default and AppArmor the one that exists in a repository, and the step after that will be to remove AppArmor.
In a way it’s a pity that AppArmor is going away so quickly. The lack of competition is not good for the market, and homogenity isn’t good for security. But OTOH this means more resources will be available for SE Linux development which will be a good thing.
Update: I’ve written some more about this topic in a later post [8].
- [1] http://en.wikipedia.org/wiki/Mandatory_access_control
- [2] http://www.nsa.gov/selinux/
- [3] http://en.wikipedia.org/wiki/Apparmor
- [4] http://news.cnet.com/8301-13580_3-9796140-39.html
- [5] http://blogs.msdn.com/michael_howard/archive/2008/01/17/crispin-cowan-joins-the-windows-security-team.aspx
- [6] http://blogs.msdn.com/crispincowan/default.aspx
- [7] http://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-basic-enablement-in-111/
- [8] http://etbe.coker.com.au/2008/09/04/opinions-facts-apparmor/
Well .. there is also Smack which is in Linus Kernel and so most new distros should include it.
I hate the complexity of SELinux .. not very Unix-ish IMHO.
Russel, mate,
What have you got against RSBAC? Or to a lesser extent GRSecurity?
RSBAC is the MAIN compeitor to SELinux, and whilst SELinux is far more popular, opinion is divided over which is better. If you want to talk about competition, then you should not pretend competitors don’t exist.
RSBAC arguably has several advantages — no software must be recompiled, filesystem independant, patent free, no LSM, loadable policy modules.., which regardless of how they fare on a technical scale, might be non technical considerations for some people. Which is a good thing.
There is also GRSecurity, which is not as complete a solution, but is still woth mentioning.
James: SE Linux is enabled by default in Fedora, RHEL, and most derivative distributions. It’s included as a standard feature in Debian and most derivative distributions. AppArmor was a default feature in SUSE for a while, now it seems to be going away to be replaced by SE Linux.
RSBAC and GRSecurity are not in Debian, Fedora, RHEL, or any common derivatives (at least not the common ones such as Ubuntu and CentOS).
In terms of recompiling, to use SE Linux in Debian, Fedora, RHEL, and derivatives there is no recompiling needed. But for any other MAC system at least a kernel recompile is needed.
The patent issue is pure FUD, the patents in question expired years ago and even before they expired there was no problem (for several reasons that I won’t cover in a blog comment).
Not using LSM means much more effort to maintain a kernel patch for a MAC system, which means more problems for the user who has to build their own kernel images.
http://lists.debian.org/debian-devel/2002/12/msg01106.html
Incidentally you might want to check out the above list archives. I did some work on RSBAC for Debian years ago but gave up because only one person expressed interest in it!
It’s all very well for people to have different opinions, but if they aren’t prepared to do some coding or test the code of others then their opinion doesn’t count for much.
Russel:
I was not aware the patents had expired, and am in fact unsure how that happened. I was unable to find information on them expiring, just that they would not be enforced, which is not the same.
I don’t see why RSBAC not being in any of the more common distributions(unless you count hardened gentoo) is relevant. You were talking about the lack of Competition and RSBAC is the main competitor to SElinux at the moment.
SELinux once upon a time required a recompile as well, it is not really a point for or against it.
The lack of LSM support is more of a developer issue than a user one, and would not be necessary if LSM was adequate. Or to be fair, considered adequate by all developers.
I did check out the archives, but that was 6 years ago. Both systems have changed. I don’t see where your coding point is relevant.
My original point stands, RSBAC is a great alternative to SElinux, and worth checking out if looking for a differing solution.
Also, you could say that since SELinux needs some programs to be compiled with SELinux support(not sure if this is still the case) that it is just as annoying having to patch a vanilla kernel.
I don’t want this to be a debate on rsbac/selinux, but simply think rsbac should be given more attention as competition.
James: Patents always expire, they only apply for a limited amount of time.
The “LSM is not adequate” arguement is based on circular reasoning. People don’t join the LSM development process and then it’s no surprise that LSM doesn’t provide some functionality that they want. So they claim that it doesn’t do the job and then don’t use it.
RSBAC could have been included in Debian if there were interested people. Even now it could be included if there was interest from Debian developers.
Compiling programs with SE Linux support is to provide greater security than could be provided without such recompilation. It would be possible to run a “targeted” SE Linux system without any SE Linux related code in applications or daemons. But the result would not be as good.
Any security system which allows a process to perform an operation which is similar in concept to dropping privileges needs to have application support for it.
If you want to advocate RSBAC then the best thing to do would be to build some packages of it for a major distribution (as I did once) and try and get some people involved in developing and testing them.
Russel:
Right, but I thought the time for a patent to expire was a maximum of 21 years, including the 1 year bonus with a provisional patent.
I believe the people who did not join the LSM development project, were not having their concerns or ideas addressed, so they wrote their own series of hooks. Just because something is accepted into the kernel tree does not make it superior.
Compiling programs with SELinux support is necessary just like Compiling a vanilla kernel with RSBAC is necessary to provide greater security? It is worth noting RSBAC does not need application to be recompiled, and does not suffer security wise because of it.
I have tried advocating RSBAC, but people are not as interested as it is, and SELinux possibly appeals more because of the larger community. If you really want to encourage competion however, you could also point it out more often as an alternative. There is a live cd if people just want to try it out.
James: It’s 20 years from the date of filing. SE Linux is based on technology developed decades ago. The SCC contribution is based on research from the early 80’s.
Getting code into the kernel takes some compromises. The first two major versions of SE Linux didn’t make it. It was only the third version (with the second version of LSM) that was accepted. If you write code and tell the kernel people that THEY should address YOUR ideas then you will miss out.
Compiling programs with SE Linux support is easy when it’s included in the upstream code base. SE Linux kernel code is in the kernel.org tree. Maintaining RSBAC patches for a distribution kernel was not easy or fun last time I tried it – and I don’t expect that things have changed in that regard.
There seems little point in mentioning RSBAC given the lack of interest last time I tried promoting it.
[…] late since I have been camping out in the french pyrinees without a computer at hand whatsoever): http://etbe.coker.com.au/2008/… […]
Russel:
I see where you are coming from, however while there is a lack of interest, maybe it is worthwhile to promote it, and thereby promote competition.
What are you smoking? Re-read the release and look at the history of SELinux in SUSE. Previously, turning on SELinux would crash SUSE. Now it won’t. That’s all they’ve done so far. For the general population, SELinux is too complex and incompatible with too many things they’re running. SUSE says they are sticking with AppArmor as their primary choice but fixing their complete incompatibility with SELinux because some customers have no choice and have to use SELinux. SUSE wants to be considered for those customers.
Did you ask anyone at Novell / SUSE about this before making all those assumptions?
eldon: The history of SUSE and MAC is very clear. They bought Immunix and tried to compete with SE Linux. Then they laid off the AppArmor developers and essentially killed the project. Crispin wanted to continue AppArmor but decided to accept an offer from MS instead.
Now Novell want to compete with Red Hat, which means having a MAC system. Now they start doing stuff with SE Linux. The path looks quite clear.
As for the general population, there are a lot of people who use SE Linux (and gain protection) without even knowing it’s there.
As for asking someone at Novell, I’d rather rely on facts (such as what they have done in the recent past and announced for the immediate future) than PR about what their long-term aim might be. No company ever announces that they will kill one of their products in a few years, it will just kill their profits in the short-term. It’s best to keep claiming that they will support it until everyone else figures it out.
SELinux is Dead !…
No really it isn’t but so isn’t AppArmor, altough Russel claims it is. Weird how he totally rewords the OpenSuse statements
From “While our customer experience shows that AppArmor is the best solution for the vast majority of users, applications, a…
Russel, are you calumniator and itself PR manager?
in most installations of rhel, engineers turn off selinux, but apparmor work just fine by default. so apparmor, from out the box provides his first function – security, and, simple configuration.
selinux not trivial for configuring, and requires more complex steps.
selinux and apparmor has different place of using.
apparmor is more actual in desktop and server/public applications/services – it usable and easy for configuring
And, i’m sure, that opensuse and suse enterprise would have both, apparmor and selinux.
p.s. Say NO to narcotic:))
Kris: It’s a matter of public record that Novel dramatically reduced the number of staff that they have working on AppArmor (rumor has it that there was one single person working on it after the cull – but I can only find reliable accounts that most of the AppArmor people were made redundant). It’s also a matter of public record that Crispin (the leader of the AppArmor project) joined MS (I referenced some of his work for MS).
Can you name a single person who has been employed to work 40 hours a week on AppArmor for any length of time? Stephen Smalley (of the NSA), Dan Walsh and James Morris (of Red Hat), and Joshua Brindle and Chris DiBenito of Tresys have all been working 40 hours a week on SE Linux for at least the past four years.
The “Targeted” SE Linux policy will work on most installations with no need for changes or tweaks.
Does anyone know if RedHat is going to add PaX support to RHEL ? I read opinions that SELinux and PaX together would significantly increase overall security level.
Ron: Red Hat have had Exec-Shield in RHEL for ages. It’s feature set is comparable to PaX. There are trade-offs between security and usability, Exec-Shield is more towards the compatibility end of this than PaX.
64bit machines with the NX bit change all this, I haven’t investigated how the various memory protections schemes really work on 64bit systems.
“Ron: Red Hat have had Exec-Shield in RHEL for ages. It’s feature set is comparable to PaX”
I know, but I heard opinions that PaX protection is better, more comprehensive and flexible: presumably PaX is more strict but can be selectively disabled for a given executable.
“I know, but I heard opinions that PaX protection is better”
stop right there. If you are relying on heresay, that is no good and PaX protection is certainly not better since not many distributions are going to use it without developing merging it upstream.
PAX is indeed superior to Eec-Sheild.
Just because something is popular, does not make it better.
neo: The “paxtest” program (available as a package in Debian for the i386 architecture) can be used to compare various mechanisms for preventing writable executable memory. Last time I compared the results of running paxtest, PaX did win – and not just because the author of the test favoured PaX.
Morris: Last time I checked PaX halved the available address space, which would be a significant problem for anyone who wanted to run a large system on i386. Now that all the big systems run AMD64 it seems that it’s old P3 and P4 desktop machines running the i386 architecture – which often are incapable of handling more than 512M or 768M of RAM. The 1.5G address space limit that I recall being in PAX would be more than adequate for all the i386 machines I own.
If PAGEEXEC is used, then the address space is not halved.
http://archives.neohapsis.com/archives/fulldisclosure/2004-03/1367.html
Morris: Peter Busser (the author of paxtest) disagrees with you on this issue.
http://pax.grsecurity.net/docs/segmexec.txt
From the above: “The basic idea is that we divide the 3 GB userland linear address space into two equal halves” …
Note that I now agree with Peter’s assessment about going 64bit (although I didn’t agree in 2004).
etbe,
He does not disagree, that is 4 years old first of all, and does not say anything about PAGEEXEC. SEGMEXEC mode halves the address space, PAGEEXEC does not. The link you gave also shows some of the design flaws in exec-shield.
openSUSE is adding SELinux, not dropping AppArmor. You are reading too much (and wrong) into what was announced. Please note that Ubuntu and Mandriva recently added AppArmor, and SUSE is not dropping it.
and that’s that. Cheerio.
[…] recent post from Russ Coker entitled AppArmor is Dead was tolling the death bells for AppArmor because SUSE decided to include SELinux in their operating […]
http://blogs.msdn.com/crispincowan/archive/2008/09/02/go-ahead-make-my-day.aspx
Crispin has responded to this post at the above URL. It’s interesting to note that he seems less certain of the future prospects of AppArmor than the other people who have commented.
http://ars.userfriendly.org/cartoons/?id=20080831&mode=classic
Crispin cites the above cartoon about SE Linux which is good for a laugh.
Crispin does not work on apparmor any longer, so how his is opinion any more relevant than the people using it and advocating it? You need to get of the SELinux love wagon, and embrace the alternatives, instead of simply thinking of selinux as superior overall.
Better competition and development is good for everybody, better than having selinux as the default implicitly trusted protection on every system.
Morris: Developers know more about the products than users. Being an advocate doesn’t imply any knowledge about the product (the comp.os.*.advocacy usenet groups used to be evidence of this).
http://etbe.coker.com.au/2008/09/04/opinions-facts-apparmor/
Also you should read my above post on this topic. One of the amusing facts I discovered when researching it is that Crispin is still listed as the project lead for AppArmor. That has got to be a bad sign for the project.
Russel: Lest you bnot forget, you are a random computer user by your own definition.
Crispin is no longer an active developer of apparmor, so he is an advocate or just a user as per your definition.
I will respond to your second post separately, but you really do have to stop with the SELinux praise, it is not the only and/or best solution.
> It’s feature set is comparable to PaX.
does Exec-Shield have any kernel self-protection features? that’s about half of PaX’s feature set.
> There are trade-offs between security and usability, Exec-Shield is more towards the compatibility end of this than PaX.
what kind of compatibility problems plague PaX that don’t exist under Exec-Shield? i know of none, if an app runs afoul of any security feature, that feature can be simply disabled for that app, not unlike it is under Exec-Shield (think GNU_STACK which happens to be a bad idea, but i digress ;).
> Last time I checked PaX halved the available address space
do you realise that there’re *two* non-exec implementations for i386 in PaX? SEGMEXEC is only one of the two, the other, PAGEEXEC, will either use the NX bit (if supported by the CPU) or the TLB manipulation trick. distros can have a kernel supporting all of them and PaX will default to the best method automatically.
PaX Team: I didn’t realise that there were two implementations for i386. That resolves the compatibility issue in regard to address space.
But I think it’s really not much of an issue nowadays, Peter Busser’s claim from a few years ago that people who need big address spaces should just use 64bit systems is now matched by the common availability of hardware.
I agree that the way GNU_STACK works seems like a bad idea. If it was up to me things would have been done differently.
Russel,
Morris told you the same thing PaX Team said, and you ignored him?