Paranoid Penguin - AppArmor in Ubuntu 9

Psst! Your Ubuntu system has been secretly hardened with AppArmor!

Three years ago, I devoted a couple columns (in the April and August 2006 issues of LJ) to Novell AppArmor, a partial implementation of Mandatory Access Controls (MACs) that Novell had integrated into SUSE Linux as part of its acquisition of Immunix. Novell also had released AppArmor's source code under the GPL. I expressed hope that other distributions soon would offer AppArmor as an easier-to-configure alternative to SELinux.

The good news is, during the three years since I wrote those articles, both Ubuntu and Mandriva have incorporated AppArmor into their respective distributions. Although until recently Ubuntu hasn't provided very much documentation on its AppArmor port—one might even characterize Ubuntu's AppArmor adoption as stealthful—AppArmor actually has been in Ubuntu since Ubuntu 7.10 (Gutsy Gibbon). In fact, I mentioned this inclusion in these very pages in the April 2008 issue, in my article “Security Features in Ubuntu Server”.

At the time, I commented that due to its lack of AppArmor GUI tools or documentation, AppArmor in Ubuntu 7.10 appeared to be targeted at expert users. With Ubuntu 9.04, I'm happy to report that although AppArmor in Ubuntu still is configured strictly via the command line, it's now amply documented and comes with a useful set of default profiles.

The bad news is, in late 2007, Novell laid off all four of its full-time AppArmor developers, raising serious questions about the future of AppArmor (see The Future of AppArmor sidebar).

Being a security goon, I'm not optimistic by nature. However, I do believe in making hay while the sun shines. If a compelling tool is available to you in Ubuntu 9.04, you should take advantage of it and not worry about whether that tool will be available in Ubuntu 11.04—unless, of course, that tool requires an enormous investment in your time, attention and thought.

But AppArmor, unlike most other MAC mechanism, is not such a tool. As I explain in this month's overview of AppArmor in Ubuntu, for many applications, you don't need to do anything to enable or configure AppArmor protection. For others, AppArmor essentially can train itself in protecting them.

So, let's take a look at AppArmor in Ubuntu.

AppArmor Review

In case you missed my earlier articles on this topic, AppArmor is based on the Linux Security Modules (LSMs), as is SELinux. AppArmor, however, provides only a subset of the controls SELinux provides. Whereas SELinux has methods for Type Enforcement (TE), Role-Based Access Controls (RBACs), and Multi-Level Security (MLS), AppArmor provides only a form of Type Enforcement.

Type Enforcement involves confining a given application to a specific set of actions, such as writing to Internet network sockets, reading a specific file and so forth. RBAC involves restricting user activity based on the defined role, and MLS involves limiting access to a given resource based on its data classification (or label).

By focusing on Type Enforcement, AppArmor provides protection against, arguably, the most common Linux attack scenario—the possibility of an attacker exploiting vulnerabilities in a given application that allows the attacker to perform activities not intended by the application's developer or administrator. By creating a baseline of expected application behavior and blocking all activity that falls outside that baseline, AppArmor (potentially) can mitigate even zero-day (unpatched) software vulnerabilities.

What AppArmor cannot do, however, is prevent abuse of an application's intended functionality. For example, the Secure Shell dæmon, SSHD, is designed to grant shell access to remote users. If an attacker figures out how to break SSHD's authentication by, for example, entering just the right sort of gibberish in the user name field of an SSH login session, resulting in SSHD giving the attacker a remote shell as some authorized user, AppArmor may very well allow the attack to proceed, as the attack's outcome is perfectly consistent with what SSHD would be expected to do after successful login.

If, on the other hand, an attacker figured out how to make the CUPS print services dæmon add a line to /etc/passwd that effectively creates a new user account, AppArmor could prevent that attack from succeeding, because CUPS has no reason to be able to write to the file /etc/passwd.

AppArmor on Ubuntu

In SUSE's and Ubuntu's AppArmor implementations, AppArmor comes with an assortment of pretested profiles for popular server and client applications and with simple tools for creating your own AppArmor profiles. On Ubuntu systems, most of the pretested profiles are enabled by default. There's nothing you need to do to install or enable them.

