The AppArmor debate begins

  > 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.

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...

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
t seen an example of how to set and maintain permissions along the lines of /home/*/public_html/* to pull an example the AA people have used to show the power of the path based approach

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.

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?

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 ;) .