New draft standards

[Paul Moore]

On Wednesday, December 09, 2015 11:35:02 PM Steve Grubb wrote:
> On Tue, 08 Dec 2015 19:28:22 -0500
> 
> Paul Moore <paul at paul-moore.com> wrote:
> > Okay, let's not call these "standards" and just stick with
> > "specifications". The term standards has all sorts of connotations
> > associated with it, both good and bad, and I think we should be clear
> > when we start talking with other developers.  I think it would also
> > be *very* helpful if you could explain the motivation behind these
> > specs so we understand what problems you are trying to solve and what
> > requirements you are trying to meet; you talk about this a bit in the
> > conclusion, but more background would be nice.
> > 
> > Another nit-picky comment, in the future I would suggest sending the
> > specs inline in your mail;
> 
> I think it was updated 6 times between my email and your's. :-) The
> link means you review a doc that already is fixed in a number of ways
> before your info.

The link means it is annoying for me to review and comment.  The more annoying 
something is, the lower the priority I assign it.  The lower priority ... 
well, you get the idea.  At least I hope you get the idea.

When you ask for comments from a group of people you are always going to be in 
the position of having to reconcile multiple sets of feedback across multiple 
revisions of a document.  Hosting a plaintext document over http doesn't solve 
that in any meaningful way, in some cases it actually hides changes and makes 
the document history less clear.

Just use the mailing list.

> > Anyway, on to your docs ...
> > 
> > * https://people.redhat.com/sgrubb/audit/system-lifecycle.txt
> > 
> > > System Lifecycle Auditing
> > > =========================
> > > This document will go over the events that are associated with
> > > starting up a system and shutting it down. Knowing what events make
> > > up these actions allows an analytical application to know the
> > > boundaries of all sessions and actions a user may perform. It also
> > > allows identification of crashed systems or malfunctioning
> > > services. The following table lists the events that make up the
> > > system lifecycle in the audit trail:
> > > 
> > > AUDIT_SYSTEM_BOOT - System boot
> > > AUDIT_SYSTEM_RUNLEVEL - System runlevel change
> > > AUDIT_DAEMON_START - Audit daemon startup record
> > > AUDIT_DAEMON_ABORT - Audit daemon error stop record
> > > AUDIT_SERVICE_START - Service (daemon) start
> > > AUDIT_SERVICE_STOP - Service (daemon) stop
> > > AUDIT_SYSTEM_SHUTDOWN - System shutdown
> > > AUDIT_DAEMON_END - Audit daemon normal stop record
> > 
> > Why both an AUDIT_DAEMON_ABORT and an AUDIT_DAEMON_END and not just
> > an AUDIT_DAEMON_STOP with a field to indicate if it was a normal
> > shutdown or a failure as outlined in the spec?
> 
> This is documenting historical behavior that has not changed.
> Originally, the event type held more weight about what was happening to
> the system. I think there's a few more details for this particular
> event, but that is the main reason.

It might be nice to add some text about what is currently done in your 
document.

> > > Audit Event Enrichment
> > > ======================
> > > 
> > > There are times when the audit events are stored in another machine
> > > and need to be searched at a later date. Some parts of the audit
> > > event are temporally limited in duration or unique to a system.
> > > This makes interpretting fields that are numbers into human
> > > readable fields hard or impossible without running a report at the
> > > time of the event or on the machine the event occurred on.
> > > 
> > > To address this issue, the audit daemon will get a new mode,
> > > enrich, where the audit trail will be amended as follows at the
> > > time an event is logged:
> > > 
> > > 1) Translations will be:
> > >   a) appended to the end of the event with the field's name in
> > > 
> > > capital letters
> > 
> > Please no, let's leave field names case insensitive, perhaps an
> > agreed upon suffix, e.g. "-trans"?
> 
> This is solving multiple issues. Grep auid would also hit auid-trans.

If you are simply greping on "auid" without any consideration of the 
characters preceding or following that string you are asking for trouble.  I 
don't buy this as a valid reason to use uppercase for the translated fields.

> Also, there are a number of strstr in various bits of code.

The same arguments apply here.

> So, changing to upper case blocks all lower case searches using case
> sensitive constructs.

You still run into the problem that the searches you propose, e.g. 'grep 
"auid"' are bad searches in the first place and moving to uppercase field 
names doesn't really solve anything as 'grep "AUID"' is still problematic.

-- 
paul moore
www.paul-moore.com