[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Problem meeting FAU_SEL with trusted programs

On Monday 13 February 2006 14:33, Matt Anderson wrote:
> > You should use suid for sender user id and sauid for sender audit (login)
> > user id.
> I can do that, but your still suggesting that the data be contained
> inside a string in the audit record.  It seems like this is not what we
> want since then all of the tools will need to look at that string in
> addition to the audit fields where the information is always reported.

I still don't think this is such a big deal. So far there is only ausearch and 
aureport, both of which share parsing code.

> >>I mentioned this on #audit and Steve said he could add the ability to
> >>ausearch to look for the uid= substring in the message, but I'm not sure
> >>that meets the first requirement.
> >
> > Sure it does. The SAR part means ausearch needs to match on that field.
> I know you can make ausearch meet the FAU_SAR requirement, but I don't
> see how the kernel side can do selective audits based on a substring
> match of the message, and isn't that what FAU_SEL requires?

I was careful with what I was saying. ;)

SEL is a problem. The only high performance way of doing this that I know of 
would be to make a new structure to pass this message and the suid & sauid 
would be passed. Then we could do the matching on it. Parsing strings in the 
kernel does not sound good to me.

Setting the loginuid as Linda suggested would probably be the best answer if 
you could do that instead. You'd need to set it at the start of a job saving 
away the original and then reset it back upon completion.

> >>Does ausearch always have to look into the message string to
> >>see if there is a (a)uid there to match on?
> >
> > This is not a problem. If it doesn't it will. :)
> You don't think its a problem for your tool, but any other tools that
> would be built to do log reduction or analysis now have to deal with
> matching those strings.  That doesn't sound bad to you?

I'm going to create a library that these other tools can use. This way if we 
change to a binary record, the third party tools do not need to be 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]