• 1
My blog was about how Novell did not work with the community and I believe has hurt Linux development.
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

(Anonymous)
Our goal is to give administrators choices of how they want to run their system, without forcing them to write policies.

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

Re: Comments

(Anonymous)
Your concerns are legit, but there is quite a bit of work in progress to deal with them, including the reference policy (serefpolicy.sourceforge.net), a policy IDE (should be released soon, being presented at the SELinux Symposium), and a book on policy writing that is in progress.

Re: Comments

(Anonymous)
Although SELinux is making good progress, it is still too complex for business adaption; the NSA once even come out and said so. Even an advanced Linux user can not use it without additional training, so what is the learning curve for someone new to Linux?

Some of the downsides to SELinux is that it's labelling is explicit and extensive, and arbitrary, meaning that if the admin leaves, his replacement may have trouble figuring out his work. It also must be done on a box-by-box basis, which is not practical for the enterprise, which requires tools for distributed computing.

With that said, even though SELinux is free, the time to administer systems is not, and since time is money, the TCO for using SELinux is generally not acceptable for business. For some reason, this topic does not come up for honest discussion very often.






Re: Comments

(Anonymous)
I just wanted to clear up a few misconceptions with what you said:

"My blog was about how Novell did not work with the community and I believe has hurt Linux development."

This is a subjective point but considering the amount of time and resources Novell spends on the Linux ecosystem I don't know where you get this from.

"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."

There's never a need to restart an application with AppArmor once you have a profile for it. Make as many changes to it as you want, you never restart the process. The learning mode of AppArmor makes this very simple as well as the tools provided to add capabilities after the fact.

"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."

AppArmor can do the same thing at an even lower level with mod_changehat. You You don't have to exec a php page but it can still have a separate security domain. This lets any single file under Apache run potentially with a separate security policy, some greater than the apache process and some more restricted. Security transitions are fully supported in all applications. You don't have to compile an application to use AppArmor but it you do write it with change_hat support you can have a very robust security transitioning mechanism built in from the ground up.

"Our goal is to give administrators choices of how they want to run their system, without forcing them
to write policies."

Choice is a great thing, it's one of the things that makes Linux so strong. I myself would rather have a profiling tool write a policy for me in 5 minutes than have to worry about all the intricacies of label based security but that's my own choice.

"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."

AppArmor provides an API that applications can use to support their security transitions. Novell has a modified Apache and SSH daemon which includes this functionality to offer even greater security. Of course, you don't have to modify your application to lock it down with AppArmor, but you can get more granular control of it if you do.

"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."

Yes, AppArmor is newly OSS but as some point every piece of OSS software was new. It's open now, fully supported, and has an active community forming around it. It's not being abandoned or anything like that, they opened it up to the community so that it could be used by everyone. You would probably ignore it as being commercial if they hadn't.

The last time I checked there wasn't exactly any standard for MAC under Linux that every distro relies on. Quite the contrary, every distro I've seen try to implement SELinux has been bogged down. Which is ok, SELinux isn't meant to be easy, but for those of us who don't have unlimited time to secure a system and want to maximize our security AppArmor is a great fit.

-Dan Elder

Re: Comments

(Anonymous)
Your arguments could also be used against how NSA "dumped" SELINUX over to the open source community. All Novell did was take a product they aquired and make it available through open source channels. There was an expectation by NSA that vendors would pick up (read: pay) for the much needed development work for SELINUX to fix the numerous bugs in the profile code and to expand the profile coding to support new versions of products and other applications. If Novell has a more stable product that can provide as good a solution or better, I think the open source community is benefited by their action.
If you honestly believe SELINUX is a mature platform that doesn't require good open source compatition to address the real weaknesses that exist in SELINUX, you are selling something other than open source (maybe Red Hat?).

Consultant at NSA

  • 1
?

Log in