On Tue, 08 Dec 2015 19:28:22 -0500 Paul Moore <p...@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. > 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. > This would be more > consistent with the other daemons and the shutdown result field could > potentially be reused by the init systems for other daemons (assuming > the information was conveyed via return values or some other > mechanism). > > > Lifecycle of the system > > ======================= > > When the system is powered on, control is eventually turned over to > > an init daemon. This daemon is responsible for starting up all > > other system services and performing an order system shutdown when > > asked. This init daemon should send a AUDIT_SYSTEM_BOOT event after > > it has done its own initialization. Most init systems have > > different targets or modes of operation that the system is turned > > over for interactive sessions. Examples are multi-user console, > > multi-user graphical, etc. > > You mention it later, but it might be a good idea to mention in this > paragraph that the audit daemon should be started as early as > possible by the init daemon. > > > Init will determine what runlevel the system is ultimately going to > > try to achieve. When gets there or it fails to get there, it shall > > issue an AUDIT_SYSTEM_RUNLEVEL event to denote which mode of > > operation it was going to be in. If an admin requests that the > > system switch to another runlevel, then it should issue another > > AUDIT_SYSTEM_RUNLEVEL event. > > I think it would be good to have a discussion about runlevels that > don't follow the traditional integer numbering, e.g. string based > runlevels. > > * https://people.redhat.com/sgrubb/audit/event-enrichment > > > 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. Also, there are a number of strstr in various bits of code. So, changing to upper case blocks all lower case searches using case sensitive constructs. Nowhere does the audit system consider the field names case insensitive. On the contrary, the specifications call out for field names to be lower case during event creation. > > b) encoded if user controlled data is used for enrichment > > > > 2) The auparse library will: > > a) preferentially use these fields whenever an interpretation is > > requested b) if none exist, look up the fields on the local machine > > if necessary > > I think resolving these fields on the local machine is misleading, > and potentially dangerous; this is especially true with respect to > SELinux labels. If you can't resolve the field, simply display it raw > and let the operator determine how to handle it. Agreed and hence the proposal. I appreciate the feedback. I'll see about making some changes to the proposal next week. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
