[RFC] Virtual Key Fields

[Steve Grubb]

Hi,

Based on the discussion last week, I'd like to propose a technique of allowing 
the appearance of multiple key fields without having to make changes in the 
kernel. The kernel has one key field associated with each audit rule. It 
doesn't look at the field's contents for anything. A patch will be submitted 
for 2.6.26 kernel increasing the size of string the kernel will accept. The 
kernel will still allocate the minimum memory needed to hold the string.

If the admin wants to have multiple keys that can be searched on for different 
purposes, we will allow that from auditctl. A couple examples: a rule meets 
more that one requirement and he/she wants to document that separately, or 
there are interpretive plugins that would like some standard tagging of 
rules. To do this, auditctl will support multiple -k fields.

When reading the rule, auditctl will append multiple keyfields to one another 
with a non-printing separator. The value 0x01 is a good candidate since its 
not likely to be used by any admin right now. Auditctl will scan each key 
field and reject the key with a warning if the separator appears in a key 
field. The rule will be processed normally without the key, though.

When rules are listed, auditctl will split the keys out so they appear 
separately. This mimics the way the rules were written. Auditctl will also 
allow listing by key in order to aid rule analysis by the admin.

Auditctl will also allow delete all rules matching a key. This will allow the 
admin or a program to delete a set of rules related to just a particular key 
and leave all other rules intact.

auparse will split the key fields in audit records so that multiple key fields 
exist whenever it finds the separator in the key field in the event stream. 
The applications using keys should iterate over the keys to examine them all 
if its looking for something in particular.

Comments?

-Steve