Saturday, June 13, 2009

Securing applications with AppArmor

The main problem with standard Unix security model (DAC - Discretionary access control) is passing user privilleges to applications he/she executes. The problem is, whenever you launch e.g. a web browser, it has access to all files/resources you would normally have to. While under normal conditions it's not a big deal, think of what happens if it has a bug that can be exploited by an attacker... Such danger can be minimized by employing MAC - Mandatory access control.

Having some prior experience with SELinux MAC implementation (the master thesis I wrote one year ago), I've decided to try out Novell's AppArmor . While SELinux is very powerful and may seem to be an ultimate MAC solution for Linux, it's far too complex for average joe user. Sure, the default 'targeted' policy implemented e.g. in Fedora Linux works fine out of the box, but debugging problems may still be too intimidating for most users. AppArmor is a MAC implementation for the masses: it's much easier to comprehend, use and administer.

I'm not going to describe AppArmor's history, command line tools etc. as they are explained in detail in the official documentation as well as in man pages. Instead, here is a short walk-through of creating a policy for Adobe Acrobat Reader 9. Acrobat Reader has a long track of security issues - most problems were related to application crashes when opening malformed (crafted) PDF files. The goal is to limit the resources/files that acroread can access by forcing read-only access to the filesystem, write access for specific paths only and 'execute' permission to specific commands only.

  1. Run AppArmor's 'learning' mode (profile generation) and point it to /usr/bin/acroread.
    $ sudo aa-genprof
  2. Run Acrobat Reader and excercise it a bit, that is, perform all the usual operations, e.g. open file, print it etc.
  3. When you're done, press "S" key in the aa-genprof window. You'll now have to answer a series of questions about granting or denying access to specific resources based on the actions you've just performed in Acrobat Reader. Use your best judgment to allow/deny access to given resources; keep in mind that some rules may need to be adjusted and made more generic by specifying glob patterns, e.g. allow acroread to read/write files in /tmp/** rather than a specific file in /tmp/ detected by aa-genprof.
  4. Once you're done with aa-genprof a new AppArmor profile will appear in /etc/apparmor.d/opt.Adobe.Reader9.bin.acroread. Open it in an editor and perform further adjustements.
  5. When done, reload AppArmor with sudo /etc/init.d/apparmor reload. Run Adobe Acrobat and verify if it works. Check /var/log/messages (or /var/log/audit/audit.log if you have auditd running) for any APPARMOR_DENIED messages which may be related to acroread actions. Repeat steps 4-5 if needed.
You'll need around 10 minutes to complete steps 1-3. You may stop there if you're happy with the rules created automatically by aa-genprof, but it's a good idea to tweak them manually. This will take you around 30 minutes, depending on your skills, needs and application complexity.

When creating my own profile for Acrobat Reader I've decided to simplify rules that govern /opt/Adobe/Reader9 subdirectories like this:

/opt/Adobe/Reader9/** r,
/opt/Adobe/Reader9/Reader/intellinux/bin/acroread rix,
/opt/Adobe/Reader9/Reader/intellinux/lib/* mr,
/opt/Adobe/Reader9/Reader/intellinux/plug_ins/* rixm,
/opt/Adobe/Reader9/Reader/intellinux/SPPlugins/* rixm,

I've also decided to restrict read-access to specific files and directories only; I came to the conclusion that PDF files usually reside in/home directories, /media/ directories (mounted devices like cdrom or flash drives) and/usr/share/doc subdirectories. So I ended up with the following rules:

deny /home/*/.ssh/** r,
deny /home/*/.gnupg/** r,
owner /home/** r,
/media/ r,
/media/** r,
/ r,
/usr/ r,
/usr/share/ r,
/usr/share/doc/ r,
/usr/share/doc/** r,

First two "deny" rules protect some vital user's files. Remaining rules grant read-only access for the paths mentioned above. Please note, that read-access for /, /usr, /usr/share and /usr/share/doc (no globs here!) is needed to allow standard "Open file" dialog to read contents of these directories (just the list of files) and browse to /usr/share/doc/. Try to navigate to e.g. /usr/share/perl to see it's not allowed. Cool!

There are of course more rules - in fact the profile file contains around 60 rules in total. Among them are rules that:
  • grant read/write access to configuration files in /home/*/.adobe/Acrobat/**
  • grant read access to standard GNOME/GTK configuration files in home subdirectories.
  • grant read/execute access to some standard commands like cat, pwd, mkdir and printing-related commands (lpq, lpr).
  • grant read access to icons, fonts and pixmaps.
  • grant execute access to /usr/lib directory.
That's it. Happy hacking.

No comments: