Novell and AppArmor

 
 
By Jason Brooks  |  Posted 2006-05-14 Email Print this article Print
 
 
 
 
 
 
 


However, the Linux community isnt there yet: While most significant distributions do offer SELinux packages, only Red Hat enables the framework by default. Whats more, Novells SUSE Linux—which, next to Red Hat, enjoys the most prominence among enterprise users—has started down a separate, and incompatible, path for application lockdown.

Novell and AppArmor

Last year, Novell purchased Linux security vendor Immunix, along with the companys AppArmor application containment product.

AppArmor had been available as a proprietary add-on for Novells SLES (SUSE Linux Enterprise Server), but, after completing the Immunix deal, Novell released the software under the GNU GPL (General Public License).

Novell is now working to submit the newly freed project for inclusion in the mainline Linux kernel, where it would join rival SELinux as an application lockdown option for Linux.

Like SELinux, AppArmor plugs into the Linux kernel through an interface called LSM (Linux Security Modules). When Red Hat first sought to submit SELinux for submission in the kernel, Linus Torvalds and other kernel developers demurred from crowning a particular security framework as the kernels one true path to mandatory access control and called for a generic mechanism through which multiple frameworks could connect—hence, LSM.

Red Hat and Immunix each contributed to LSM, which made its debut in the 2.6 kernel release.

However, while SELinux and AppArmor plug into the kernel in a similar way, the two systems take separate approaches: Where SELinux depends on object labeling, AppArmor controls are based on path-name locations. For instance, when we created an AppArmor profile to contain the Apache service on our OpenSUSE 10.1 RC3 system, we began by specifying for AppArmor "/usr/sbin/httpd-prefork," the Apache binary on our test system.

From there, AppArmor went into a learning mode, where it monitored the files that Apache read, wrote and executed, along with the POSIX capabilities that the service called on as we started Apache, interacted with our Mediawiki test site and shut down Apache.

Next, AppArmor stepped us through the actions that Apache had taken, asking us whether each should be allowed in our profile.

In the case of our Mediawiki application, AppArmor also gave us the option of enabling its "changehat" capability. That is, when Apache interprets PHP scripts, AppArmor can switch to a separate profile for the PHP operations, rather than execute those operations under the same profile as the rest of Apache. AppArmors changehat feature also works with Apaches mod_perl facility.

AppArmor hangs its hat on ease of use, and, while rolling our own profiles wasnt as easy as using the premade policies that Red Hat ships with SELinux, doing it ourselves in AppArmor wasnt much tougher. And, when dealing with an application for which theres no existing policy or profile, its no contest—App-Armor makes policy creation much simpler.

AppArmor ships with a complement of premade profiles for common network-facing services. Whats more, while we had to really pore through the source of SELinuxs policies to get a direct look at its rules of enforcement, AppArmor profiles are significantly shorter and easier to read.

The AppArmor approach delivers a smaller range of potential functionality than SELinux: AppArmor does not set out to lock down the entire system, as SELinux and a strict policy can, and AppArmor does not offer a route to multilevel security, as SELinux does.

Novell officials have said they are looking for a multilevel security solution that could plug into the kernel via LSM, function alongside AppArmor and exhibit ease of use similar to that of AppArmor. AppArmor also lacks SELinuxs capacity for implementing role-based access.

Microsoft, Novell and Red Hat discuss existing relationships. Click here to read more. We could, however, use AppArmors trait of interpreting a hard link to an application as a separate entity (and, therefore, a candidate for its own profile) to create a rights-limited version of the bash shell. We could then assign this shell to a user to provide for some administrative privileges without giving up full root access.

Its only been since January that AppArmor has been licensed under the GPL, so, while we can test the softwares effectiveness in the SLES 9 and OpenSUSE 10 and 10.1 distributions on which its now available, its too early to see whether AppArmor will take off in other Linux distributions. AppArmors pedigree stretches back a bit through Immunix, but the softwares previous proprietary licensing has retarded its spread.

Novells AppArmor team is seeking involvement from other major Linux distributions, such as Fedora, Debian and Gentoo. However, with current Linux access-control efforts spread among SELinux and other projects, including GRsecurity and RSBAC (Rule Set Based Access Control)—neither of which weve tested yet—Novell may have to work hard to win converts.

Senior Analyst Jason Brooks can be reached at jason_brooks@ziffdavis.com.

What about Microsoft?

Four years ago, Microsoft laid out an ambitious plan for building an NGSCB (Next-Generation Secure Computing Base). NGSCB was to be a trusted computing environment extending from motherboard-embedded security chips, through the Windows kernel and out to the application windows and input peripherals with which users interact with the system. As a major player in the server space, Microsoft should offer the sort of mandatory access controls were beginning to see in Linux and Solaris. For now, though, the bulk of Microsofts privilege management is centered on the desktop.

* Reduced rights for Internet Explorer IE doesnt require all the rights of a limited user, let alone an administrative one, to do the work of rendering Web pages. In Vista, IE will run by default with less privilege rope with which to hang itself (and the system as a whole).

* A Vista for nonadmins Perhaps its silly to worry about limiting applications to the fewest privileges they require when, according to Microsoft officials, the difficulty of running current Windows versions with appropriately limited rights leads about 80 percent of business users to run as admins—a management gap that Vista should help patch.

* Virtualized system file stores If you cant control exactly what a particular application is allowed to do, you can at least issue it a safer sandbox in which to run. Vista will let applications that want to run as administrators modify system files and registry keys, but do so in a branched-off, virtualized area.

* Still hankering for NGSCB? Microsofts NGSCB developers are now called the System Integrity Team, and they have a blog at blogs.msdn.com/si_team/default.aspx.

For reader response to this article, click here. Check out eWEEK.coms for the latest news, views and analysis on servers, switches and networking protocols for the enterprise and small businesses.


 
 
 
 
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel