Juju and AppArmor
jamie at canonical.com
Thu Oct 13 13:55:17 UTC 2011
On Mon, 2011-10-03 at 11:08 -0700, Clint Byrum wrote:
> 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. 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, 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.
> > If people are interested, there is plenty of example policy for daemons
> > and other applications in Ubuntu. 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:
> (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:
> And I went ahead and added this to charm proof/create in charm-tools.
This is excellent!
I have pointed my team at the page for feedback. As mentioned before, if
we can help, don't hesitate to ask (#ubuntu-security on Freenode or
email to security at ubuntu.com).
Thanks so much for your work on this; it is really exciting. :)
Jamie Strandboge | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Juju