Paranoid Penguin - AppArmor in Ubuntu 9

# Last Modified: Mon Jun 15 21:29:38 2009
#include <tunables/global>

/usr/bin/spaztacle.sh {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  /bin/dash rix,
  /bin/tar rix,
  owner /home/** a,
  /usr/bin/spaztacle.sh r,
  /var/spaetzle/ r,
  /var/spaetzle/** r,

}

Happily, if I run spaztacle.sh again, it still works. But, is AppArmor doing anything? I can make sure the new profile is loaded with this command:

bash-$ sudo aa-status

Here's part of its output:

apparmor module is loaded.
26 profiles are loaded.
13 profiles are in enforce mode.
   /usr/sbin/clamd
   /usr/sbin/cupsd
   /usr/bin/spaztacle.sh
[...]

Great! The spaztacle.sh profile is loaded in enforce mode. Besides showing what profiles are loaded and in what mode, aa-status also lists which processes are being protected actively. Because spaztacle.sh isn't actually running at the moment, it doesn't turn up in aa-status' output as an active process, but that's okay—normally you'd expect server dæmons, not commands per se, to turn up in that part of aa-status' output.

There's just one more test we'll do to see if AppArmor is doing its job. The more astute among you may have noticed that there's a glaring flaw in my little shell script (Listing 1). Because I didn't contain $1 in quotation marks, it's possible for a mischievous user to execute spaztacle.sh like this:

bash-$ spaztacle.sh "tarfile.tar /etc/apparmor.d/"

When the tar command in spaztacle expands the command input, it will correctly interpret tarfile.tar as the target file, but will include not only /var/spaetzle but also /etc/apparmor.d/ in the tar archive! On the one hand, local file permissions still apply. This works only if users in question have read access to /etc/apparmor.d, which means that although they're tricking spaztacle.sh, they aren't copying anything they'd otherwise be unable to get at.

But on the other hand, this is unexpected behavior for my unfortunate script. I don't want users to be able to include arbitrary directories in their authorized backups of /var/spaetzle.

So I'm glad to see that if I actually try running spaztacle.sh that way with my new AppArmor profile in enforce mode, this is the result:

tar: /etc/apparmor.d: Cannot open: Permission denied
tar: Error exit delayed from previous errors

The following message also has been written to /var/log/messages:

Jun 16 01:17:43 micksbox kernel: [57354.414567] type=1503
audit(1245133063.520:1004): operation="inode_permission"
requested_mask="::r" denied_mask="::r" 
fsuid=1000 name="/etc/apparmor.d/"
pid=28019 profile="/usr/bin/spaztacle.sh"

Success! AppArmor has correctly identified bad behavior on spaztacle.sh's part. And, the intended tar file (tarfile.tar) not only was created, it also contains the backup of /var/spaetzle that I did want the user to be able to create—only the unexpected part of spaztacle.sh's activity was blocked. Success indeed!

Using genprof may seem a little involved, but the man pages for genprof, logprof and apparmor.d explain most of what you need to know. The tutorials listed in Resources should be helpful too. I hope I've covered enough here to get you started using AppArmor on your own Ubuntu system!