Take the server survey

Products

AppArmor

Software with no bugs is something that we have always dreamed of, but that we'll ever be able to 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

A new installation of the following applications has enforcing AppArmor profiles by default:

  • cups
  • bind
  • mysql
  • slapd (Open LDAP)
  • New in 8.10: ClamAV

Wide list of sample profiles

The following server application 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 come either on trying 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 solutions 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 system. 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 script are widely used throughout the internet, it make it 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,

See Also