Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On Tuesday, October 21, 2014 06:30:29 PM Eric Paris wrote:
On Tue, 2014-10-21 at 17:08 -0400, Richard Guy Briggs wrote:
> On 14/10/21, 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=
>
> We already have audit_log_task() which gives:
> auid=
> uid=
> gid=
> ses=
> subj=
> pid=
> comm=
> exe=
>
> This is missing tty=, but has gid=. Can we please use that function
> instead and add tty=? And while we are at it, refactor
> audit_log_task_info() to call audit_log_task()?
>
> Is this standard set above what should be used for certain classes of
> log messages?
>
> Yes, it will be in a different order because we don't have a canonical
> order yet. Can we accept two orders of keywords so we can start
> canonicalizing, please?
I've always hated the fact that we include this in ANY current audit
message. I truly believe we need two new record types.
AUDIT_PROCESS_INFO
AUDIT_EXTENDED_PROCESS_INFO
It'll eat at least 60 bytes per record and its its an aggregated log, then
throw in the length of the system names. Disk space is at a premium. We want
as many records as possible in the logging partition. Also, this will
translate into more network traffic, more buffers needed in the kernel queue,
more buffers in audispd and remote logging.
What does my UID have to do with a syscall? Why is it in the record?
To save space. But also because it may be relevant to whatever is happening.
-Steve