lkml.org 
[lkml]   [2014]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
Date
On Tuesday, October 21, 2014 05:08:22 PM Richard Guy Briggs wrote:
> On 14/10/21, Steve Grubb wrote:
> > > super crazy yuck. audit_log_task_info() ??
> >
> > 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=?

gid is important for things that might allow access by file permissions. But
the syscall logging is going to have that and much more. In this case, access
is granted by having a posix capability. So, all we want is what's the
process, who's the user, which session/tty is this coming from to find all
events that might be related.


> And while we are at it, refactor audit_log_task_info() to call
> audit_log_task()?

That will cause problems at this point.

> Is this standard set above what should be used for certain classes of
> log messages?

Its hard to say if that is sufficient for all cases. When access is granted by
posix capability, sure. This is probably good for most kernel originating
events. But there are times extra info is needed.

> 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 don't understand what you are getting at.

-Steve

> > > > + audit_log_format(ab, " group=%d", group);
> > >
> > > group seems like too easily confused a name.
> >
> > nlnk-grp is better if its what I think it is.
>
> Where did you find that name? That could work and it is shorter, but it
> seems awkwardly optimized. "nlnk" doesn't appear once in the kernel.
> "nl" is already recognized for netlink, "mcgrp" is already used for
> "multicast group(s)", so I would suggest "nl-mcgrp".
>
> > -Steve
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@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



\
 
 \ /
  Last update: 2014-10-22 00:21    [W:0.112 / U:1.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site