Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
[NOTE: Since we are wandering off the original topic I took the liberty of
trimming the To/CC line to just the audit list folks, feel free to add back as
necessary.]
On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote:
On 14/10/21, Paul Moore wrote:
> On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote:
> > audit_log_task_info logs too much information for typical use. There are
> > times when you might want to know everything about what's connecting.
> > But in this case, we don't need anything about groups, saved uids,
> > fsuid, or ppid.
> >
> > Its a shame we don't have a audit_log_task_info_light function which
> > only records:
> >
> > pid= auid= uid= subj= comm= exe= ses= tty=
>
> This is getting back to my earlier concerns/questions about field
> ordering, or at the very least I'm going to hijack this conversation and
> steer it towards field ordering ;)
Well, I've already been pushing it that way because it interferes with
any sort of refactoring that needs to be done to simplify and clean up
the kernel log code.
Exactly. I'm starting to think that we need to resolve this issue before we
introduce any new features into the kernel.
> Before we go to much farther, I'd really like us to agree
that ordering is
> not important, can we do that? As a follow up, what do we need to do to
> make that happen in the userspace tools?
At the very least, as I've suggested, agree on at least one more order,
a canonical one, that can provide a much more firm guide how to present
the keywords so that we're not stuck with an arbitrary order that turns
out not to make sense for some reason or another.
No, we're already seeing that a single fixed ordering is bad, adding an
alternate fixed ordering just kicks the can down the road a bit further and
sets a bad precedence for future development. It is time to get rid of the
fixed ordering in the audit records.
--
paul moore
security and virtualization @ redhat