------------
I have lived the Unix wars over the past 20 years. I worked on Project
Athena back at Digital Equipment (DEC) in the late 1980's and remember
all the effort that it took to make it work on multiple UNIX versions.
We had the best technology at the time. MIT and DEC had awesome
technology including instant messaging (Zephyr), security (Kerberos),
distributed management (Moira), secure file systems with Kerberized NFS
and AFS, shared name service via DNS and Hesiod, and a network windowing
system (X). You could walk up to any machine and log in and have the
same environment. We had single sign-on. We had universities working on
the product. It was a perfect system. But then we decided it need to run
on multiple different Unixes. We spent untold dollars making it work.
The problem was instead of improving the overall product, we spent all
of our time dealing with differences between the platforms. During this
time Microsoft was developing NT group-ware products and ended up
blowing us out of the water. The Unix wars had destroyed a great
product.
Linux consistency refocuses Unix developers
----------------------------------------
After a few years of working on Microsoft platforms for managing
security infrastructure on Unix and Non-Unix platforms, I came to Linux.
Linux seemed to have corrected the problems of the UNIX wars. It was
community based, all vendors shared the same code and worked together to
build a common platform. Sure, there were multiple competing layered
products, but almost all could run on all the different distributions.
Third party vendors could fairly easily build to a single API and it
worked on everyone's Linux.
Three years ago, I was asked to work on the SELinux Team at Red Hat to
bring Mandatory Access Control to a mainstream operating system (OS).
MAC had been attempted before but had always failed or became a one-off
OS. OS vendors would ship the primary OS and then a "Trusted" version.
This "Trusted" version would quickly become out of date as the main
development efforts would always go into the primary OS and eventually
be ported to the "Trusted" version.
With SELinux we decided we could do both at the same time, using the
Open Source method, we could get multiple companies, and customers
working on it. We had some stumbles along the way, but through the use
of the Fedora Core collaborative development process we came up with a
single OS that uses MAC and handles everything from your laptop to a the
highest levels of security specified by government.
Today we have great technology. We have many companies and government
organizations collaboratively working on SELinux together, including Red
Hat, IBM, HP, NSA, DOD, Tresys, Trusted Computing Systems. We have a
significant open source community built around SELinux, colleges and
universities contributing and doing experiments with it. We have
multiple distributions shipping with SELinux including Fedora Core
(2,3,4 and soon 5), Red Hat Enterprise Linux 4, Gentoo, Debian, Ubuntu,
Suse and Slackware.
Security Deja Vu
----------------
Everything seems to be going great, but ... Novell, who last year
claimed to be the first Linux distribution to ship with SELinux
technology, suddenly announced that they are dropping support for it. To
replace it, they bought a product called AppArmor and are now asking
third party developers to use it instead of SELinux. Is this the
beginning of the Unix wars all over again?
Not only is AppArmor divergent from upstream/community, but it is also not
suitable as a real alternative to SELinux, because it lacks the flexibility
and scalability of SELinux to address the full range of security concerns,
and its limitations are not just in implementation but architectural.
Novell claims that AppArmor is easier to use for third parties. But now
users and developers have to choose one or the other mechanism for
providing MAC, and ignore the other platform's security mechanism. Or do
twice as much work, to support both. Think back to the Project Athena
example. Is this easier? Couldn't Novell have spent their money on
making SELinux easier to use? No, Novel chooses to split the user and
developer community. I am not sure what their goals are, but I feel this
hurts Linux and the open source movement. The community has now gotten
SELinux to the point where "easier" is coming, but built upon a solid
foundation.
My fear now is that the Linux OS community has given application
developers an excuse to support neither security infrastructure, because
supporting either of them would prevent their product from running in
the other environment. So, for a developer, supporting neither SELinux
or AppArmor is the cheapest alternative, and maximizes the potential
customer base.
Instead of leveraging collaborative open source development to make
Linux the most secure operating system in the world, the now fragmented
Linux security community will be doing battle over who has the prettier
GUI. And the ISV community will ignore us.
Conclusion
-----------
The best outcome would be to have Novell work with the SELinux/open source
community to bring the benefits of AppArmor to the architecture/infrastucture
that is SELinux. This collaboration would benefit the entire Linux community.
To the contrary
SELinux has been available to the open source community for many years, and is now a standard part of RH's install. Yet the vast majority of people who look at it reject it and choose nudity instead :) In the usual open source world, that rate of rejection usually says "nice try, how about something else?"
Contrary to the claims above, I think AppArmor is actually *more* flexible than SELinux. Because of its much greater ease of use, a mere mortal sys admin can adjust AppArmor policy on the fly, without even having to re-start the contained process. Changing SELinux policy, in practice, requires someone with substantial SELinux expertise. Unless you have someone with those skills on staff, you need to call a consultant just for a configuration change.
Your fears about application developers having to choose between SELinux and AppArmor are unfounded; unlike SELinux, AppArmor does not require the developer to support AppArmor. Anyone can make an effective profile for an application with the AppArmor tools.
The reason for the split is that this has nothing to do with GUIs. For that matter, I'll concede that SELinux actually has prettier GUIs, but AppArmor is still an order of magnitude easier to use. The reasons are deeply founded in the security model, and it would not be possible to move SELinux to this point without completely ripping it apart amd making be ... well, AppArmor. SELinux and AppArmor are already sharing the code that we agree upon: LSM http://lsm.immunix.org/ which was developed jointly by Immunix and SELinux, as well as numerous other open source contributors.
I am painfully aware of the UNIX fragmentation wars. Open source licensing is the solution, which is why AppArmor was recently released under the GPL http://en.opensuse.org/Apparmor Competing projects in the open source space allows users to make a choice. With the very low adoption rate of SELinux, I think users are crying out for another choice.
Crispin
---
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/
Director of Software Engineering, Novell http://novell.com
Olympic Games: The Bi-Annual Festival of Corruption
Re: To the contrary
"unlike SELinux, AppArmor does not require the developer to support AppArmor"
Novell Users FAQ (http://en.opensuse.org/Users_FAQ) says:
"Applications don't have to be modified at all to be protected by AppArmor. To get the full power of SELinux, applications must be recompiled and linked against SELinux libraries."
I'm not sure what you mean by "to get the full power", but above statements seem to be a blatant lies. Could you please elaborate what modifications are necessary for the appliciation to be protected by SELinux ? Propaganda is a subtle art and exaggerating may be dangerous.
contrary intention
For example, even if in mail server, there are many servers
like sendmail, postfix, qmail, etc. And many of users are
choosing whichever they want.
Re: contrary intention
Comments
I did not intend it to be a point by point comparison of AppArmor and SELinux. But I will respond just
this once to some of the points.
- Interesting that comments made by me at the first SELinux conference are brought up, somewhat out of
context. Basically what I said is that in Fedora Core 2 we tried to use strict policy, which was
difficult to use because it tried to control user space and users wanted to setup their systems in a
many different ways. So the Open Source community told us they were not ready for such a drastic change.
We worked with the user community and the open source community. Together we decided what we needed was
to select a few "targets" to lock down and prove the technology and came up with targeted policy. This
proved the flexibility of SELinux and allowed us to ship SELinux turned on by default with FC3, FC4
and RHEL4.
- Any paradigm shift takes time for adoption, and SELinux/MAC is a paradigm shift in security, but one
that is necessary to make real progress in securing systems and one that gives enough flexibility to
permit people to gradually ease into it (ala RHEL4's targeted policy).
- AppArmor is not more flexible than SELinux. It controls based on fewer inputs (program/pathname),
controls fewer objects and fewer operations, and doesn't support entire classes of security policies
that are handled by SELinux.
- Through the use of SELinux, we have found potential security problems in many different applications.
This has allowed us to tighten security on applications whether SELinux is enabled or not. We have
removed many leaked file descriptors, We have worked with partners to remove unnecessary requirements
for execution of the memory stack using the execmod, execstack, execmem, execheap access checks.
http://people.redhat.com/drepper/selinux-mem.html
We have worked with Open Source application developers to design and build better applications, to allow
SELinux to better protect their applications.
- SELinux policy can be modified on the fly without re-starting a "contained" process; you only have to
re-start the process if you are changing what domain you are putting it into (vs. just changing some
allow rules), and AppArmor is no different in that respect. Further, SELinux has runtime booleans which
AppArmor lacks. Booleans allows an administrator to change the way policy an application is allowed to
run without having to write policy. So if you want to turn off the ability for apache to run cgi scripts,
you simply set a boolean rather than having to change a line of policy.
- SELinux also supports dynamic context transitions, so we can create an Apache module that switches
domains for PHP scripts. We favor exec-based transitions because they are more "secure" (stronger
boundaries between domains, real control over the code executed in the new domain), but SELinux has the
flexibility to support it.
- Our goal is to give administrators choices of how they want to run their system, without forcing them
to write policies.
- The fact that "AppArmor doesn't require the developer to support AppArmor" is an indictment of AppArmor
not providing real security. Ultimately, applications have to be involved in providing higher level
security guarantees, and they need some awareness of the underlying security model. SELinux provides
the infrastructure and APIs for such applications.
- Open Source means more than just dumping code over the fence with a suitable license; it has connotations
of community and upstream, which SELinux has had since 2000, vs. AppArmor's recent entry.
- Alternatives are good, but I question at what level. If major distributions of Linux were suddenly to
choose a new C compiler and runtime, such that applications built for one platform would not run on the
other, that would not be a good Alternative for Linux as a whole. KDE versus Gnome is a decent alternative,
an alternative to XWindows that did not work with X Apps would not be a good alternative.
Re: Comments
This works only for basic applications and environments. It obviously does not provide room for much customization. That said, I think Selinux is great once administrators can write their own policies. As has been said before this leads back to the discussion on documentation and tutorials; the Selinux project simply needs more of it. Or at the very least a visual tool which allows you to see appropriate context of changes made or programs added to policy and how they affect other packages. Or maybe using a macro for something would be bad in some form or combination etc etc.
Interestingly enough I came across this thread, while trying to figure out if Selinux was included in RHEL v3. I came across apparmor yesterday which from what I can tell is just Immunix. The main difference between the two? Documentation. The guide for lets say RHEL V4 and AppArmor are worlds apart.
You get to Chapter 8 in the RHEL V4 guide and what?
Presenting a comprehensive guide to writing policy is not within the scope for this book. For more information on writing policy, refer to the resources in Chapter 9 References.
You click on the HOWTO on writing Policy, learn about attributes, users, te's, etc etc and then you think you're gonna get some good answers you get:
We'll now get in to the fun part of actually editing SE Linux policy. This takes a fair bit of practise. The best thing to do is just play around with it all. It can be quite a challenge to get started with as a lot of stuff isn't documented and you'll most likely take the trial-and-error approach. Make sure you look at other policies already written in /etc/selinux/domains/program/ and the corresponding file_contexts file in /etc/selinux/file_contexts/program/
Considering that a major part of Selinux is enforcing policy. You can't expect someone to place all their security in the fact that others have written policy for programs. Not only that but what about ones own program which Redhat hasn't written policy for? Also, considering that Selinux the actual project is being built on a Fedora machine with core system packages being patched and modified, acquiring the patches for fedora first become a pain. Binding lets say Novell to Fedora, there is much involved in that alone. I say after going through it all myself, its a steep hill and alot of time involved in even setting it up. Then understanding how to write policy? Thats even more time, since there really is no documentation its just all trial and error.
This is why I suspect most distros provide Selinux support in the kernel/userland and just stop there. It ships, selinux=0.
Redhat just needs to provide proper documentation on writing policy. Otherwise the lazies will indeed choose AppArmor. I can't speak on the technical merits of it mind you but it does look like the easy way out. I suspect the reason everyone does Selinux=0 is because no one understands it and no one understands it because there is no good howto, no good documentation and seemingly no one wants to write any.
Anyway, yeah.. rhelv3.. no selinux.. so now my selinux skills go back in the closet.
Christopher Warner
I prefer AppArmor's approach.
Users and processes require access to resources using pathnames, not security-labels.
So, performing MAC using pathnames is more natural than doing it using security-labels.
Why not perform MAC based on pathnames?
NTT DATA CORPORATION (Japan) has released TOMOYO Linux, an implementation of pathname-based MAC like SubDomain, on November 11, 2005.
TOMOYO Linux can study MAC's policy like AppArmor.
This is because TOMOYO Linux uses pathname-based MAC.
If one security-label corresponds to multiple pathnames, security-label-based policy grants unnecessary access while pathname-based policy doesn't.
TOMOYO Linux can catch up with Fedora Core series that many users are choosing to "disable SELinux".
Changing TOMOYO Linux's policy doesn't require expertise.
You needn't to call a consultant just for a configuration change.
TOMOYO Linux is good at supporting customized programs that RedHat hasn't written policy for.
Many business applications developed by newbie programmers are running on Linux, they are not developed by RedHat and the administrator have to write policy for such applications.
Such applications tend to have more vulnerabilities (such as buffer overflows and directory traversals) than applications provided by distributors.
Though TOMOYO Linux doesn't have GUI tools, TOMOYO Linux is enough easy to manage using only CUI tools.
I think the time to review LSM is approaching.
TOMOYO Linux didn't use LSM because "the location of hooks" and "the parameters passed to hooks" and "the granularity of capability" are not enough.
I see AppArmor has struggled deriving absolute pathname inside LSM's hook function.
TOMOYO Linux derives absolute pathname outside VFS function, making MAC's code and policy much simpler and easier to manage.
Just try the KickStart for Debian Sarge on http://tomoyo.sourceforge.jp/en/kickstart/ .
You will find the advantages of pathname-based MAC.
Papers: http://sourceforge.jp/docman2/ViewCategory.php?group_id=1973&category_id=531&language_id=1
Project: http://tomoyo.sourceforge.jp/
Re: I prefer AppArmor's approach.
Labeling the inodes with the security attributes and then using those security labels for the permission checks is the only approach to provide real enforcement of confidentiality and integrity guarantees, or any kind of information flow policy. It allows consistent protection of the objects no matter how they are named/referenced and allows the real security properties of the object to be bound to it. It also allows the policy to scale, by grouping subjects (processes) and objects into equivalence classes (types and levels) rather than having to consider each individual subject/object, and allows analysis of the policy for information flows independent of the current filesystem state (which may include millions of objects and be changing during runtime). Using the inode attributes is consistent with the existing Linux DAC checking, which bases its checking on properties of the inode (mode, owner, group), not the path by which it was accessed.
Further, only SELinux provides comprehensive control of all objects and operations in the system, which is also necessary to provide real security guarantees.
Two things one should not forget
2. SELinux and LSM are not the be all and end all of security. There have long been several other approaches, such as grsecurity and RSBAC, for example. Incidentally, both these projects consider LSM to be an inferior solution. So what's so new and special about AppArmour?
Regards
Michael Burschik
Re: Two things one should not forget
My God. Are you still talking about the gcc 2.96 thing? First, that was ages ago. Second, you're wrong, and you've always been wrong. Read this document. RedHat made the correct decision.
open source is all about freedom of choice
Patents, Folks
Re: Patents, Folks
Slackware and SELinux
used both, have an opinion
I've been using Redhat, and now Fedora, for many, many years. I have appreciated the advances made by SELinux in Fedora Core, and I have high hopes for the modular reference-based policy in FC5. (I'm running FC5b3 as I type this.)
HOWEVER, recently I started running SUSE 10.1b6 on a second machine. I've been familiar with AppArmor for awhile, but have never bothered to use it as it was closed -source until recently. Having spent some time trying to build policies for both FC5 SELinux and AppArmor, I feel I've realized why AppArmor has the upper hand.
Simply put, AppArmor is *easy* to add policy to. I can quickly sandbox applications using AppArmor that would take TONS of time to "do right" in SELinux. That's a killer difference for me.
If you want SELinux to succeed, you have got to deliver tools that are geared at the use cases of the average sys admin. It's that simple.
Best regards,
Ben
Re: used both, have an opinion
Yo, bros!
From LA Monday Fest...Keep your ass!
Released??
Dead Man's Chest II trailers\fotos and some copy (920Mb)... how can it be? Released?
Fresh m-service
nice!
Earth is under attack
Look at Memo "About me" 8)
Jimmi song(and dance)
http://bmains.info/youtube/movie.php?movie_id=40762