| |||||||||||||
The AppArmor debate beginsThe AppArmor debate beginsPosted Apr 27, 2006 6:39 UTC (Thu) by drag (subscriber, #31333)Parent article: The AppArmor debate begins
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...
(Log in to post comments)
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 (subscriber, #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 (subscriber, #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.)
|
|||||||||||||