The lightweight auditing framework [LWN.net]

One of the patches in Andrew Morton's "merge candidate" tree is the lightweight audit framework. This patch, written by Rik Faith, is intended to be a way for the kernel to get various types of audit information out to user space without slowing things down, especially when auditing is not being used. The framework is meant to serve as a complement to SELinux; it is already being shipped as a part of the Fedora Core 2 test 2 kernel.

There are two kernel-side components to the audit code. The first is a generic mechanism for creating audit records and communicating with user space. All of that communication is performed via netlink sockets; there are no new system calls added as part of the audit framework. Essentially, a user-space process creates a NETLINK_AUDIT socket, writes audit_request structures it, and reads back audit_reply structures in return.

The generic part of the audit mechanism can control whether auditing is enabled at all, perform rate limiting of messages, and handle a few other tasks. On the kernel side, it provides a printk()-like mechanism for sending messages to user space. This code also implements a user-specified policy on what happens if memory is not available for auditing; truly paranoid administrators can request that the kernel panic in such situations.

The audit patch includes some SELinux tweaks to make it use the audit functions rather than printk() when it has something to log.

The audit logging code expects an audit daemon to be running to accept messages via the netlink socket. Code for an example daemon is available in Rik's Red Hat web area. Should there be no daemon running, log messages are simply passed to printk() instead.

In addition to the generic support code, the audit patch includes a mechanism for auditing system calls. One gets the sense that this was the real purpose for the patch. System call auditing is off by default, but a suitably privileged user-space process can turn it on and load a whole set of rules describing what should be logged. Rules can test on various attributes of the calling process, including its process ID, user and group ID (both "real" and "effective"), etc. Rules can also be set to fire on accesses to particular devices or files. Finally, there are also tests on specific system call arguments, whether the call succeeds, or for a specific return value.

Included with the audit daemon is an auditctl utility which can be used for setting and tweaking rules.

The audit mechanism will give system administrators a new tool for looking at what is going on between user space and the kernel. With the addition of some user-space utilities, it could become a powerful facility for tracking down system problems and security issues - or for any number of big-brotherish applications. Expect to see it in 2.6.6.

(Log in to post comments)

The lightweight auditing framework

Posted Apr 8, 2004 22:44 UTC (Thu) by Klavs (subscriber, #10563) [Link]

Whats the diff. from this - and the feature systrace supports for doing exactly this(when recording a profile)? I'm guessing theres a good reason he reinvented the wheel, instead of just using the systrace code for this (he could leave out the allow/disallow parts if he didn't want them) ?

Anyways, just curious - systrace seems like a good idea, and just wondering why he didn't just use its code for the audit part.
There could be a ton of valid reasons ofcourse - just wanted to "throw in" the question that comes to mind.. hoping the vanilla 2.6 kernel will shape up to be a bit more capable security-wise, than vanilla-2.4 is :) (thinking of projects such as LIDS, SELinux (already in via the new cool security-modules feature), systrace, vserver etc.). Unfortunately a project like vserver can't be implemented as a security-module only AFAIK, and perhaps the same goes for systrace?

Why not just patch the stuff in yourself, you might think? Well the problems I found with this, was that some patches I used, were very much incompatible - and my limited knowledge of kernel-code could not figure out how to merge them together - ie. I had to choose what features I wanted to use, out of the ones I would have liked to have :(

I must say the 2.6 is already shaping up very well, as IPv6 and IPSEC is looking good - and as it is now in the kernel (the USAGE version) it won't give me any problems anymore :)

Enough rambling.. its late and I'm just thinking aloud - ignore me if you will :)

Compared to systrace

Posted May 13, 2004 0:09 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

I think the major differences are: systrace is a reference monitor, it can
return a code telling the kernel to allow, (optionally allowing with a specific set of UID/GID credentials!), or deny the access (optionally with a specific errno). However, it only acts on system calls (though it provides canonicalized arguments to the reference monitor in user space; on which the daemon can make its decisions).

This "auditing framework" is clearly targeted toward logging and is more pervasive, extending beyond system calls to other sorts of resources, and having the rate limiting features.

Personally I prefer the systrace approach and would like to see it more widely adopted. SELinux is far too complex and intrusive. However, with the implicit primatur of the NSA giving Red Hat Inc. the lust to include it for future appeal to Gov. and Banking institutions I think that the simpler, more elegant, and (dare I say) equally effective systrace approach will languish in obscurity! :(

JimD

New URL?

Posted Jan 12, 2005 21:50 UTC (Wed) by j1m+5n0w (guest, #20285) [Link]

You can get a readme and kernel patches from the "wayback machine" at archive.org, though they don't have the user space code (auditd-0.4.tar.gz) cached there. I would be interested in finding that myself.

New URL?

Posted Jan 17, 2005 0:45 UTC (Mon) by j1m+5n0w (guest, #20285) [Link]

The kernel patch and auditd (currently up to version 0.5) code is hosted here. According to Rik, it is now maintained by Peter Martuccelli.