Re: missing avc message field names

[Eamon Walsh <ewalsh@tycho.nsa.gov>]

Steve G wrote:
>> If you have to include code for parsing the current format, why the rush 
>> to change the kernel output?
>>     
>
> I was thinking that it should be done in near future so its not forgotten. But
> that is the only reason. It could be delayed for a while.
>
> 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.  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.

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

Another request I have is that if this scheme moves forward, that we do 
away with the audit_log_user_avc_message(3) family of functions and 
instead introduce an interface that takes an array of name/value pairs 
making up the audit message, or a single string which it could parse as 
name/value pairs.  This would be one-size-fits-all and would avoid the 
10+ parameter situation with the current functions.
-- 

Eamon Walsh <ewalsh@tycho.nsa.gov>
National Security Agency