Re: New operators for rules
On 9/28/05, Steve Grubb <sgrubb(a)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
Attachments:
- signature.asc (application/pgp-signature — 189 bytes)