Other Ubuntu AppArmor profiles are installed, but set to run in complain mode, in which AppArmor only logs unexpected application behavior to /var/log/messages rather than both blocking and logging it. You either can leave them that way, if you're satisfied with just using AppArmor as a watchdog for those applications (in which case, you should keep an eye on /var/log/messages), or you can switch them to enforce mode yourself, although, of course, you should test thoroughly first.

Still other profiles are provided by Ubuntu's optional apparmor-profiles package. Whereas ideally a given AppArmor profile should be incorporated into its target application's package, for now at least, apparmor-profiles is sort of a catchall for emerging and not-quite-stable profiles that, for whatever reason, aren't appropriate to bundle with their corresponding packages.

Active AppArmor profiles reside in /etc/apparmor.d. The files at the root of this directory are parsed and loaded at boot time automatically. The apparmor-profiles package installs some of its profiles there, but puts experimental profiles in /usr/share/doc/apparmor-profiles/extras.

The Ubuntu 9.04 packages shown in Table 1 put corresponding profiles into /etc/apparmor.d.

Table 1. Ubuntu Packages Having AppArmor Profiles

Ubuntu Package Name AppArmor Default ModePackage Description
bindenforceThe BIND DNS server
clamdenforceClamAV antivirus scanner
cupsenforcePrint services dæmon
dhcp3-clientenforceISC's DHCP client
dhcp3-serverenforceISC's DHCP server
mysqlenforceMySQL database engine
slapdenforceOpenLDAP LDAP server
tcpdumpenforceCommand-line network sniffer

If you install the package apparmor-profiles, you'll additionally get default protection for the packages shown in Table 2.

Table 2. Packages Whose AppArmor Profiles Are Provided by apparmor-profiles

Ubuntu Package NameAppArmor Default ModePackage Description
pingcomplainNetwork diagnostic tool
klogdcomplainKernel message logger
syslogdcomplainBerkeley system message logger
syslog-ngcomplainSyslog-NG system message logger
avahi-daemonenforceMulticast-DNS (network auto-discover)
dnsmasqcomplainDNS/DHCP forwarder used for Internet connection sharing
identdcomplainMaps user names to processes/sockets
mdnsdcomplainScans for Multicast-DNS services
nmbdcomplainPart of Samba (MS file sharing)
nscdcomplainNameservice (DNS) Caching Dæmon
ntpdcomplainNetwork Time Protocol Dæmon
smbdcomplainPart of Samba (MS file sharing)
traceroutecomplainNetwork diagnostic tool

The lists in Tables 1 and 2 are perhaps as notable for what they lack as for what they include. Although such high-profile server applications as BIND, MySQL, Samba, NTPD and CUPS are represented, very notably absent are Apache, Postfix, Sendmail, Squid and SSHD. And, what about important client-side network tools like Firefox, Skype, Evolution, Acrobat and Opera?

Profiles for those applications and many more are provided by apparmor-profiles in /usr/share/doc/apparmor-profiles/extras, but because they reside there rather than /etc/apparmor.d, they're effectively disabled. These profiles are disabled either because they haven't yet been updated to work with the latest version of whatever package they protect or because they don't yet provide enough protection relative to the Ubuntu AppArmor team's concerns about their stability.

Testing and tweaking such profiles is beyond the scope of this article, but suffice it to say, it involves the logprof command.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Ubuntu 9.10, soon to be

Anonymous's picture

Ubuntu 9.10, soon to be released, has even more profiles. See:
https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#GNOME
https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview#AppArmor

It should also be noted that the Ubuntu kernel team has put a lot of effort into getting AppArmor into the upstream kernel. See http://thread.gmane.org/gmane.linux.kernel.lsm/9493 for details. IMO, the future of AppArmor has never looked better.

I switched from Suse because

Tinker's picture

I switched from Suse because of their policy of messing with my system, I avoided distro's that implemented SELinux without my permission. I noticed the stealth introduction of AppArmor which I do not want and the fact there is no documentation of how to disable it. Is there any Linux distro left that allows me freedom of choice?

Disabling AppArmor is

John Johansen's picture

Disabling AppArmor is documented here

Sorry for the bad link, See

John Johansen's picture

Sorry for the bad link,

See https://help.ubuntu.com/community/AppArmor#Disable%20AppArmor%20framework for details on how to disable AppArmor.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix