Our
first experiences with Novell’s AppArmor
Imagine
you plan to offer an application service hosted on a common LINUX
box. That is not very difficult at all, so you have to go on and
choose your favourite distribution, installing and configuring some
servers (e.g. web- and database servers) and finally adding your web
based application itself. Sooner or later the project was announced,
you’ll have to face with security issues, depending hardly on the
fact, that Internet web applications are always a good target for
possible offences. Right now you are in the circuit of fixing bugs,
upgrading software and closing „open doors“.
As
Mayflower decided to improve the system’s security on some customer’s hosts by request, we stood right in front of the decision between AppArmor and SELinux. How could we
be one little step ahead, before another leak is found and maybe
compromised e.g. in the underlying scripting language PHP ?
Hardening the system and its running processes is always a good idea
– so we’ve done that first. At the same time we read about Novell’s
AppArmor, a security tool which acts beneath the Linux Kernel and –
simply said – controls which application can do whatever on the
system. On current SuSE Linux distribution (10.1 and up) the AppArmor
is bounded by default and more than this – it can be configured
within YaST. Because the customer’s boxes had not always a very current distribution, we
had to compile it by our own, including patching the kernel. It
wasn’t that difficult, but the documentation was not extensive
enough. After the new kernel was up and running, the main task stood
in front of us: profiling the participating processes, including for instance: PHP,
MySQL, lighttpd (as our preferred Web server), Apache, Postfix and others.
Profiling
means: start the target application, or, to be more exact, the
server’s process while AppArmor records all necessary system calls in
the background. As mentioned before, AppArmor carries on file
accesses (e.g. read, write, execute) and logs that kind of events. In
the meantime it is your job to do all the typical things, that the
application will do in the matter it does normally, too. So you start
up with a Unix like rc-command, so your server will come up, reads
its configuration files initially, writes PID- and LOCK files (if
needed), put some information in the system log (or wherever else)
and so on. In case of a web server, you will now do some things like
accessing common documents from the web. More interesting is it to
invoke a further application through the web – the PHP interpreter.
That will do more things on it’s call and during it’s life time.
Exactly on all this possible actions will have AppArmor an eye on. So
it’s a good idea to do as much as expected things during the running
profiling process. The easiest way to do so is to test your live
application in PHP.
In our
case, a therefore developed test application had to do among other typical tasks like MySQL access
or session storage , generating PDF documents, invoking a couple of
background daemon processes (which are very close to the system),
doing a lot of system calls, sending mail through the local MTA and
so on. During the profiling process the expected results occurred:
PHP needed write access to temporally session storage files, wanted
to read the php.ini configuration file and many more. Once the
procedure of profiling is finished, it was our turn to permit or deny
one by one all the previously recorded events. This was done in form
of a console dialogue. As mentioned above, in current SuSE releases
this is a little more comfortable, since you could do it all in YaST.
Depending
on what you decide to allow or deny, AppArmor saves the result in
form of a text based configuration file beneath the /etc/apparmor.d/
directory. The naming convention is the full path name of the target
application, whereas the slashes have been substituted by dots: e.g.
the PHP interpreter configuration will be saved as
/etc/apparmor.d/user.local.bin.php (assuming it is located there,
depends on your local installation).
AppArmor
comes with a few typical configuration files by default. So all you
have to do is to tune the already defined settings, e.g., adjusting
pathnames according to your system’s set-up.
The
major goal of using AppArmor is to be always at least one step ahead
before an application’s security leak is coming up and will be
exploited by some people, regardless of their motivation or
intention.
We
think that AppArmor is one important brick in the application’s- and
security set-up. Among other things (e.g. system hardening, firewall
) it gives you the ability to look behind of what an application will
do during the “real” runtime, and: it lets you decide what is
generally right allowable, or on the other side, what’s rather to
deny.
A last
note: It is often said, AppArmor is more easy than a comparable
“SELinux” – to keep it short: yes, it is! Both follow the same
approach and surely they do their expected work, but we chose
AppArmor based on it’s effective convenience. So if you do not know
your enemy, you probably won’t get to know him ;-)
More information about AppArmor can be found at Novell’s website.
Schreibe einen Kommentar