User: Password:
Subscribe / Log in / New account

The lightweight auditing framework

The lightweight auditing framework

Posted Apr 8, 2004 22:44 UTC (Thu) by Klavs (guest, #10563)
Parent article: The lightweight auditing framework

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 :)

(Log in to post comments)

Compared to systrace

Posted May 13, 2004 0:09 UTC (Thu) by AnswerGuy (subscriber, #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! :(


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds