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