I planned to create a plugin which would extend the current audit
capabilities adding a new type of rule - a reactive rule. This
type of rule is different in the way that it watches for an event
like an ordinary rule, however, when the event happens, it reacts
to that adding or deleting other rules. For example, there is
a reactive rule that watches for a certain user to login and as
the reaction to the event, it adds the new rule that watches for
file changes in the user's home dir.

The problem with the plugin is that it would have to analyze
every single message from the dispatcher, parse it and look for
an appropriate rule in a rule set that caused this message was
generated. The process of parsing every message isn't the right
thing to do because of overheat.

I suggest that a change should be done in the kernel. The events
are filtered in it so that there is no need parsing the messages
sent to the auditd and this solution wouldn't cause any increase
in the load of the system caused by auditing.

First of all, the syntax of the rules should be changed a bit to
include reactive rules. It could look like this:

rule1
rule2 {
   rule2_1
   rule2_2
}
rule3

When an event that rule2 watches for occurs, rule2_1 and rule2_2
will be added/removed to/from the rule set.

The change in the syntax means a change in auditctl.c. Also,
struct audit_rule_data needs to be altered to include some flag
that makes it possible to recognize between the types of rules
when passed to the kernel.

Furthermore, ordinary rules are added/removed to/from the rule
set as soon as the kernel receives a request from the user space.
From the example above, rules rule2_1 and rule2_2 can't be
added/removed to/from the rule set immediately because an event
that matches rule2 must occur at first. Although, they must be
saved in the kernel, for example, they could be kept in a list
of type struct list_head and the associated reactive rule would
keep a reference to this list.

----------