AppArmor makes it into the 2.6.36 Upstream Kernel
I had the opportunity to talk to John Johansen about AppArmor after I saw a tweet today from Pete Graner about AppArmor being accepted upstream into the 2.6.36 kernel. Matt Zimmerman and Pete Graner also took a moment to give me their thoughts on what this means as well.
I asked Matt Zimmerman, Canonical CTO, about how he viewed this announcement. He said, "I'm very pleased with AppArmor's acceptance by the Linux kernel community, and appreciate all of the effort which went into getting it merged. It's taken a very long time, but this is a success to be celebrated. I hope that this will lay the foundation for greater cooperation between the communities of Linux and Ubuntu developers."
When Pete Graner, Canonical Kernel Team Manager, was asked about the significance of AppArmor being included in the upstream 2.6.36 kernel he said, “ I'm glad Canonical was able to step up and take over maintainership of AppArmor. This allows distros & users to have a rich choice of security mechanisms for Linux which is good for everyone. Personally I'm hoping this will continue down the road of greater cooperation between Ubuntu & the Upstream kernel community.“
John I know you are the upstream AppArmor maintainer and you also work for Canonical on the Kernel Team and I was keen to ask you a few questions in regards to this announcement and all your hard work on AppArmor.
QUESTION: What does this really mean for the end user?
John Johansen: Well in the short term it doesn’t mean much for end users. They won’t see any major changes or improvements right away. Longer term it means that AppArmor is more stable and less effort is needed to maintain an out of tree patchset. This means that there is more time to develop and improve the parts that the end users interact with, which will lead to friendlier tools, and ease of use improvements.
QUESTION : Can you tell folks about why this is important to AppArmor, Canonical, Ubuntu and the upstream kernel?
John Johansen: Well I think the importance is different for each of these. For AppArmor it provides a legitimacy and acceptance from the upstream linux kernel, which will lead to a lower maintenance cost. This basically means that when kernel developers make changes to the kernel that affect AppArmor, they will submit patches to the AppArmor code as well as the rest of the kernel, which will be less work for us than having to develop patches to AppArmor for the changes from scratch. It also means AppArmor has more of voice in the kernel community when changes are made that affect how AppArmor interacts with the kernel.
For Canonical I think the importance is that it shows Canonical is contributing to upstream development and does care about the kernel. This should hopefully lead to better cooperation with the upstream kernel community. Of smaller importance is that it provides Canonical a specific piece of the kernel that it can point to as an upstream kernel contribution. This isn’t meant to belittle the work Canonical has already done, and continues to do by sending patches upstream, but it is generally harder to point out contributions made by patches instead of a specific driver or subsystem.
For Ubuntu the importance is a little different again. It certainly will gain from the benefits that the AppArmor project will see from this, but there will also tangible benefits. With AppArmor going upstream it will now be possible to start merging AppArmor into Debian, which means one less (or a smaller) delta that Ubuntu needs to carry. It also means that Ubuntu’s choosen default security choice (we provide selinux, smack, and tomoyo) will be around a long time (a projects life out of tree is a lot more tenuous).
For the upstream kernel the importance is a couple things, it shows yet again a willingness to work through contentious issues and come to a resolution that allows an out of tree project to getting upstream. The other perhaps greater importance to kernel devs is that the AppArmor code is upstream. This is actually important as there are a lot of people running AppArmor, which means that it shows up in the stack trace of a lot of the bug reports being received (whether it caused the bug or not). Having such a widely used, invasive piece of code (security hooks have their fingers every where in the kernel) out of tree just makes life harder for kernel devs.
QUESTION: Can you give a little history about AppArmor and the journey to getting it accepted in the upstream kernel?
John Johansen: Well the AppArmor project is actually pretty old (I don’t know the full history). It started back in about 1998 - 1999 (if I remember what I have been told correctly) under the name of SubDomain. The goal was to build a security hardened version of Linux, and it was incorporated into to the Immunix distribution along with other technologies like stack protection.
This was pre LSM (Linux Security Module) and it lived as a patch on top of the Linux kernel. The company behind Immuix (WireX who latter changed their name to Immunix) along with some of the selinux people got together and started work on what would become the LSM. The goal being to have a common set of hooks that different security implementations could use.
For various reasons AppArmor didn’t get ported to the LSM until late in the game, and hence the LSM didn’t really have the hooks necessary for AppArmor. This lead to AppArmor having a few ugly hacks in it.
In 2005 Novell aquired Immunix and slowly begain to open it up. I believe the first posting to LKML were in 2006. This didn’t go well as the community rightly pointed out the ugly hacks and chastised AppArmor for being developed behind closed doors.
Ubuntu picked up AppArmor in the summer of 2007 for inclusion into 7.10 (Gutsy) and Novell began a rewrite of AppArmor to get rid of the ugly hacks. The rewrite reworked the LSM and VFS to pass the information that AppArmor needed down into the security module. This patchset was contentious and saw several revisions.
In the fall of 2008 a sort of an agreement was reached with upstream about the correct approach to handle pathname based access control, and the TOMOYO Linux project began submitting the security_path hooks to upstream. These went in around the beginning of 2009 along with another major change (creds). Which lead to AppArmor being rewritten yet again.
Canonical picked up the mantle of AppArmor development in 2009, and saw the first iteration of the rewritten module go into Karmic, with the new code base being pushed up stream for review. Since then its been iteration and cleanup on that initial code set to meet the changes asked for by upstream.
QUESTION: How and where can people help with AppArmor going forward?
John Johansen: Well the AppArmor project can always use help :) There is the simple things like just reporting bugs, to doing translations, writing documentation, getting involved on the mailing list or writing code. The projects main documentation with all the information on how to get the source code etc, is on the wiki (which is it self a work in progress).
http://apparmor.wiki.kernel.org
QUESTION: Is there anything else you want to tell folks about AppArmor that I haven’t asked you about?
John Johansen: Well the dirty little secret is that AppArmor upstreaming isn’t complete. The main portion (core) of AppArmor has gone upstream but there are parts of it that were separated out either because they weren’t amenable to upstream, or because a portion of the code code be logically broken out easing what needs to be reviewed at one time.
What this means is that if you are using an upstream version of AppArmor it currently has reduced functionality. Currently this basically breaks into two parts, the kernel module doesn’t export all the interfaces that the older version does so tools like aa-status and the inti script based profile replacement won’t work. The other part is that the upstream version doesn’t have have the network mediation currently.
Ubuntu carries a compatibility patch on top of the upstream version that provides this functionality. But now that the core bits of AppArmor are upstream we can send in incremental patches to add the missing functionality, since these patches will be smaller and more targeted they will be easier to upstream and soon the upstream version will match and exceed what we currently carry in Ubuntu.
John thank you so much for taking time to let people know more about the history and significance of AppArmor. I can’t wait to see what other exciting things happen over the remainder of the Maverick cycle and into the Ubuntu 11.04 -N cycle.
For more info on how you can download, use, participate and contribute to Ubuntu, visit:http://www.ubuntu.com/community/participate.
Questions, Comments suggestions can be sent to Amber at: amber [AT] ubuntu-user.com.
Comments