missing avc message field names

[Karl MacMillan]

Steve Grubb wrote:
> On Monday 29 January 2007 16:16, Karl MacMillan wrote:
>> Steve Grubb wrote:

<snip>

>> All of these messages serve exactly the same purpose - splitting them would
>> be a pain for any app that wants to process them (not to mention dealing
>> with backwards compatibility).
> 
> 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? In 
fact, I would rather that AUDIT_AVC and AUDIT_USER_AVC were not split.

>> For example, the policy generation tools that I am working on could
>> process these X messages because they are AVC messages and I only
>> require the core fields to be present (i.e., source / target types,
>> granted / denied, class, and permissions). If they were split out I
>> would a) have to process more message types and b) track which versions
>> of the audit subsystem contain which message types.
> 
> You already have them split out...or did you totally skip AUDIT_USER_AVC? So, 
> you already have to solve the problem so why not generalize the solution? The 
> parsing API should be able to help with this. If you tell it to get all the 
> different types and they don't exist, you don't get a hit except the ones 
> that do exist.
> 

You keep talking about the future - which doesn't yet exist.

So today, if you add a message type I would have to somehow determine 
which audit version I was dealing with so that I didn't pass an invalid 
record type to ausearch (because it bails). Definitely problematic.

Using the audit library would be better if it ignores invalid record 
types, but it still requires tool updates.

>>   If we ever want to have binary audit records, we need to think of these
>>
>>> audit messages as if they were database tables - each type normalized.
>>> This is, I think, where we are ultimately heading.
>> What problems do binary audit records solve?
> 
> 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? Is audit searching 
performance the most important consideration?

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.

>> 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. Not 
to mention the number of log monitoring and aggregation tools that 
assume text logs.

>> Some can be moved over to the audit library, but it is still useful to use
>> grep, tail, and other shell tools to search logs. I know that you discourage
>> that practice, but I believe that it is (and will remain) useful.
> 
> What happens when the file format changes - zlib compression for example?
> 

zcat :) Seriously, what you seem to be suggesting is that the presence 
of the audit library will make it possible to arbitrarily change the 
audit log format. I believe that the library is not sufficient - 
changing the format will continue to cause breakage and frustration. I'm 
concerned about that as someone that writes applications that are 
consumers of the audit system.

>>>> If all of these keywords in the data dictionary have to be unique, I'm
>>>> wondering if it might be useful to use a 3-tuple instead of a
>>>> (name,value) pair.
>>> I just don't see audit growing that much bigger. Of course, I may be
>>> wrong.
>> Why? I hope there will be a growing list of selinux object managers
> 
> I doubt there very many security related pieces of information that is not 
> already in the dictionary. There are a finite number of security objects and 
> their attributes.
> 

Almost by definition a userspace object manager adds new security 
critical objects. See Eamon's example.

>> 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?

Karl