From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Moore Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Date: Wed, 22 Oct 2014 09:34:41 -0400 Message-ID: <2257794.LVmDKq0bnE@sifl> References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com> <1645943.LlOpH1gJUB@sifl> <20141022012405.GP15532@madcap2.tricolour.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20141022012405.GP15532@madcap2.tricolour.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Richard Guy Briggs Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com [NOTE: Since we are wandering off the original topic I took the liberty of trimming the To/CC line to just the audit list folks, feel free to add back as necessary.] On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote: > On 14/10/21, Paul Moore wrote: > > On Tuesday, October 21, 2014 03:56:10 PM Steve Grubb wrote: > > > 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= > > > > 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 ;) > > Well, I've already been pushing it that way because it interferes with > any sort of refactoring that needs to be done to simplify and clean up > the kernel log code. Exactly. I'm starting to think that we need to resolve this issue before we introduce any new features into the kernel. > > Before we go to much farther, I'd really like us to agree that ordering is > > not important, can we do that? As a follow up, what do we need to do to > > make that happen in the userspace tools? > > At the very least, as I've suggested, agree on at least one more order, > a canonical one, that can provide a much more firm guide how to present > the keywords so that we're not stuck with an arbitrary order that turns > out not to make sense for some reason or another. No, we're already seeing that a single fixed ordering is bad, adding an alternate fixed ordering just kicks the can down the road a bit further and sets a bad precedence for future development. It is time to get rid of the fixed ordering in the audit records. -- paul moore security and virtualization @ redhat