public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
From: Paul Moore <pmoore@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>
Cc: Richard Guy Briggs <rgb@redhat.com>, linux-audit@redhat.com
Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
Date: Wed, 22 Oct 2014 11:28:46 -0400	[thread overview]
Message-ID: <5825121.QQHNuuEBO9@sifl> (raw)
In-Reply-To: <1978142.LNMGsIevqD@x2>

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.  I'd like to discuss improving the AVC audit 
record, but that discussion is lower priority than the field ordering 
discussion.

Let's stick to correctly formed audit records that follow the name-value pair 
format perfectly; I argue that while we may get accustomed to a specific field 
ordering, the field ordering for well formed audit records should not be 
guaranteed.

> > Before we go to much farther, I'd really like us to agree that ordering is
> > not important, can we do that?
> 
> Its kind of doubtful we can do anything like this quickly. Maybe over time.

Why?  Why can we not do this now?  What, besides some assumptions by the 
userspace tools, is preventing us from fixing this?

> But for entirely new events, we can create some canonical order and use it.

No.  Field order is a problem, not a feature we need to promote.

> > As a follow up, what do we need to do to make that happen in the userspace
> > tools?
> 
> I have serious doubts that this is worth doing right now.

I disagree.  I think we need to resolve this before we go forward with adding, 
or modifying any audit records.

> To me, these are the burning issues that I think should be on the table to
> be solved rather than field ordering:
> 
> 1) ... {snip} ...

Ignoring the priority for a moment, thanks for posting these.  Is there an 
audit TODO list posted somewhere?

-- 
paul moore
security and virtualization @ redhat

  parent reply	other threads:[~2014-10-22 15:28 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 [this message]
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
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=5825121.QQHNuuEBO9@sifl \
    --to=pmoore@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=rgb@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