Juju and AppArmor

[Clint Byrum]

Excerpts from Jamie Strandboge's message of Thu Sep 29 11:42:06 -0700 2011:
> Hi!
> 
> Juju offers a wonderful opportunity to combine robust and easy
> installations with the security benefits of AppArmor[1]. A big reason
> why policy makers for any Mandatory Access Control (MAC) system like
> AppArmor are unable to shipped usable default policy is because people
> are free to adjust paths for their applications in such a way that it
> makes it difficult to have a general-purpose policy that is usable yet
> still offers security benefits.
> 
> Juju solves this because it gives us the opportunity to do what we never
> could with Debian packaging alone-- have predictable locations for
> files. The charm makers have deep insight into how the application works
> and where it is going to be installed and they can leverage this insight
> to create useful AppArmor policy for their applications. For example,
> someone uses the wordpress charm, and Juju does magic and out pops an
> apache installation with mod-apparmor enabled along with a changehat
> AppArmor policy for wordpress. Wordpress then runs in a confined
> environment that is analogous to a sandbox in such a way that attacks
> against wordpress are limited to only that which is allowed by the
> policy.
> 
> For those unfamiliar with AppArmor[1], it is a very flexible technology
> that can significantly improve the security of applications, has a
> pretty low barrier to entry, works particularly well with isolating web
> applications, and can work with various other technologies. A lot of
> information can be found in the upstream documentation[2][3].
> 
> If people are interested, there is plenty of example policy for daemons
> and other applications in Ubuntu[4]. To confine a web application,
> install the libapache2-mod-apparmor package and read the top
> of /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2 and then you can
> install the phpsysinfo package for an example policy that works with
> mod-apparmor. 
> 
> While we can't really drive this, the Ubuntu Security team would be
> happy to help people in any way we can. Feel free to discuss on the
> ubuntu-hardened at lists.ubuntu.com mailing list or join us in
> #ubuntu-security on Freenode.
> 

Jamie, this is definitely the kind of thing I also envision for juju as
well. The term DevOps Distilled captures this idea nicely, as most ops
guys out there know that they could do more to harden their systems,
but its hard to do so without direct feedback and connection with the
development teams.

Since juju allows those to work together a little more seamlessly (at
least, thats the vision), we should be able to make it even easier to
use things like AppArmor.

Ultimately its going to be something that we add to each charm. I can't
see any kind of blanket automation, but I can see us making it very easy
to remember to add support by warning about it in the 'charm proof'
command, and requiring people to asswert that its not needed before
inclusion in the repository.

I wrote up a page to describe how I see it working here:

https://juju.ubuntu.com/AppArmor

(not linked to just yet)

The way I see it happening is this:

$ charm create my-cool-webapp
...
$ charm proof my-cool-webapp
W: charm has empty apparmor dir (https://juju.ubuntu.com/AppArmor)

If they have an older charm or haven't used charm create..

$ charm proof my-cool-webapp 
E: does not have apparmor directory (https://juju.ubuntu.com/AppArmor)

I also opened a bug against juju to automatically install apparmor profiles:

https://bugs.launchpad.net/juju/+bug/865550

And I went ahead and added this to charm proof/create in charm-tools.