New operators for rules

[Amy Griffis]

On Wed, Sep 28, 2005 at 04:47:12PM -0400, Steve Grubb wrote:
> Dustin and I were talking about how to represent some new operators for 
> writing audit rules. I am interested in seeing >, <, and range added at a 
> minimum. The question came up as to how to fit this into the existing 
> audit_rule structure. This is what we currently have:
> 
> struct audit_rule {          /* for AUDIT_LIST, AUDIT_ADD, and AUDIT_DEL */
>       __u32           flags;  /* AUDIT_PER_{TASK,CALL}, AUDIT_PREPEND */
>       __u32           action; /* AUDIT_NEVER, AUDIT_POSSIBLE, AUDIT_ALWAYS */
>       __u32           field_count;
>       __u32           mask[AUDIT_BITMASK_SIZE];
>       __u32           fields[AUDIT_MAX_FIELDS];
>       __u32           values[AUDIT_MAX_FIELDS];
> };
> 
> 
> The fields member currently uses the msb to determine whether its =
> or !=.
> 
> #define AUDIT_NEGATE    0x80000000
> 
> I was wondering if we should go ahead and map the other operators
> into the other high bits. We are currently only using the lower 4
> bits of the u32 word so we have plenty of room. 

We need to be able to correlate the operator with a particular
field-value pair, so I think this works better than some of the other
suggested approaches.

> We have to do this in a way that is backward compatible for old
> kernels.

Where is this requirement coming from?

> Any ideas? Any preferred bit patterns?

If this had been included as part of the original design, older
kernels would have been masking out a set of bits for operator flags,
instead of just a single bit.  Since that isn't the case, I don't see
any way to make it backward compatible other than requiring user-space
tools to be aware of the kernel version and send the appropriate bits.

How about introducing this feature in a 2.0 release?

> Also, we have the issue of needing to send 2 values for a range
> operator. How should we make the kernel understand this? 

User-space tools could translate a specified range into a rule with
the following fields:

    fields              values
    ------              ------
    > AUDIT_PID         100
    < AUDIT_PID         200

> Or should we create a new message type for adding, listing, and
> deleting rules that we can expand the idea of operators for and use
> the current one for legacy compatibility?
> 
> Need some ideas from the kernel hackers....
> 
> -Steve
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>