Logical fallacies aside your argument is very poor. Let me compare your argument to cars. Sure, we will eventually have flying cars that are fueled by discarded foodstuffs but that doesn’t mean we have to (or even can) give up on all the intermediary steps in between. If we don’t continue to make more fuel efficient cars and alternative fuels we may never make it to magical flying cars.

Furthermore, your argument seems to imply we should not waste our time and money on the infrastructure, so if we leave all our roads, bridges and parking lots to degrade we’ll end up much worse off than we are now, simply because we were trying to ignore the present to obtain the future, this clearly doesn’t work, and never has. Sure there are disruptive technologies, SELinux is one of them, but you don’t get a million miles away (your words) without traveling those million miles.

O/S security will continue to be on a wing and a prayer until MMU hardware can control access to state at arbitrary levels of granularity. In other words, real security requires all state (even a single character) to be opaque and accessible only through access methods (to use OO terminology) enforced by MMU — not by programming language. Only then will be be able to ascribe access constraints to the myriad large and small entities within an O/S with anything like full coverage, and only then will those labels stick as entities migrate and replicate.

We’re a million miles from that currently, so you’re wasting your breath in AppArmor vs SELinux arguments. There is Unix religion standing in our way at the moment, in the shape of “All I/O is in unlabelled bytes”, and that meme is immensely strong and adopted by every O/S on the planet. Security-conscious innovators have their work cut out for them.

There aren’t any patches of brightness appearing in the “Dark Ages of Computing” as yet, sadly. Anyone who combines both insight and a will to buck the accepted computing memes, please apply. Security needs you.

So, neither AppArmor nor SELinux provide bullet proof security or data integrity, although both may be useful in protecting against some problems.

But arguments like the ones in this blog really make me doubt whether the SELinux people even understand the issues or have much of a notion of how files and security work on real-world UNIX systems.

