missing avc message field names

[Steve Grubb]

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

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

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

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

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

The one function you speak of was designed specifically for a python program. 
But otherwise the API is designed to enforce common format across a variety 
of applications. I do not see this family of functions growing much bigger at 
all. I think we have auditing in nearly all the trusted apps right now. But I 
also want to point out that if we ever want to have binary audit records, we 
would have to have a standard API that takes certain parameters and converts 
them to their binary equivalents. To allow a free style API would mean that 
it cannot be converted to binary format.

-Steve