Re: missing avc message field names

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday 30 January 2007 09:49, Karl MacMillan wrote:
> > You already have that problem. AUDIT_AVC and AUDIT_USER_AVC.
>
> Yes, but adding even more message types makes the problem worse. More
> importantly, what does splitting AVC messages even more accomplish?

It allows users to tune the audit system to the kinds of messages they want to 
keep in their logs, makes analysis of the kinds of problems being reported 
easier, and allows normalization of records for binary use.

> In fact, I would rather that AUDIT_AVC and AUDIT_USER_AVC were not split.

They have to be, ironically, because of SE Linux.  :)

> > Speed and compression. People doing serious auditing have very large
> > files. Compression is extremely important. Also when dealing with large
> > files, any performance trick you can find helps immensely.
>
> gzip or bzip2 compression is not sufficient?

No, its an intermediate solution on the way to a better more difficult 
solution.

> Is audit searching performance the most important consideration?

Storage size is the more important followed by speed. As soon as you allow 
more records, they will have more to search.

> Look, I'm not against binary logs, I'm just trying to point out that I
> think that the transition will not be as easy as you seem to suggest.

No, I'm sure it will be time consuming and done in phases. The first step is 
providing the insulating layer so that apps do not have to care.

> >> The biggest issue, of course, is that it would prevent the use of any
> >> tools that process the files as text (grep, tail, awk, seaudit,
> >> setroubleshoot, etc., etc.).
> >
> > ausearch -m all --raw | grep anything you want
>
> tail -f happens to be my favorite counter example, but I am certain
> there are other useful tricks for monitoring logs that will break.

You can still use this on your system. What will be happening in the audit 
system is that there will be choices as to how the information will be 
stored. Text will still be an option. However, the portable way will be 
ausearch based.

> >> And what about third-party tools that are security critical?
> >
> > They have the TRUSTED_APP message type and they can put anything in that
> > they want. I consider that one completely freestyle.
>
> Why is it acceptable to have arbitrary name/value pairs in that message
> type and not in others?

Because by definition third party means we don't have the source to review or 
fix.

-Steve