Weekly Edition
Return to the Kernel page
| |||||||||||||
The AppArmor debate begins
Novell announced the release
of the AppArmor security module last January. Then everything went quiet;
in particular, no attempt was made to get the AppArmor code merged into the
mainline kernel. The silence was broken last week, however, as a result of
the discussion on the possible
removal of the Linux security module (LSM) API. The submission of the
AppArmor code has had the desired short-term effect: the discussion has
moved away from removal of the LSM interface and toward the merits of
AppArmor. The AppArmor developers may not see that shift as a blessing at
the moment, however.
As expected, AppArmor has taken a fair amount of criticism. The largest complaint is the fact that AppArmor uses pathnames for its security policies. Using AppArmor, a system administrator can provide a list of files accessible by a given application; anything not on the list becomes inaccessible. Other things - such as capabilities - are also configurable, but there is no controversy over that aspect of the system. It is the use of path names which raises the red flags. The sticking point is that a given file name is not the file itself. So, while /etc/shadow might identify the shadow password file, that name is not the shadow password file. If an attacker is able to create another name for that file (through the use of links or namespaces, perhaps), that other name could become a way for the attacker to access the shadow password file. So, even if AppArmor forbids access to /etc/shadow for a given application, that application might still have access to other pathnames which could be made to refer to the same file. AppArmor thus differs from the SELinux approach, which attaches labels to objects and enforces access control rules based on the labels. With SELinux, the shadow password file has the same label (and, thus, the same access rules) regardless of the name by which it is accessed. So SELinux lacks a possible failure mode (rule bypass through different file names) that exists in AppArmor. Of course, as any SELinux administrator knows, maintaining file labels in a consistent and correct state poses challenges of its own. The other problem with the AppArmor approach is that the LSM API is not well suited to pathname-based security policies. As a result, AppArmor must often go through a fair amount of (potentially expensive) pain to obtain the names corresponding to files. The impedance mismatch between AppArmor and LSM is not generally seen as a reason to keep AppArmor out of the kernel, but it has led to suggestions that the AppArmor developers should either extend LSM for pathname-based policies or just add their own patches and drop LSM altogether. If AppArmor gets past the other objections, some work will almost certainly have to be done in this area. At this point, how any decision will be made on merging AppArmor is far from clear. It has not escaped notice that some of the strongest criticism of AppArmor is coming from the SELinux camp; SELinux developer Stephen Smalley has defended that criticism this way:
We're not threatened by alternatives. We're concerned about a
technically unsound approach. The arguments being raised against
pathname-based access control are about the soundness of that
technical approach, not whether there should be any alternatives to
SELinux.
The proponents of AppArmor claim that the approach is sound. Unlike SELinux, AppArmor does not attempt to be the ultimate security solution for all situations. Instead, it simply puts a lid on applications which might be compromised by an attacker. AppArmor raises the bar by limiting what a broken application might do; it does not attempt to regulate the interactions between every application and every object in the system. This approach is, it is claimed, enough to significantly raise the security of a system while maintaining an administrative interface which is accessible to mere mortals. And, for AppArmor's goals, a pathname-based access control mechanism is said to be good enough. It will probably be some time before we will see whether the kernel development community agrees with that claim. (See also: this detailed criticism of pathname-based access control by Joshua Brindle). (Log in to post comments)
The AppArmor debate begins Posted Apr 27, 2006 3:47 UTC (Thu) by jamesm (guest, #2273) [Link] I'd like to address the idea AppArmor is simple for "mere mortals" to administer in comparison with SELinux, which I believe to be a myth. In this thread, the creator of AppArmor admits that he doesn't understand the thunderbird policy on his own machine, and alarmingly, why it has setuid capability. Quote:> but as you posted an example profile with "capability setuid", I must > admit I am curious as to why an email client needs that. Well now that is a very good question, but it has nothing to do with AppArmor. The AppArmor learning mode just records the actions that the application performs. With or without AppArmor, the Thunderbird mail client is using cap_setuid. AppArmor gives you the opportunity to *deny* that capability, so you can try blocking it and find out. But for documentation on why Thunderbird needs it, you would have to look at mozilla.org not the AppArmor pages.As they add more policy coverage for things like IPC and networking, it will only become more complicated, but without the strong security assurance features of SELinux. This also demonstrates the way the AppArmor tool encapsulates existing behavior, without any real design or understanding of the security implications of the policy being generated.
The AppArmor debate begins Posted Apr 27, 2006 6:56 UTC (Thu) by nix (subscriber, #2304) [Link] This is the *point* of the learning system. The idea is that you run your target app in learning mode while it is *not* being attacked (which basically runs it with everything banned, but with the system set to log, not deny failed operations, and then analyzes the logfile). The resulting policy will only allow the target app to do what it did while you were running it in learning mode, which may include... unexpected things.
If you want to know *why* those unexpected things are being done, you'll have to examine the app's source code: and oddly enough Crispin didn't want to do that for a monster like Thunderbird.
This is (yet another place) where *exactly* the same criticism can be made of SELinux, except that of course because it doesn't have a learning mode you'll have to do the log analysis yourself.
The AppArmor debate begins Posted Apr 27, 2006 8:58 UTC (Thu) by james (subscriber, #1325) [Link] audit2allow is a "learning mode" for SELinux -- it takes the audited failures and creates rules to allow them.
audit2allow: more details Posted Apr 27, 2006 17:10 UTC (Thu) by bkoz (guest, #4027) [Link]
Thanks.
Huh. Interesting. This tool looks quite useful.
I found more details here:
Is there other documentation about this? (Targeted at non-studly sys admin types such as myself?)
audit2allow: more details Posted Apr 27, 2006 19:36 UTC (Thu) by jamesm (guest, #2273) [Link] Try the SELinux wiki: http://fedoraproject.org/wiki/SELinux Dan Walsh's blog: http://danwalsh.livejournal.com/ There's also a comprehensive book coming out, soon.
The AppArmor debate begins Posted Apr 27, 2006 13:10 UTC (Thu) by jamesm (guest, #2273) [Link] The exact same criticism cannot be made, as this is not the primary way that policy is developed under SELinux (it comes with the apps). You can use audit2allow, but I would not recommend it as anything but an adjunct to designing policy and then only if you understand what it's doing. (I know that it's mentioned in a lot of the online documentation -- possibly without enough caveats). I was discussing something similar to a learning mode for SELinux with another developer last year at OLS, and it can definitely be done, say, with per-process permissive mode. I don't think it's the right approach alone, but could be useful when used by a trained policy developer with some other features such as static analysis of the source code, peeking inside RPMs etc. There are tools now being developed for SELinux which operate at a higher level, with a wizard-like interface which allows security goals to be defined by the user, from which a security policy is generated.
The AppArmor debate begins Posted May 1, 2006 16:04 UTC (Mon) by Method (guest, #26150) [Link] Congratulations, you identified the precise problem with this type of system. For comparison the SELinux Thunderbird policy *does not* include this capability, proof positive that iterative active policy development will yeild higher quality policies than 'status quo encapsulation'. If thunderbird functions properly without this permission then it should not be there.
See http://securityblog.org/brindle/2006/03/25/security-anti-...
The point mentioned in your post about using learning mode while the app is not being attacked is talked about in the above article but I'll refute it here incase people don't want to read it. Once your system is active (eg., thunderbird is fetching mail from your server) it is no longer in a known good state, you have no idea if it is being attacked or otherwise compromised. The fact that blindly writing policies in this manner can actually create channels for the attackers to operate on after the policy is active is disturbing and IMHO a very compelling argument against this type of behavior.
The AppArmor debate begins Posted Apr 27, 2006 10:19 UTC (Thu) by jschrod (subscriber, #1646) [Link] It would help to get your critique in context to know if you're an independent observer or if you're working on SElinux.
Your past comments about SElinux, in previous stories on lwn.net, showed that you are very familiar with that topic. You brushed away several times the criticue of SElinux's complexity. So, how involved are you in SELinux? (That's not to say that your critic is invalid. It is about the expectation if you will represent both sides or one side of the discussion, with your arguments.)
For the record, I'm involved in neither SELinux nor AppArmor, but try to follow the developments.
Joachim
The AppArmor debate begins Posted Apr 27, 2006 12:58 UTC (Thu) by jamesm (guest, #2273) [Link] I'm James Morris and a long time SELiunx developer (I thought that was well known).
The AppArmor debate begins Posted Apr 27, 2006 18:24 UTC (Thu) by wcooley (guest, #1233) [Link] It's a little bit disingeneous to call Crispin the "creator" of AppArmor. Crispin writes papers, not code (I've heard him say as much myself when I worked at WireX [the company's name before Immunix and the Novell purchase]). He's a PhD theorist, not a programmer, and he tends to not get mired in details--so it would come as no surprise that he doesn't understand the Thunderbird profile on his machine.
Yes, he led the development of the higher-level aspects of AppArmor and wrote papers and secured funding, but most of the actual implementation details were handled by Greg Kroah-Hartman, Chris Wright, Steve Beattie, Seth Arnold and Jesse Michael (maybe others now too).
The AppArmor debate begins Posted Apr 27, 2006 19:46 UTC (Thu) by jamesm (guest, #2273) [Link] Well, that's never been my impression, and doesn't seem to match the way he describes himself.
"developed the StackGuard C compiler buffer overflow defensev and the AppArmor application security system. He lead the effort to build the LSM (Linux Security Modules) feature into Linux 2.6,"
http://www.linuxworldexpo.com/live/12/events/12BOS06A/con...
"Architect of the AppArmor Project"
http://www.fosdem.org/index/speakers/speakers_cowan
"Crispin Cowan is the chief architect of SubDomain, and CTO at WireX Communications."
http://www.seifried.org/security/products/20010912-immuni...
The AppArmor debate begins Posted Apr 27, 2006 6:39 UTC (Thu) by drag (subscriber, #31333) [Link] I don't understand how this is a problem with AppArmor.
It would be a definate problem for SELinux, but it looks like AppArmor and SELinux are doing different things.
Apparmor is for creating a sort of hardenned 'shell' around a application, right? So by default it has 'DENY ALL' type setting. Then you allow access to this or that file, right?
So if you want to deny access to /etc/shadow, you simply do not allow access to it. It's denied by default.
So if a attacker figured out how to make shadow appear as /etc/toffu or /tmp/taco to the application or whatever then it still doesn't matter. AppArmor would not allow access to that either; it's denied by default.
A attacker would have to figure out a way to make the file appear as a file you specificly allowed the application access to, right? What is the likelihood of that? In what possible way would a attacker make your shadow file or any other file appear as a library file or maybe a .config file in your home directory while working in a environment everything is set to 'deny all' by default.
The problem is only a you have the default setup of 'access everything', then you try to deny this or that file. Which seems a realy crappy way of doing things.
At least that's how I see it. Is is possible that I am confused about what is going on (which is likely)?
And if AppArmor dies and everybody ends up using SELinux then would it be possible in the selinux framework for me to do what AppArmor does?
I want to make a profile for each and every desktop application that interacts with anything on the network. I want to make a profile for Firefox, Evolution, my IRC client, GAIM, and my RSS reader. This is because my time is important and I only care about hardenning applications that are likely vectors of attack for my day to day activities on the desktop.
Now what is the best way to do that, to do what Apparmor does fairly easily right now, in SELinux?
To me it's always seemed that SELinux is for situations were you have a experianced administrator that wants to setup MAC for a server or whatnot.
AppArmor seems more like a application-level firewall, to block applications from behaving badly and accessing information or writing fradulent information that they shouldn't.
It doesn't seem that one is suited to do what the other does...
The AppArmor debate begins Posted Apr 27, 2006 12:02 UTC (Thu) by jamesh (guest, #1159) [Link] For some applications you might be able to restrict them enough for this to be true, but many apps will need fairly liberal policies.
Consider a text editor for example. The user expects to be able to edit files all over the system, so even if there is a final "deny all" rule, there will be many paths that the policy needs to allow. Each of these paths is a potential attack vector (assuming that they manage to create the hardlink or bind mount).
The AppArmor debate begins Posted May 1, 2006 18:56 UTC (Mon) by perbu (subscriber, #14372) [Link] I would think text editors are not the primary target of Apparmor. Talks and demos given seem to indicate that their focus seems to be on network-enabled services, such as Apache, Tomcat, PostgreSQL and lots of closed-source services.
I've been working as a sysadmin for 8 years and I must say I welcome Apparmor with open arms. It seems to be dead simple to set up - and you can do so without to much knowledge of the application you are trying to secure. It does not try to secure every aspect of every application - they seem to rule out support for complex beasts as shared memory because it would make the configuration process to complex - which I think is a good thing.
The AppArmor debate begins Posted Apr 27, 2006 15:16 UTC (Thu) by vmole (guest, #111) [Link] Lots of applications need temporary files with unpredictable names. For these, your AppArmor profile will have something like "/tmp/*" allowed. Or consider a mail reader, that might allow access to "/var/mail/**" (AA designation for all subdirs of "/var/mail", IIRC). Or, consider one that was pointed out on the LKML: The bind9 profile was "/**", i.e. everything, under the assumption that it would be running chroot("/var/named"), but there's no way for AA to enforce that expectation. Another thing to realize is that a lot of the objections are to AA using paths in the kernel. This leads to AA trying to convert dentry values to paths, which is both expensive and unreliable.
The AppArmor debate begins Posted Apr 28, 2006 5:49 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] note that AppArmor is planning to make all paths be absolute paths, so if you chroot bind in /bind then it's profile would be /bind/** to close this exact vunerability.
don't mistake a weakness in the current implementation with a fundamental flaw in the design
The AppArmor debate begins Posted Apr 28, 2006 17:28 UTC (Fri) by MenTaLguY (guest, #21879) [Link] Since Linux supports per-process namespaces, there ARE no globally absolute paths.
The AppArmor debate begins Posted May 4, 2006 9:13 UTC (Thu) by renox (subscriber, #23785) [Link] I disagree: the kernel has to do the translation so it has 'absolute' paths.
That each process can have a different view doesn't imply that there is no absolute path.
The AppArmor debate begins Posted May 4, 2006 16:58 UTC (Thu) by MenTaLguY (guest, #21879) [Link] No, it doesn't. As I recall (it's been a long time since I've messed with filesystem stuff), each namespace can have its own root dentry, and dentries are mostly used used for looking up inodes by their path within a particular namespace.
There is no real "absolute" path to a file because the kernel doesn't need it. Most interesting things happen at the filesystem/inode level.
(One of the reasons that people object to AppArmor is that it'd require pushing a lot of things up into dentry-land, when the whole system was designed around inodes.)
turn the /etc/shadow argument on it's head Posted Apr 27, 2006 7:48 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] if AppArmor won't protect you if you manage to create a new name for the file /etc/shadow, SELinux (which doesn't care about filenames, only the files themselves) won't protect you if you manage to change the name /etc/shadow to point at a new file.
you know what? every other program in the system will try to access whatever file /etc/shadow is pointing at, they won't care about the object that used to be called /etc/shadow that SELinux is still protecting, they'll happily use the new file
any way that you mark all things that access /etc/shadow to only access the 'true' /etc/shadow file requires active work to maintain over time (every program that modifies it, including vi/emacs, will need to set the correct SELinux label, and if any of them get it wrong, the whole system stops)
while AppArmor doesn't try to do everything that SELinux attempts to do, in some ways it's far more useful.
David Lang
P.S. I still haven
turn the /etc/shadow argument on it's head Posted Apr 27, 2006 15:59 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] I know only a little about SELinux, but I believe that you are incorrect. Programs that use /etc/shadow for password authorization can check the security label; if it is not set to the proper value, authorization can be made to fail. So if you manage to make /etc/shadow point to a new file, you only achieve denial-of-service: no one can log in.But even if this check is not made, ordinary users can make a hard link to /etc/shadow if they have write access to a directory in the same filesystem as /etc. Ordinary users cannot make /etc/shadow point to a different file unless they have already cracked root. So you haven't quite turned the argument on its head: it is easier to add new names than to change what a name refers to.
turn the /etc/shadow argument on it's head Posted Apr 28, 2006 6:01 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] and AppArmor only allows you to create a link to a file if you have permission to modify the file itself so creating a new name isn't as trivial
turn the /etc/shadow argument on it's head Posted May 4, 2006 14:48 UTC (Thu) by anLWNreader (guest, #36915) [Link] That would break POSIX. I hope AppArmor doesn't do that.
Raising the Bar Posted Apr 27, 2006 16:00 UTC (Thu) by Baylink (subscriber, #755) [Link]
My personal opinion on this is that if you create a security system that makes things only a little harder, then crackers will work a little harder. If you're going to provide new security facilities, and you have a choice between ones which have a fairly clear path to get around, and ones which will be substantially harder to break (at, perhaps, the expense of being substantially harder to configure), you go deep. Not doing so penalizes the smart people in favor of the dumb ones -- just because I don't know how to configure SELinux doesn't mean I can't find someone who does ... but if it's not there, it doesn't matter whether I can do it myself or find help, does it?
Raising the Bar Posted Apr 28, 2006 6:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link] nobody is suggesting that SELinux should not be available if you want it. however some people are arguing that since AppArmor isn't perfect security it shouldn't be an option for anyone to use.
Raising the Bar Posted Apr 28, 2006 13:08 UTC (Fri) by jamesm (guest, #2273) [Link] Just to be clear (seeing as I'm an SELinux developer and involved in the debate) -- this is not my position, rather, whether the mechanism used by AppArmor is suitable for merging with the mainline kernel.
Of course, people are free to do whatever they want with Linux, but it doesn't mean every idea belongs in the mainline kernel. There are a couple of paths to investigate to fix the problems with AppArmor, which have been discussed.
SELinux shortcomings Posted May 4, 2006 16:56 UTC (Thu) by alogghe (subscriber, #6661) [Link] As I understand it-
You can't secure a mounted nfs share with SELinux because it can't apply its labels (and I wonder which other filesystem types that wouldn't work either).
AppArmor would allow you to secure (to the level apparmor does) pretty much any path in the system and so you can secure an nfs/smb/anything mount.
For me this is pretty critical in making a choice of security systems.
Attention captain obvious- nfs security shortcomings are offtopic in replies ;) .
SELinux shortcomings Posted May 5, 2006 1:10 UTC (Fri) by sshimko (guest, #37560) [Link] SELinux supports context based mounts so while it is not currently possible to label NFS files (although this has been explored) it is possible to label the entire mounted file system.
So what you're saying is that you'd rather have security policy enforced across arbitrary mount points? So if I mount a NFS share on /mnt, /media, and /home the security policy is completely different for each? This doesn't sit well with me...
SELinux shortcomings Posted May 5, 2006 5:13 UTC (Fri) by alogghe (subscriber, #6661) [Link] Yes we would need security enforced at different levels/files in the mount points and selinux would be too course grained (just on/off at the mount point itself).
Network based filesystems provide a great deal of flexibility that we need here in the trenches ;)
Heh it's funny how some of us see the different policy against the different pathname/same share as a useful feature and it makes other people paranoid.
It's dangerous I agree but so is any powertool.
|
|||||||||||||