Paranoid Penguin - AppArmor in Ubuntu 9

Psst! Your Ubuntu system has been secretly hardened with AppArmor!
Creating AppArmor Profiles

At a high level, creating a new AppArmor profile involves creating a deny all policy and then running that profile in complain (log-only) mode; running your application in as typical a fashion as possible; using the resulting log messages to loosen up the profile enough (but only enough) for the application to work properly; and setting the finished, tuned profile to enforce mode.

AppArmor, through its genprof and logprof commands, walks you through this entire process interactively. I'm not going to cover the process for tweaking existing AppArmor profiles with logprof. logprof sessions are very similar to genprof sessions, so if you're comfortable creating new profiles, it's easy to tweak existing ones. (See Resources for more information on the latter.)

So, let's walk through the process of creating a new AppArmor profile. For this example scenario, let's start with a simple shell script,, that could use some protection. Listing 1 shows the script itself.

As you can see, this script allows users to create a backup archive of the directory /var/spaetzle, using the archive filename specified in the command line (for example, mybackup.tar). To create an AppArmor profile for it, run the following command:

bash-$ sudo genprof

What follows is an interactive question-and-answer session in which:

  1. genprof creates a new AppArmor profile for, containing a simple “deny all access” policy.

  2. genprof loads the new policy in complain mode and prompts you to start the application in a separate window (this is your first opportunity to demonstrate normal application activity to genprof).

  3. After you've demonstrated the application sufficiently, genprof analyzes the messages the new profile generated in /var/log/messages.

  4. For each log message, genprof asks what sort of rule to add to your new AppArmor profile to account for the behavior that was logged.

  5. After all log messages have been analyzed, genprof allows you to repeat the test/analyze cycle, which may or may not result in additional rules for the profile.

  6. When you're done with the testing/log-analyzing cycle, genprof saves the profile and loads it in enforce mode. You're done!

A full genprof session is too lengthy to list and dissect here, but we can discuss some highlights from my sudo genprof session that illustrate how the process works.

First, I'm asked whether genprof should query the AppArmor profile repository at I select d to disable repository access.

Next, I'm prompted to run my application. So I open another xterm window, and from my home directory, run the command arf.tar. That command results in the file arf.tar being written in my home directory, as expected.

Back in the genprof session, I type s to begin scanning the system log for AppArmor messages. genprof asks me whether and how to allow /bin/tar to be executed. This, of course, is the core function of, so I type i to cause tar to be allowed, “inheriting” the same profile as itself.

Next, I'm asked whether to allow /bin/dash to run. Because is a Bourne shell script, it needs to be interpreted by /bin/dash (on Ubuntu 9.04 /bin/sh actually is a symbolic link to /bin/dash). I type a to allow /bin/dash to run.

Then, I'm asked whether may read itself—that is, /usr/bin/ This is an expected part of the script-parsing process; I type a.

For now, there are no further log messages to process, so genprof prompts me to save the tweaked profile and asks whether to scan for more events. Before answering, I switch to my other xterm window, change my working directory to /home/mick/Public, and run the command anothertar.tar.

Sure enough, back in the genprof session after I type s again, there's a new set of “complaints” to process. The first concerns whether (actually tar) can read /etc/group. I'm given the option of allowing access only to /etc/group or of enabling the abstraction called nameservice.

Abstractions are groups of commonly accessed profile objects that constitute common system functions and services, such as checking file permissions, looking up hostnames and so forth. In this case, I select the nameservice abstraction and type a to allow it.

Next, genprof asks me whether to allow only write access to the (new) file anothertar.tar, or to use some sort of wild card (“glob” in AppArmor parlance). Because I want users to be able to create arbitrary tar archives in their respective home directories, I type n to specify a new glob, and specify /home/**.

In AppArmor profiles, ** is a wild card that means “any string, including /”. This is in contrast to *, which means “any string up to and excluding a / and anything after it”. Therefore, /home/** means “everything within /home/, including all subdirectories of its subdirectories”.

This implies that users might be able to write files to other users' home directories, but AppArmor controls augment normal Linux filesystem permissions; they don't replace them. In our example, therefore, users will be able to write to other other users' directories only if those directories' permissions are set accordingly.

In fact, our /home/** rule actually reduces the number of places can create tar archives. Without this rule, can write in any directory in which the user executing it has write privileges, not just subdirectories of /home/.

There are just two more log entries to account for. One concerns read access to /var/spaetzle. I type a to allow this access. You might be tempted to create a new glob instead, /var/spaetzle/**, but as it happens, tar handles the directory itself and its contents separately.

Therefore, only after creating the rule allowing access to /var/spaetzle and being prompted for a decision on allowing access to the file /var/spaetzle/arf.txt, will I type n, create the new glob /var/spaetzle/** and allow access to it.

Finally, we've reached the end of the new AppArmor events in /var/log/messages. When genprof asks me what to do after saving the changed profile, I finish the genprof session. genprof puts my new profile into enforce mode, reloads it and I'm done! Listing 2 shows the result, /etc/apparmor.d/



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Ubuntu 9.10, soon to be

Anonymous's picture

Ubuntu 9.10, soon to be released, has even more profiles. See:

It should also be noted that the Ubuntu kernel team has put a lot of effort into getting AppArmor into the upstream kernel. See for details. IMO, the future of AppArmor has never looked better.

I switched from Suse because

Tinker's picture

I switched from Suse because of their policy of messing with my system, I avoided distro's that implemented SELinux without my permission. I noticed the stealth introduction of AppArmor which I do not want and the fact there is no documentation of how to disable it. Is there any Linux distro left that allows me freedom of choice?

Disabling AppArmor is

John Johansen's picture

Disabling AppArmor is documented here

Sorry for the bad link, See

John Johansen's picture

Sorry for the bad link,

See for details on how to disable AppArmor.

Free Dummies Books
Continuous Engineering


  • What continuous engineering is
  • How to continuously improve complex product designs
  • How to anticipate and respond to markets and clients
  • How to get the most out of your engineering resources

Get your free book now

Sponsored by IBM

Free Dummies Books
Service Virtualization

Learn to:

  • Define service virtualization
  • Select the most beneficial services to virtualize
  • Improve your traditional approach to testing
  • Deliver higher-quality software faster

Get your free book now

Sponsored by IBM