missing avc message field names

[Karl MacMillan]

Steve Grubb wrote:
> On Monday 29 January 2007 14:22, Eamon Walsh wrote:
>> Steve G wrote:
>>> But back to the original question, any preference for non-conflicting
>>> names? :)
>> CC'ing linux-audit.
>>
>> Some comments regarding userspace object managers and the userspace AVC:
>> in general userspace object managers will introduce new fields to the
>> AVC messages.  
> 
> Which brings up the question of does everything have to be an AVC message 
> type?

I don't know that it is necessary, but it is certainly preferable. 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).

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.

  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? I think that binary records 
introduce significant problems and would need to have significant benefits.

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.). 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.

A related problem is that rigidly enforcing the formatting forces 
updates to the audit system for any slight change to the output. 
Tracking those changes is going to be incredibly difficult for tools 
that process audit data. The audit library will help, but won't 
alleviate all problems (like the introduction of new record types). 
Regular breakage of tools is just going to discourage adoption of the 
audit system.

>> For example the AVC's generated by the X server have fields such as window=,
>> property=, and extension= for X-specific things which do not appear in the
>> kernel AVC's.  So it should be relatively easy to add new keywords to the
>> dictionary, or even have the audit system gracefully accept keywords that
>> are not in its dictionary.
> 
> The parsing API has a iterator approach and makes no assumptions about what is 
> supposed to be there or not. So, it would accept new name/value pairs without 
> any problem.
> 

Great.

>> 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. And 
what about third-party tools that are security critical?

>> The 3-tuple would consist of (namespace,name,value) with namespace coming
>> from a defined list of subsystems.  So for example there would be
>> an "SELinux" namespace encompassing all of the selinux keywords, so that
>> the "result" and "perms" keywords from the previous example would not
>> conflict with the "other" ones which would presumably be in a different
>> namespace.  Or just prefix the names with "selinux-", "syscall-", etc.
> 
> That would add a lot to disk space consumption in the current logging format. 
> The real problem that we will have if there is a common name share among 
> different records but with different meaning, is when people do a search. You 
> should be able to say "I want all audit records with the perm field" and get 
> records that are of the right type. Or another example, "I want records with 
> perm == 0". The perm field in AVC's with get run through strtol which will 
> yield 0 and then you have a match for an AVC when it should have been file 
> related. We need unambiguous names to make searching work as expected.
> 

I don't understand - Eamon is suggesting creating unique names across 
all message types by introducing a prefix, which seems like what you are 
saying is necessary. And prefixes don't have to take much room (e.g., 
sel instead of selinux-). The advantage to me is that it would be 
natural when there are conflicts (e.g., the sel prefix on selperms would 
let me know it would work for the selinux related message types).

Karl