[ubuntu-hardened] AppArmor for Ubuntu (braindump/overview)

Paul Sladen ubuntu at paul.sladen.org
Wed Mar 1 02:36:38 GMT 2006

On Wed, 22 Feb 2006, Crispin Cowan wrote:
> would like to help port it to Ubuntu. Since Ubuntu has a very strong
> ease-of-use theme, AppArmor for Ubuntu should be a very strong fit.

I had a good talk with Crispin this evening in London and I hopefully have a
reason overview handle on AppArmour.  Crispin, please correct any of the
following if I've got the wrong idea.

Example policy:

  $ cat /etc/apparmour/usr.bin.foo
  /usr/bin/foo {
    #include <another.base.policy>
    /etc/foo/* r
    /proc/[0-9]*/cmdline r
    /tmp/ rw
    /var/lib/foo/foo-helper-* rx

  Permissions are standard Read, Write, eXecute.  Globs are *, [x-y], ?.

AppArmour approach:

  LSM module (Linux Security Module), uses existing LSM hooks.

  Class-based policy.  This means that policies are applied to all programs
  named '/usr/sbin/sshd', rather than particular process IDs (instances).

  Can only restrict existing permissions (by causing syscall failures/
  permissions denial), cannot grant new privileges.

  Has a training/learning mode that records file/syscall-access and 
  bootstraps policy creation based on this log.

  The syscall is 'chhat()', this changes the 'Hat' that the program is
  using.  Processes either wear a hat, or they _don't_ wear a hat.

  Use sys_chhat($random_cookie) to wear a hat.  The hat (restriction
  policy) can be removed by calling chhat() again with the _same_
  random cookie;  calling with a incorrect value gets your process
  terminated, immediately.  Using 'chhat(0)' means that the hat can never be
  removed;  this one-way trapdoor is used for things like PAM setup.

Current implementation:

  LSM module loaded into the kernel at runtime.

  One tiny kernel patch to re-export a symbol that used to be exported but
  isn't any longer---this should disappear when AppArmour goes for mainline
  kernel integration.  This is to do with converting an inode number into a

  Module contains the PCRE regex-parser for filepath matching and loads this
  into the kernel, amongst other things, this is non-deterministic.

Possible first-glance improvements:

  Remove all the Novell Proprietary Copyrights from the examples and make
  them public domain/BSD.  They currently can't be distributed.

  Switch filepath matcher from regex to glob-based.  Audit this and try to
  ensure it is deterministic;  or, better still:

  Move filepath matcher to user-space, so that all matching is done
  safely;  the kernel can then keep a cache table of previous
  hits/misses.  Is removes all globing *completely* from the kernel and
  seems the safest/cleanest.  Communication via netlink socket or similar.

  Mount the helper filesystem somewhere that is *not* '/security/'.  This is
  non FHS.  Something like '/sys/kernel/security/' if that's what it is
  designed for. 

  Processes have a 'label' (displayed by "ps Z"), this should probably point
  to a something more useful than the name of the executable---eg. point to
  the policy file '/etc/apparmour/usr.some.thing' or the helperfs).

  The Yast GUI tool needs breaking-out/replacing with some nice Python/Gtk+.

My hunches/observations:

  This is more useful^W usable to our users than SELinux.

  Both use the same kernel LSM hooks;  so can be loaded either/or.

  Looks like I could actually configure this without a rocket-scientist's
  University degree.

  By default, Apparmour is off for a class of process.  Nobody's machine is
  going to become unusable.

  Combined with the existing 'sudo' infrastructure, we can give a user
  temporary permissions and then immediate restrict them down to what is
  required.  Eg.  "sudo gedit " but then immediately restricting that
  process to only being able to read/write the file passed to it.
  This can be wrapped up in the 'gksudo/ksudo' call from the GUI shell.


  Be able to freeze the process when it does something naughty so that a
  call to userspace can be made and a "firewall" dialogue pop up asking the
  currently disallowed action should be allowed.  Looking at the freezer/
  suspend code to work out how this might be possible immediately before
  return to userspace.

Britain is just cold, in a pesky way.  London, GB

More information about the ubuntu-hardened mailing list