From: Richard Guy Briggs <rgb@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
Date: Thu, 30 Oct 2014 10:55:40 -0400 [thread overview]
Message-ID: <20141030145540.GP26201@madcap2.tricolour.ca> (raw)
In-Reply-To: <4831978.tkKbUtpGiO@x2>
On 14/10/22, Steve Grubb wrote:
> On Wednesday, October 22, 2014 04:06:47 PM Paul Moore wrote:
> > On Wednesday, October 22, 2014 01:56:13 PM Steve Grubb wrote:
> > > On Wednesday, October 22, 2014 11:28:46 AM Paul Moore wrote:
> > > > On Wednesday, October 22, 2014 10:25:35 AM Steve Grubb wrote:
> > > > > On Tuesday, October 21, 2014 06:30:24 PM Paul Moore wrote:
> > > > > > 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 ;)
> > > > >
> > > > > Field ordering is important. For example, suppose we decide to make
> > > > > ordering changes to the AUDIT_AVC record to bring it in line with
> > > > > current standards. Would anyone care?
> > > >
> > > > That is an interesting example record considering everyone recognizes it
> > > > to be an oddly formed, special case.
> > >
> > > But it illustrates the point. There are tools that depend on an ordering
> > > and format. There are more programs that just ausearch that needs to be
> > > considered if the fields change. For example, Someone could do things
> > > like this:
> > >
> > > retval = auparse_find_field(au, "auid");
> > > retval = auparse_next_field(au);
> > > retval = auparse_next_field(au);
> > > retval = auparse_find_field(au, res");
> > >
> > > Where, if the field ordering can't be guaranteed, the code becomes:
> > >
> > > retval = auparse_find_field(au, "auid");
> > > retval = auparse_first_field(au);
> > > retval = auparse_find_field(au, "pid");
> > > retval = auparse_first_field(au);
> > > retval = auparse_find_field(au, "uid");
> > > retval = auparse_first_field(au);
> > > retval = auparse_find_field(au, res");
> >
> > In my mind the latter code is more robust and preferable.
>
> Except you can have problems when the event is like this
> auid= pid= old uid= new uid= res=
>
> and yes there are places like that. The performance really is the main issue.
And this is the type of thing that needs to be cleaned up,
disambiguating which field you actually want. Both "old" and "new" are
orphaned keywords that you have indicated are ignored by the parser, so
should be cleaned up to old_uid= and uid=, according to the rules you
have set out.
> -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
next prev parent reply other threads:[~2014-10-30 14:55 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 18:23 [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Richard Guy Briggs
2014-10-07 19:03 ` Eric Paris
2014-10-07 19:39 ` Richard Guy Briggs
2014-10-07 22:06 ` Paul Moore
2014-10-11 15:42 ` Steve Grubb
2014-10-11 20:00 ` Paul Moore
2014-10-21 16:41 ` Richard Guy Briggs
2014-10-21 19:56 ` Steve Grubb
2014-10-21 21:08 ` Richard Guy Briggs
2014-10-21 21:40 ` Steve Grubb
2014-10-29 20:23 ` Richard Guy Briggs
2014-10-21 22:30 ` Eric Paris
2014-10-21 23:14 ` Paul Moore
2014-10-22 1:18 ` Richard Guy Briggs
2014-10-22 14:30 ` Steve Grubb
2014-10-21 22:30 ` Paul Moore
2014-10-22 1:24 ` Richard Guy Briggs
2014-10-22 13:34 ` Paul Moore
2014-10-29 21:09 ` Richard Guy Briggs
2014-10-22 14:34 ` Steve Grubb
2014-10-22 14:25 ` Steve Grubb
2014-10-22 14:30 ` Eric Paris
2014-10-22 14:36 ` Steve Grubb
2014-10-22 15:08 ` Eric Paris
2014-10-22 15:12 ` Eric Paris
2014-10-22 15:51 ` LC Bruzenak
2014-10-22 16:24 ` Steve Grubb
2014-10-22 18:18 ` Eric Paris
2014-10-22 19:36 ` LC Bruzenak
2014-10-22 20:00 ` Steve Grubb
2014-10-22 15:28 ` Paul Moore
2014-10-22 17:56 ` Steve Grubb
2014-10-22 20:06 ` Paul Moore
2014-10-22 20:34 ` LC Bruzenak
2014-10-22 20:44 ` Paul Moore
2014-10-22 21:11 ` LC Bruzenak
2014-10-22 21:29 ` Paul Moore
2014-10-23 14:19 ` LC Bruzenak
2014-10-23 19:08 ` Paul Moore
2014-10-22 20:39 ` Steve Grubb
2014-10-22 21:00 ` Paul Moore
2014-10-22 21:18 ` Steve Grubb
2014-10-23 19:15 ` Paul Moore
2014-10-30 14:55 ` Richard Guy Briggs [this message]
2014-10-30 14:48 ` Typo in AUDIT_FEATURE_CHANGE events [was: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket] Richard Guy Briggs
2014-10-30 15:10 ` Steve Grubb
2014-10-30 15:23 ` Richard Guy Briggs
2014-10-29 21:38 ` [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Richard Guy Briggs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141030145540.GP26201@madcap2.tricolour.ca \
--to=rgb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=sgrubb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox