Linux security non-modules and AppArmor [LWN.net]

Linux security non-modules and AppArmor

Posted Jun 30, 2007 16:33 UTC (Sat) by drag (subscriber, #31333)
In reply to: Linux security non-modules and AppArmor by dlang
Parent article: Linux security non-modules and AppArmor

Well there is a fundamental flaw in pathnames that he is trying to point out, abiet unsuccessfully.

You see that is were the problem is. Absolute pathnames are not realy all that absolute. It's possible to have multiple names for the same files. It's possible to have weird directory setups were the same stuff appears multiple times in different directories and different paths.

Plus when your dealing with kernel-level stuff pathnames are pretty much immaterial because the kernel deals with lower-level stuff then all that. I don't understand all of it myself, but your dealing with situations were the kernel has to continiously loop back into userspace to determine what Apparmor is talking about.

So AppArmor is making things _deceptively_ simple instead of actually making it simple. It's just hiding complexity and control from the end user while setting you up for nasty security holes in corner cases. To actually effectively use it you have to actually understand everything that is going on, because it is easier to set rules does not make it actually simplier to effectively impliment versus SELinux.

What he is saying is:
* SELinux is a more realistic design based on the realities of how the software and machines work.
* SELinux can do everything AppArmor can do.
* AppArmor can't do everything that SELinux can do.
* It's very possible that SELinux can be made to be as 'simple' as AppArmor is, probably through the use of user-land programs to help set it up for admins.

I don't want to get into a big arguement about it. I don't know if he is right. If you have technical reasons why he is wrong then actually I would love to hear it because it would make it easier for myself to understand what is going on.

But you saying "AppArmor is easy" and that's why some people need it doesn't realy have much to do with what he is talking about because (I suppose) SELinux can be made "easy" in that way also.

It's like that Fire-proof door vs regular Door vs gaping hole thing that came up a few posts back.

If your going to have a door, then why not make it a good and effective door? There is no reason why a effective firedoor door can't be as user-friendly as a less effective door. At least in software-land.

(Log in to post comments)

Linux security non-modules and AppArmor

Posted Jul 2, 2007 8:52 UTC (Mon) by farnz (guest, #17727) [Link]

You've read a bit too much into what I'm saying. All I'm trying to point out is that the use of pathnames as your stable identifiers is rather weak if you're not thinking things through; this becomes especially true if a program uses hard links in normal operation. If you're thinking things through in enough detail to catch all the corner cases, you're also thinking things through in enough detail to write a label-based policy that works.

It's all too easy to write a policy like "Read /etc/resolv.conf, read/write/modify/hardlink in /tmp" without thinking about the details of what that allows; worse, the exact behaviour of that security policy depends on system partitioning. On my home machines, where /tmp is in its own partition, that policy is safe. On my work machines, where I have a single large /, that policy is dangerous.

Note that it's the use of pathnames as stable identifiers in policy that concerns me, not the rest of the AppArmor kernel-side. A simpler policy format using file labels wouldn't worry me at all.