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)