On 15/02/18, Paul Moore wrote:
On Wed, Feb 18, 2015 at 4:13 PM, Richard Guy Briggs
<rgb(a)redhat.com> wrote:
> On 15/02/17, Viswanath, Logeswari P (MCOU OSTL) wrote:
>> I agree that changing the formatting of the records could break the existing
applications
>> that consume them, and I didn't mean changing or eliminating of the
formatting completely.
>> We agree that formatting is required for logging the records(as buffers) into
the log files.
>> We are wondering if these records can be made available as RAW records so that
the
>> analytical programs which are capable of reading them for processing can perform
better.
>
> There are tools that completely ignore any of the audit userspace suite
> including libaudit, so changing the formatting in the kernel and
> deferring to userspace to later do that formatting is not currently an
> option.
It is if you take a versioned API approach where the kernel defaults
to the current behavior and switches, per-socket/connection, at the
request of userspace. It's really the only way to have a graceful
transition with audit.
Agreed.
>> This option of RAW mode for the events can be an additional
option
>> where, kauditd delivers the audit buffer without formatting. Any
>> comments on this?
>
> For a transition period if we were to consider it, it would mean
> rewriting *all* places in the kernel that generate audit messages and
> provide two paths switched on this RAW mode for each one of them, then
> copying all that duplication to userspace libaudit.
Your comment is a little vague, so let me mention what I'm currently
considering: we convert all of the in-kernel audit users away from
generating strings in the context of the caller, instead having them
record information in a native/struct/etc. format that would be later
used by the kernel audit subsystem to generate the audit records (in
whatever format(s) is(are) requested). This actually has advantages
beyond the record format work, it moves the issue of record formatting
(always a problem) out of the caller and into audit itself which
should hopefully prevent future audit abuses (a netlink attribute
based record format would likely help further).
This approach seems good to me.
> According to Linus' decree, it would need to remain that way
until we
> were certain that all tools including ones we don't know about had
> switched over.
I would imagine a scenario where we introduced the new format in stages:
#1 - Move in-kernel audit record string generation completely into
kernel/audit*.c. Benefits everyone regardless of the audit format.
Ok.
#2 - Introduce a versioned audit API. The most difficult step for
obvious reasons.
That infrastructure should already be in place. We just converted over
the version field to a bitfield listing the availability of features.
An initial call can be made to find out if it is supported, then use the
feature switching bitfield to enable it. We could alternately make a
different unicast socket available signalling its availability.
#3 - Deprecate the old/existing audit record format, make it a
Kconfig
option that defaults to off and emit a warning when the old formatting
is used. This will be a year, and most likely more, after step #2.
#4 - Remove the old/existing audit record code. Once again, this
would happen a couple of years after step #3.
I suspect in practice stesp #3 and #4 could take a lot longer.
However, nothing is really determined yet, this is just my current
thinking.
paul moore
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545