Reactive rules (from juro.fit@gmail.com)

Reactive rules (from juro.fit@gmail.com)

[Miloslav Trmac]

[-- Attachment #1.1: Type: text/plain, Size: 2025 bytes --]

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. 

---------- 


[-- Attachment #1.2: Type: text/html, Size: 2337 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Reactive rules (from juro.fit@gmail.com)

[Steve Grubb]

On Wednesday 19 August 2009 03:12:05 am Miloslav Trmac wrote:
> 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.

I suppose you could hook into the exclude filter and check events there.

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

You could also do matching based on a new field rather than change the syntax 
of the rules. It could work like key field except its a number. The high bit 
could determine if its add/delete.


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

The less changed in the kABI the better. It needs to stay backward/forward 
compatible in different combinations of kernel and user space.

-Steve