New operators for rules

Dustin Kirkland dustin.kirkland at us.ibm.com
Thu Sep 29 16:28:50 UTC 2005


On 9/28/05, Steve Grubb <sgrubb at redhat.com> wrote:
> Need some ideas from the kernel hackers....

Not calling myself a kernel hacker, but I'll throw out a few thoughts.

> 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];
> };
> 
> 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 have to do this in a way that is backward
> compatible for old kernels. Any ideas? Any preferred bit patterns?
> 
> Also, we have the issue of needing to send 2 values for a range operator. How
> should we make the kernel understand this? 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?

I think we ought to be able to get decent mileage out of field_count, fields[], and values[].

For the range stuff I've been working on, how about...

field[0] = OPERATOR
field[1] = BOUNDARY
field[2] = BOUNDARY
...
value[0] = AUDIT_RANGE 
value[1] = 1300
value[2] = 1399

and

field[0] = AUDIT_OPERATOR
field[1] = AUDIT_BOUNDARY
...
value[0] = AUDIT_LESS_THAN
value[1] = 1500

and

field[0] = AUDIT_OPERATOR
field[1] = AUDIT_BOUNDARY
...
value[0] = AUDIT_GREATER_THAN
value[1] = 1066


Obviously, we create #define's for
AUDIT_[RANGE,OPERATOR,BOUNDARY,LESS_THAN,GREATER_THAN].  I suggest more
magic numbers, as opposed to bitmasks, but that's just me.  The
field/value arrays certainly have room for storing the operator in
there.  And I think it gives us considerably more room to grow the
operators list (to include perhaps AUDIT_GREATER_THAN_OR_EQUAL, etc).

Thoughts?

:-Dustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050929/62ad5873/attachment.sig>


More information about the Linux-audit mailing list