AppArmor:

Ubuntu Server Edition

Software with no bugs is something that we have always dreamed of, but that we'll never see. Unfortunately some of these bugs can lead to exploits, therefore endangering the whole system the software is running on. No "perimeter security" will ever be able to detect all malformed expression in a URL, which can lead to a complete takeover of a machine.

In order to limit this type of issue, it is now possible to restrict what a given piece of software can and cannot do on a system. AppArmor has been designed to do just that.

Benefits

Simple to implement

AppArmor does not require complex scripting to implement. This means that very little or no training will be required for a system administrator to define the rights a given application will have on its environment, meaning the system it is running on.

Positive security

Given this capacity to limit the ability of (let's say) Apache, to go write or execute elements outside of the very few directories where it should, AppArmor will ensure that nothing can be done outside of it and generate appropriate warnings when it happens.

Name enforcement (Dynamic Labelling)

All one has to know is the name of what should be allowed, and this is all that is necessary to prepare the secure environment of a given application.

Default enforcement

By default, a new installation of the following services will have AppArmor profiles enforced:

cups
bind
mysql
slapd (Open LDAP)

Wide list of sample profiles

The following server applications are de-facto supported by AppArmor through the sample profiles provided with Ubuntu :

syslog
postfix
ntp
traceroute
samba
cron
nx
dhcp
apache
subversion
clamav
spamassassin
ftp
imap
pop
...

But AppArmor can also be run on the desktop to protect it from getting exploits through its various interation with the outside world :

acrobat reader
gaim
opera
firefox
gnome
man
...

Why do I need a secured environment for my applications ?

Most system attacks nowadays are due to poor password protection or known vulnerabilities in software. While many solutions exist to help solve the first problem, controlling the abilities a given piece of code has is the only foolproof solution for the second. Of course vulnerabilities are published and fixes are produced, but no matter how quickly the fixes are applied, there will always be a gap between publication and installation of patches. Attacking systems in this gap, or before a vulnerability is known, is what is commonly called zero day attacks.

AppArmor will not block these vulnerabilities from existing, but it will limit what the malicious code will be able to do with it. This very often means preventing the attacker from gaining full control of the system the application is running on and warn the administrator when such an attempt is made.

Example

Let's imagine we are running an Apache web server on one of our systems. Even though Apache is a very largely deployed, and therefore tested, application, very often Apache is used to produce content dynamically through the use of scripts or cgis written in a wide variety of languages such as perl, php, python and many more... All the web applications that one installs on Apache, such as blogging software, webmails, calendaring, photo galleries, CMS, etc. are written in one of these languages.

Very often, a vulnerability is coming not from Apache itself but from one of these scripts running on top of it, and because these scripts are widely used throughout the internet, it makes a very tempting pray for the malicious users that are thrilled by the idea of taking over the usage of someone else's machine for a variety of reasons, ranging from sending spam to steeling valuable data. By defining what Apache will be able to read, write or execute on the system, through a list of accessible ressources such as the example below, we will prevent apache from accessing the password database or execute any binaries or script placed elsewhere. Profiling additional resources can be as simple as adding these few lines:

	  /srv/www/htdocs/ r,
	/srv/www/htdocs/** r,
	# virtual hosting
	/srv/www/vhosts/ r,
	/srv/www/vhosts/** r,
	# mod_userdir
	@{HOME}/public_html/ r,
	@{HOME}/public_html/** r,
	/srv/www/rails/*/public/ r,
	/srv/www/rails/*/public/** r,

New in 8.10:

A new profile protects clamav by default

New in 9.04:

New profiles have been added for dhcp3-server, dhcp3-client and tcpdump by default.

New in 9.10:

AppArmor in Ubuntu 9.10 features an improved parser that uses cache files, greatly speeding up AppArmor initialisation on boot. AppArmor also now supports 'pux' which, when specified, means a process can transition to an existing profile if one exists or simply run unconfined if one does not.

Please see the AppArmor documentation for information on using AppArmor in Ubuntu.

New profiles

In addition to the above changes to AppArmor itself, several profiles were added. Enforcing profiles for ntpd, and libvirt are enabled by default. Complain mode profiles for Dovecot are now available in the apparmor-profiles package.

An AppArmor profile is now available for Apache in the libapache2-mod-apparmor package. When used in combination with the mod_apparmor Apache module, web applications can now be protected and isolated from each other. Instructions for enabling the profile are in the /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2 file.

Please see the SecurityTeam/KnowledgeBase for a full listing of readily available profiles in Ubuntu.

Libvirt

Libvirt now contains AppArmor integration when using KVM or QEMU. Libvirtd is configured to launch virtual machines that are confined by uniquely restrictive AppArmor profiles. This feature significantly improves virtualisation in Ubuntu by providing user-space host protection as well as guest isolation. This is particularly important for multi tenant usage of Ubuntu Enterprise Cloud.

About Ubuntu