1. As root, run “genprof /usr/local/bin/googleearth”.
2. In another shell, or from your desktop launcher, run googleearth. Visit some stuff. Exit googleearth.
3. Back in the first shell, answer genprof’s questions.

Done. No “make the module and reload it”, genprof did the policy reload for you. You don’t even really have to exit googleearth the first time, AppArmor can change the policy out from under the running process. The only real reason to exit googleearth the first time was so AppArmor can learn what an exit looks like.

Produced these two policy files:

# vim:syntax=apparmor
# Last Modified: Mon Apr 16 17:13:13 2007
#include

/opt/google-earth/googleearth flags=(complain) {
#include
#include
#include
#include

/bin/bash ixr,
/bin/grep ixr,
/bin/ls ixmr,
/bin/sed ixr,
/opt/google-earth/googleearth mr,
/opt/google-earth/googleearth-bin px,
/usr/bin/dirname ixr,
}

# vim:syntax=apparmor
# Last Modified: Mon Apr 16 17:13:13 2007
#include

/opt/google-earth/googleearth-bin {
#include
#include
#include
#include
#include

/dev/dri/* rw,
/home/*/.ICEauthority r,
/home/*/.Xauthority r,
/home/*/.fontconfig/* r,
/home/*/.googleearth/** rw,
/opt/google-earth r,
/opt/google-earth/** mr,
/proc/sys/kernel/osrelease r,
/usr/lib/dri/*.so mr,
/usr/lib/qt3/lib/lib*so* mr,
/usr/share/X11/XKeysymDB r,
/usr/share/X11/locale/** r,
}

Similar to Jan-Frode’s work, these policies are fairly loose, and in particular allow full read/write access to the .googleearth/** directory tree.

I’ll clean up the notes later.. and maybe even do an “evince” confinement just to get a more apples-to-apples comparison to this blog entry. I think googleearth is a bit more complex than evince, but for evince we would also have to not allow accesses to f.ex. /home.

Is it useful? Well, that depends on what you mean by “useful”:
-It is not useful if what you meant was “fully powered general-purpose user shell that gets to do anything, but not mess up the system.” No, it was not designed for that.
-Sophisticated multi-user interaction control. It wasn’t designed for that either.

What it is good for is creating strictly-limited confined shells that are purpose-specific. The linked white paper shows how to create a “syslog analyst” role so that a user can have root privilege to be able to read syslog, but still cannot hurt the system because they have very limited exec permission and extremely limited write permission.

Crispin

Python, Perl, etc., are identical.

Talking about confined shells intended for users realistically requires knowing what you intend to allow your users to do. It’d be simple to give them all access to mutt, pine, vim, slrn, wget, etc., but forbid them from mucking around with anything important on the system. Simpler still to give them execute access to nearly everything on the system but only write access under /home/*/**.

Mono and Java are similarly trivial.

(However, application containers such as Apache, Tomcat or Websphere are slightly more difficult. You options for running multiple applications in such a container are: (1) run all applications in a single security domain (2) run all applications in multiple security domains by starting an entire new tomcat or websphere process per application, or eschewing mod_perl, mod_php, etc., in Apache (3) a hybrid model that uses our change_hat() functionality to run multiple applications in different security domains in the same process. This does not provide full memory seperation, but it can help mitigate against applications running amok on their own.)

And, in fact, we have customers deployed with confined mono, confined websphere, confined jakarta, confined ruby, python, etc.

Users have happily deployed AppArmor in mixed Apache+lighttpd+fastcgi environments. In some cases, AppArmor’s mod_changehat module for Apache is “good enough” for them, in other cases, they have configured their systems to run different applications in different profiles and processes.

You raise a good point about the usability of the system not being a particularly good indicator of the security of the system. However, the counter point is that a complex security system can give a false sense of security by not making clear what privileges are being granted. (The quality of the SELinux profile inspection tools are hands-down fantastic. It’s been one of my goals to write an apol-style tool for AppArmor for several years. However, since AppArmor security policies are easily read and understood without more sophisticated tools, our need for tools is less severe.)

And ask yourself: how many SELinux users _really_ know what restorecond is doing? An obvious concession to usability that clearly trades many of SELinux’s strong points to try to emulate AppArmor’s path-based access controls. One might as well use the vfs_mnt, dentry pairs in the kernel to provide names at the time of use rather than rely on a secondary process to relabel files after they are created.

Perhaps there is a usecase for restorecond in SELinux deployments, that still makes good use of the rest of SELinux’s benefits, but it is difficult for me to see it.

Because evince is like the simplest example. It’s a monolithic, binary application that doesn’t interact with others much (though I’m not sure if above policy would allow printing!)

Now if you look at some application written in Python, Perl or SH, things become really different. Shell scripts especially rely on being able to execute *tons* of other commands. And the next obvious question is: how about virtual machines? Can I really confine applications written in Mono or Java?

I’m totally with you that users should have a choice in MAC systems. However these systems *need* to be technically sound, and I’m not convinced of that point with AppArmor. I still have the impression that AppArmor can control 90%-95% of common accesses, however the remaining 5% may easily leave enough room open for a privilege escalation. And this is very dangerous.

You suggested that “each admin should give each system an afternoon’s test to decide which is a better match for their needs”. I seriously doubt that a typical admin will be able to judge if the system covers *any* attack vector relevant to him. An ‘admin’ is not a securit experct, he can’t be expected to judge a system for it’s security on a day; so this suggestion of yours is actually *suggesting that an admin should pick his security solution by how easy it is to use*!

What the admin needs instead is *honest* information about the available systems, which threats they can prevent and which they can not.
And all the marketing speak surrounding AppArmor is something I can not call “honest”.

AppArmor seems to like avoiding this discussion by claiming that certain things are not in their “threat model”. Of course you can make every non-trivial situation not part of your threat model, but it can seriously limit the overall usefulness of the protection. But how much security do you really gain by only covering certain situations? Sure, you can prevent certain common attack vectors from being easy to exploit, such as the evince example, but it should be made clear to the users, that this is all AppArmor does: when used right (e.g. by not using a custom copy of evince) it should prevent certain common attack vectors. Just to give you some example on unnecessary privileges granted by AppArmors default profiles: evolution and gaim (and probably many others) can read /proc/*/cmdline; which might for some badly written applications even contain passwords, and which definitely allows an attacker to gather some information on running services in the system. However, path-based access control can’t differentiate here. Just the example I found quickly, experts can probably find more.

To do an _entirely unfair_ comparison: by enforcing a password length of 9 characters and a username length of 8, I can effectively prevent users from picking ‘password’ or their username as password. Given the current attacks profile on the net, this does significantly reduce the risk of being hacked. However, it doesn’t prevent users from using ‘password1′ as password. But if I’m assuming the users are smart enough to not use ‘password’ or ‘password1′, then I wouldn’t have needed this policy in first place; and allowing shorter passwords as well in fact increases the search space.
Yes, this is very unfair, since AppArmor can actually confine applications. No user will be able to start an httpd on port 80 anyway, and the admin should be smart enough to make sure his httpd is running in the confinement. But the path-based confinement model of AppArmor is very limited, and so I’m not convinced it can actually cover complex real world cases. For example, my httpd needs to be able to execute various CGI scripts and helper applications (e.g. for URL rewriting, fastCGIs and so on), these in turn need to be able to write to some cache files and so on.
SELinux on the other hand has a very powerful toolchain, that can - for example - calculate if there is any way to migrate from the httpd_t domain to sysadm_t. All reachability can be calculated, and thus it’s showable that no CGI ever could give an attacker full control over the system. Yes, it can be calculated that the policy doesn’t allow the httpd or any of it’s children (!) ever to write to /etc/shadow, for example.

Under AppArmor, a system administrator must confine untrusted applications. If the system administrator does not trust Erich, then Erich must not have an unconfined shell. If the system administrator does trust Erich, then Erich may have an unconfined shell.

Any attack that starts with “using an unconfined shell..” is outside the AppArmor threat model. AppArmor is designed first-and-foremost to allow a system administrator to confine services that the admin must run, without requiring the admin to develop policy for the entire rest of the system. AppArmor can also be used in desktop environments to confine applications that the user does not trust with all their data.

But any process that is a threat is supposed to be confined.

Moving on to your other complaints:

It is true that our learning mode can only assist users write policy for things their application has done. Sites with good test suites can do this without trouble. (Prominent online retailers have profiled their entire application suite in under four hours. Most of this time was spent drinking coffee, because their test suite was very comprehensive. :)

Installations without good test suites must rely on placing their applications into learning mode “long enough” to catch a representative sample of what their applications must do, and then make good choices when being prompted about accesses to allow. Since our policy is simple text files, system administrators are free to hand-edit policy to add rules they know should be added, but weren’t captured during training — as well as remove rules added too hastily.

The abstractions are there entirely as an aid to profiling. Feel free to not use them if you don’t like my choices. Feel free to make your own abstractions. (Most of our users do. :) We decided to try to keep the abstractions orthogonal and minimal, so abstractions/gnome doesn’t automatically include abstractions/X — in this specific case, an access to both ~/.Xauthority and ~/.gtkrc-2.0 will prompt the user for including both abstractions/gnome and abstractions/X.

There are times when abstractions make good sense (read access to a bunch of libraries, fonts, data files, write access to e.g. nscd pipes, audit logs, etc) and there are times when abstractions aren’t the right answer (data pumps — one process must write only, one process must read only). In this case, there are two simple approaches: (a) either put the required rights in profiles directly, without abstractions (b) create ‘read’ and ‘write’ versions of abstractions. (b) is usually only worth the hassle if there are multiple kinds of readers and writers…

AppArmor isn’t for everyone — e.g., the DoD and so forth would probably be better served by labelled data schemes such as SELinux that can provide MLS policies that confine the entire computer. AppArmor is designed to make confining specific applications easy.

Users have a choice of mandatory access control systems, and I definitely think every user should give each system an afternoon’s test to decide which is a better match for their needs.

Thanks for your comments.

(BTW: I’m assuming the evince process isn’t allowed to put code into /tmp and execute it!)

A counter example for how to develop a module for confining /usr/bin/evince using selinux would be interesting!

And last but not least:
- you rely on being able to trigger all functionality you need during the training phase.
- you still have to choose the right ‘abstractions’; in your case it looks like you are either missing some abstraction or have some duplication; the .Xauthority access for example should be in the Gnome abstraction, shouldn’t it?
- this approach is okay as long as you are dealing with simple applications. But abstractions will quickly be unsatisfying once you are dealing with the *interaction* of multiple services.

AppArmor is seriously hyped. Novell is totally behind it, sure, but I havn’t seen real scientific support for it yet. That it’s a tight security system and such.