On Fri, Feb 20, 2015 at 1:29 PM, Casey Schaufler <casey(a)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