[RFC] Virtual Key Fields

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