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 17:00:03 -0400 Message-ID: <3317728.dvkNIPeE7c@sifl> References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com> <1438858.gaYjDkNvLv@sifl> <4831978.tkKbUtpGiO@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4831978.tkKbUtpGiO@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: Richard Guy Briggs , linux-audit@redhat.com List-Id: linux-audit@redhat.com On Wednesday, October 22, 2014 04:39:49 PM 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= I honestly don't see the problem here. > and yes there are places like that. The performance really is the main > issue. So you've said. As I've said, I'm not convinced. > > > Which of the two is likely to be faster? Especially when doing realtime > > > analysis as a plugin and needing to finish because another event is > > > coming in? Just like a binary struct has to maintain an order of data > > > members if written to disk, the sequence of fields need to be maintained > > > in a text record. > > > > What about the speed and performance of the code in the kernel? > > kprintf is the same speed no matter what the order. Having to duplicate code in the kernel has a negative effect. > > What about the maintenance burden of having to duplicate code to ensure a > > fixed format? > > There just isn't a need to be altering events. We've had to add a few things > here and there, but its only been a couple changes. See the earlier comments on Richard's patch. > > > > > > 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? > > > > > > There are more pressing needs on the user space side of this. reordering > > > fields means I have to drop all my current plans and redo something > > > that's been working fine. This is why it takes so long to get audit > > > utilities and reports that are fast, understandable, and the right > > > information. > > > > I disagree about the priority. Eric disagrees about the priority. > > Richard hasn't explicitly stated he disagrees with the priority but he has > > made several comments on this list about ordering being an issue (Richard, > > my apologies if I am putting words in your mouth). > > What events do people need to change and why? There's not been any > discussion that I know of saying we need to add fields or change them > around. See the earlier comments on Richard's patch. > > What would we need to change in the userspace to eliminate the reliance on > > field ordering? > > Many of the utilities. ausyscall & autrace might be the only ones not > affected. So we would need to change ausyscall and autrace, possibly others. Do you expect to need any changes to the deamon or audit libraries? > > I understand if you don't have a well developed list of items, > > but surely you must have some idea? > > > > I'm willing to help here, and I suspect there might be some others as > > well, just let us know what the pressing issues are in the audit > > userspace. > > People have been asking for ... {snip} ... Right now I was asking for input on what would need to change in userspace to eliminate the reliance on field ordering, not a full TODO list. > > > We shouldn't be doing much modifying of records. They really should be > > > pretty static unless requirements change. For new records, there is no > > > guarantee that the function created before is the right information for > > > the new event. It just depends on what it is as to what needs to be > > > collected. Then due to all the misused fields, we still need to have > > > review to make sure there's no typo. Speaking of which, I just found a > > > typo in AUDIT_FEATURE_CHANGE events. > > > > We're seeing at least one case where our inability to change the ordering > > of the audit fields is causing problems. > > What field ordering problem is preventing kernel work? It is making Richard's patch undesirable. > > > > > 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? > > > > > > That is just some kernel issues off the top of my head. Things come up > > > all the time. Most of the time things are found because someone is > > > asking questions or I am trying to make sense of the audit trail. > > > > > > As for user space tools, yes there is a TODO file in the audit tarball. > > > I don't know if the kernel maintainers have a TODO list published > > > anywhere. > > > > Eric, do you have one published somewhere? > > > > Assuming that Eric doesn't have a TODO list posted somewhere, do you have > > any objections to my posting and maintaining an audit kernel TODO list on > > the audit fedorahosted.org wiki? > > That would be nice. Great, I'll look into that once I hear back from Eric on any old kernel audit TODO lists he might have. -- paul moore security and virtualization @ redhat