The future of AppArmor

By Jake Edge
October 17, 2007

Late last month, Novell laid off the development team for the AppArmor security tool. AppArmor is widely deployed by SUSE Linux users to restrict programs from accessing things that they shouldn't. Novell intends to keep shipping AppArmor, while two other distributions are adding support for it, which makes this move a bit puzzling. Reasons are hard to come by when a "reduction in force" (a common euphemism for layoff) happens, but Novell did clearly indicate that they had no plans to stop using AppArmor as the "core security technology in SUSE Linux Enterprise."

When a project team is laid off, it is common for the team to lose interest in the project – go off to find other things to do – but that does not appear to be the case here. Some of the laid-off team members have formed Mercenary Linux to do AppArmor consulting. They intend to work with Novell and others to guide AppArmor through the kernel submission process, with the goal of getting merged into the mainline. There are some hurdles to clear before that can happen – if it does – but AppArmor does not have the look of a project being abandoned, at least yet.

AppArmor was originally a proprietary program, which Novell acquired in 2005 when they bought Immunix, the company that developed it. In January 2006, Novell released it under the GPL and in April of that year, submitted it as a patch for inclusion in the kernel. The reaction was rather unfavorable, with the main issue being the reliance on paths, rather than information stored in the filesystem inode, to determine security policy. The main advantage cited by AppArmor proponents is that it is much easier to understand and manage compared to SELinux, its main competitor in the Linux security module arena.

AppArmor is included in SUSE Linux and has become popular, so much so that both Mandriva and Ubuntu are shipping it in their next releases. Because of that, Crispin Cowan, founder of Immunix and former AppArmor team lead at Novell, guesses that "by early 2008 a majority of all Linux users will have AppArmor running on their desktop."

After letting the developers go, Novell has no plans to stop shipping AppArmor according to Kevan Barney, senior public relations manager:

We remain committed to AppArmor as our application security solution inside SUSE Linux Enterprise. We have no plans to change to SELinux or another alternative technology, although we always reserve the right to evaluate market conditions to provide the maximum value to our customers.

AppArmor is shifting to an open source development model, where Novell will still be participating as part of the community. As Barney puts it:

[...] we partner with the community to provide a part of the innovation and testing efforts, which we complement with our own focused efforts and investments. Novell will continue its maintenance of the core kernel code and will continue in our efforts to move this upstream. We will also invest in key new features as driven by market need.

Cowan agrees that the project is moving away from a one-company model: "AppArmor is becoming a truly distributed open source project, and Mercenary Linux hopes to be the hub of that community." He and the other former team members who formed Mercenary Linux are poised to assist with AppArmor development:

We have an ongoing commitment to the community that we will work to fulfill - distribution vendors needing integration help, consulting firms looking for even better management tools, and bug fixes for the distributions that AppArmor is deployed in.

Both Novell and Mercenary will be pushing to get AppArmor into the kernel, with another patch submission from Novell expected soon. The impediments to getting those patches accepted are outlined by Cowan:

The barriers to acceptance are both technical and political. Technical is "the way you want to do something conflicts with the way I want to do something" and political is "... and mine is more important than yours" :-) An unfortunate resolution to that is a slugfest of whose really is more important, and an adroit solution is to find a way to achieve both that doesn't conflict. Developers at Novell and Mercenary are working on that latter path.

AppArmor provides some amount of protection against programs trying to access files or perform actions that they shouldn't. Just how much protection it provides is the subject of much debate. There are valid concerns that it papers over the complexities of securing Linux, providing a false sense of security, but it would appear that there is a clear path for it to be included in the kernel. After Linus Torvalds's recent pronouncement that the Linux Security Modules API would stay in the kernel, one potential barrier to AppArmor acceptance has fallen.

It remains to be seen if Novell, Mercenary, and the AppArmor community can work with the kernel hackers to resolve some outstanding issues. The path-based architecture of AppArmor, while contentious, is not likely to keep it out of the kernel. It has been a year and a half since the first submission, though; it will require a concerted effort to work through the process. With three distributions shipping it and minimal impact on those who do not enable it, it seems pretty unlikely that it will stay out forever.

Index entries for this article
Security	AppArmor
Security	Linux Security Modules (LSM)

The future of AppArmor

Posted Oct 18, 2007 14:14 UTC (Thu) by jengelh (guest, #33263) [Link] (1 responses)

>There are valid concerns that it papers over the complexities of securing Linux, providing a
false sense of security.

You use SELinux and when you /think/ you've got your policy right (giving you a sense of
security), there might be still something left that remained open because you could not find
it in that not-papered-over complexity.

The future of AppArmor

Posted Oct 19, 2007 12:48 UTC (Fri) by t8m (guest, #31777) [Link]

I don't think so. As there are strictly only allow rules in policy so you are only adding
actions which the restricted application can do it is unlikely. On the other hand it is one of
the reasons why writing a policy is  relatively hard and that SELinux tends to "break" apps.
But that's a price for being correct and not oversimplifying security.