Right now, the best choice is the “Setools” package that has been recently updated ( http://tresys.com/selinux/selinux_policy_tools.shtml ). SeAudit and SeAudit-Report are the ones that will help you when dealing with AVC denials.

Also, as AVC denials are handled via the audit subsystem, designed and developed by Steve Grubb and others, you can use his tools to perform detailed analysis of the generated messages (audit ones and AVC denials).
Check http://people.redhat.com/sgrubb/audit/index.html. There’s also information on how to create graphs upon audit logs: http://people.redhat.com/sgrubb/audit/visualize/index.html

You can get them all in FC5 with the default repositories.

Oh, one other point, SELinux in the real world appears to already be partly pathname based, as at least when I was using it Fedora would routinely naval-gaze for 10 minutes or so whilst it relabelled every file on the system according to regular expressions ….. whilst I see this isn’t quite the same thing, it does rather make one go “hmmmm”

This sort of thing happened pretty often on old (e.g., FC2) Fedora but since then relabeling has really been limited to installation time, major policy changes and limited relabeling ala restorecon (when called by the user).

File labels in general aren’t suppose to change much, and correct type_transition rules will keep new files consistent for the most part (a few security relevant apps need to do more)

You’ve done a fine job of compiling some very compelling arguments against pathname based security. Here are some flip-side opinions put up for the purposes of debate. Again, I’d like to say that this doesn’t mean I think your arguments are wrong or SELinux is Ease of use

You claim this is a bogus argument because pathname security is “bad” as defined by your other points, therefore, it doesn’t matter that some people find path security easier.

Having used both SELinux and AppArmor there is no question in my mind which system is easier to use, and given that my needs did not include things like policy analysis and restricting the application I was confining from making hard links was not a problem, the benefits existed and should be considered.

So I would say you should not brush this aspect off. Whilst SELinux is arguably more complete, not every scenario requires completeness, in fact many don’t. In these cases usability can be the dominant factor.

The other factor to consider apart from policy language is for instance this ….

Jul 10 02:44:17 new2 kernel: audit(1089441857.053:0): avc: denied { read } for pid=4121 exe=/bin/bash name=.bashrc dev=hda2 ino=130311 scontext=root:system_r:cupsd_t tcontext=root:object_r:staff_home_t tclass=file

vs

type=APPARMOR msg=audit(1145112727.513:553): REJECTING r access to /home/mike/Desktop (wineserver(5405) profile /opt/wine/bin/wineserver active /opt/wine/bin/wineserver)

(yes I know they aren’t exactly the same message). However for me there’s no question which is clearer and the usability of the AVC Denied messages has been raised on the SELinux list before (eg the Python->English work).

Given that simplicity and usability are the reasons to go with pathname based security, it deserves a more thorough treatment IMHO.

Paths are ambiguous

This is why the namespace facilities in Linux require root to use them, right? Even though it’d be useful if they didn’t.

Firstly, this isn’t exactly a fatal flaw for AppArmor, as it can simply deny the ability to hard link. Very few apps need that ability for their standard operation. Users may use it more often, but, it’s not uncommon for users $HOMEs to be on filesystems separate to the main system, so, they couldn’t hard link there either (and you can mount /tmp as tmpfs or something similar).

In other words whilst paths can be ambiguous, often they aren’t. This theme of common case compromise vs absolutism seems to be a recurring theme in SELinux v AppArmor debates.

It’d be nice if namespace manipulation was available to everybody, without needing root access. SELinux does not provide that ability currently as it cannot override DAC security, which blocks it for the same reasons (eg you could fool an app into loading an inappropriate library if you were able to do arbitrary namespace changes). But in theory it could provide that.

The question is, is it worth the additional level of abstraction possible? And is it possible to allow for mixing namespace manipulation and path based security at the same time?

For the common case of a server admin who wants to sandbox sendmail, maybe not.

Lack of object tranquility

That can also be a strength as well as a weakness. For instance on Windows it’s common to have a filesharing app which shares any files put in a certain directory. The files location determines whether it’s viewable to the world or not. This is a commonly used setup, on any operating system.

The fact that SELinux does not do this is one of the major reasons people find it confusing and it has gained a reputation for commonly being switched off (eg, I copied a file into /var/www and I can’t view it in a web browser).

So I don’t think this particular point is as black and white as you make out.

For example, in the AppArmor evolution policy the “subject” /opt/gnome/bin/evolution-2.4 is given access to read and write /home/*/.evolution/mail/*.

It’s entirely clear, to me at least, that the combination of DAC and AppArmor would do what is meant here. SELinux does not replace DAC, it only adds to it, and I’ve been told this is a feature. So it seems disingenuous to claim that this rule is a problem with AppArmor because it relies on DAC to “do what I mean”.

Path based systems can’t differentiate between files downloaded by the browser and files put there by the user

It would be trivial to add this ability using extended attributes and allowing a glob match on them, so I don’t especially perceive this as a weakness. EAs to mark potentially unsafe files are already being talked about to deal with the fact that .desktop files can “appear” to be anything, including safe files like pictures.

Not all objects are files

A path is simply a name for something. It’s easy to invent a path scheme for naming objects that aren’t actually files, in a way that doesn’t disrupt the overall system or lower usability. For instance, I can imagine writing a profile like:

/usr/bin/my-update-agent {
connect http://updates.mydistro.com/*;
}

/usr/bin/apache {
listen http://eth0;
}

Or some better (real) syntax to express what I mean.

Likewise some imaginary path for IPC keys, X windows and so on could be invented. You could even go as far to claim that having such objects accessible via the filesystem is good and correct OS design, for instance, Hans Reiser has made compelling arguments as to the benefits of namespace unification, and Plan9 was based on similar ideas.

OK, that’s enough, your post is massive and my comment is getting that way too I haven’t talked about policy analysis because really, I have no clue how to do that, and for the sorts of things I’ve been using AppArmor/SELinux for I didn’t feel any need to do it either. When you’re trying to confine every object on a system using MAC I can see why it’d be useful but, well, I’m not …..

Paths may be bad, but inodes are atrocious and attributes more than a little annoying since you lose them way too easily and you can’t put attributes on files and directories that do not exist yet. So what do you propose?

Extended attributes, like the file mode, owner, group, etc are stored with the inode. There was probably a similar struggle when file modes and owners were first introduced (a long long time ago). Tools had to evolve to handle these things and now you’d be hard pressed to find a tool that doesn’t understand the file mode. This evolution will have to take place for extended attributes (not just for SELinux either..)
On the second point, some security relavent tools must be modified to set the context when creating the file, that is part of the same evolution. However, for non-security critical files something like restorecond, which is a userland solution to the problem, can be used.
The problems you point out are usability/user interface problems and those can and should be addressed in userspace rather than the kernel.

OG.