Re: missing avc message field names
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