“On Tuesday, Novell announced the creation of the AppArmor project, a new GPL open-source project dedicated to advancing Linux application security. Novell’s AppArmor is an intrusion-prevention system that protects Linux and its applications from the effects of attacks, viruses and malicious applications. AppArmor is based on technology that Novell acquired from Immunix, a leading provider of Linux host-based application security solutions, when it purchased the company in May 2005.”
Most major Linux distro’s are very secure already. Is this a drive to make inroads into secure environments such as Military applications? Or is it just another annoying service to disable?
Reading the documentation for AppArmor, the learning or complain mode appears to take the pain out of setting up a profile for an application. With SELinux, if you are creating a policy for something that is not supported you are basically “on your own” and would require a lot of testing before the solution could be pushed into production. Hitachi has some tools that might help in creating policies, but I can’t seem to get to the site (Government computer).
Using AppArmor in the learning mode you could deploy it in a production setting and have it log all of the violations to a profile without actually affecting the application. Then examine the logs and use the information provided as a basis for creating a custom profile. A very interesting concept.
Another interesting player in this field is RSBAC ( http://rsbac.org ), which also has a “learning mode”.
I’d like to learn more about how these projects compare/relate.
We had a “training” mode in Trusted Solaris 1.2 c. 11 years ago. It would allow the applications to run with the necessary privilege and log (to the audit log the privileges, uid/gid/ruid/rgid etc) that was used. You could then build a profile out of that. Trusted Solaris 8 still has this capability today.
A similar feature was carried over to Solaris 10’s ppriv(1) command. There will be a article written by myself and Glenn Brunette on the Sun Blueprints (http://sun.com/blueprints) site describing how to do privilege profiling beyond what you can do with ppriv(1) for Solaris 10 probably published in Feburary.
Look forward to reading that article, Thanks!
Actually you can do the same with selinux as well. Just run your system with selinux enabled, but don’t turn on enforcing mode. Then any violations will simply get logged. You can then take the logs and run the audit2allow tool on them to create selinux policies. Though granted things may be easier with apparmor.
SELinux policies are written in a macro language and then “compiled” with make. I know I know, you can use audit2allow to make mostly auto-generated SELinux policies, but the problem with SELinux is that the policies aren’t easily understandable without learning it’s internals.
This pretty much sums it up for me:
http://developer.novell.com/wiki/index.php/Apparmor_FAQ#AppArmor_ve…
SELinux and Apparmor are both very impressive Mandatory
Access Control frameworks. Thanks to great work from
the NSA, SELinux is even integrated into the mainline
kernel. Being more trivial to deploy into realworld
production environments gives Apparmor a signifigant
advantage over SELinux. Lets see how this plays out…
I figured as much, but I haven’t had the opportunity to use SELinux. And I agree with you, let’s see how this plays out.
Novell…… I’ve gotta buy the next couple of versions of suse when they arrive. I was debating it previously, due to priorities.
They *definately* deserve my money. Working on XGL for us, and opening up it’s other products for the good of the community.
I can’t wait to see what they do next.
Edited 2006-01-10 16:43
Read the white paper… not a bad program but looks to be un-necessary if one is proficient at building environments. I am not a huge fan of creating large multiple application machines in enterprise environments. For example a database server who would run 10 other applications on it so as to need a program like app armor? Rather then having a server just run the database which is something that is easy to secure.
You don’t seem to understand the concept of Mandatory vs Discretionary Access Control. It’s ok, most people dont.
DAC is basic Unix security. If you are user root, you own the box. MAC is a much more fine-grained layer that sits ontop of DAC. Mandatory Access Control is something like telling httpd that it can only read from /var/www/html and /etc/apache/conf/httpd.conf. Even if a flaw is found in httpd that allows privilege escalation, MAC (at the kernel level like SELinux or Apparmor) will completely prevent anything from happening. Does that make sense?
Say you have your “secure” Oracle box and an (at the time) unknown vulnerability comes out something like this one:
http://secunia.com/advisories/17250/
The intruder could use that buffer overflow to write to important system files or further compromise the box. With properly configured Mandatory Access Controls in place, this hack would yet again be harmless.
Fine so your talking about a severe niche market. There are other simpler means to protect against exploits you can never anticipate every bug even with software such as this. Just seems like overkill and an uneeded expense for 99% of installs in corporate environments. But thats just my opinion.
Just your opininion 🙂
The US govt doesn’t agree. That is one of the reasons that SELinux was wrote in the first place. MAC provides information assurance whereas DAC does not.
To each his own
You are right, one can not anticipate every bug.
This is why it is so important to have many independent ways to protect yourself from the bug or from the effects of the bug.
E.g. SELinux is a separate system from the normal Linux DAC security. To penetrate the system you need to penetrate both.
And as usual, the more secure, the more difficult to use and manage. That’s why you need to evaluate your protection needs carefully for each situation.