Linux audit performance impact

Paul Moore paul at paul-moore.com
Fri Feb 20 21:22:04 UTC 2015


On Fri, Feb 20, 2015 at 1:29 PM, Casey Schaufler <casey at schaufler-ca.com> wrote:
> The existing audit system is pretty hard on the security modules, too.

Yep.

> An internal structure that captures the information and formats it later
> makes a whole lot of sense provided the information required to do the
> formatting is available at that later time. It also allows for flexibility
> in adding new information to audit records. A new security module could
> add information it considers "security relevant" that other modules don't
> without mucking up the audit records from existing modules.

Yep.  However, just so we're clear, what I'm proposing is just a
change in the kernel API and record format, ultimately the on disk
format will be dependent on the audit userspace.  The good news is
that if we can move away from this fixed string format it opens the
door for different log formats; you could stick with the existing
goofy strings or switch to any other format you like, you just have to
write the daemon/tools.

I may end up writing some dummy tools just as part of the kernel
development process, and I might even maintain them as a simple
example of an audit userspace.  However, my hope is that Steve will
update his audit userspace to take advantage of the new API when it is
ready.

> In Irix (The kids on the list can look that up elsewhere :) ) audit
> data was gathered as a collection of audit tokens, each of which
> contained a chuck of information such as the MLS label, or the DAC
> attributes of a process. The tokens were combined to create a complete
> record late in the processing. The scheme didn't require much in the
> way of structure.

My main goal is to try and create a sane API/record-format for the
kernel that is maintainable over time and feature creep.  My secondary
goal is to push as much processing out of the kernel as possible, both
for performance and flexibility reasons (see my main goal).  A binary
record format based around netlink attributes is likely the path of
least resistance for these goals.

> I've done several audit systems and would be happy to contribute
> to a revision of the Linux implementation.

Well, good news, you're in the right place.  My patches will be posted
here and all are welcome, and encouraged, to provide their comments
and/or patches.

-- 
paul moore
www.paul-moore.com




More information about the Linux-audit mailing list