[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New operators for rules



On 9/28/05, Steve Grubb <sgrubb 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

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]