3:47 p.m.
Hello,
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 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?
Need some ideas from the kernel hackers....
-Steve
2:40 p.m.
On Wednesday 28 September 2005 15:47, Steve Grubb wrote:
Hello,
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 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?
Need some ideas from the kernel hackers....
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
You could add a zero-sized array at the bottom like, so:
struct op_t {
char op[2];
}
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];
struct op_t operator[0];
};
Then you iterate over field count to get each operator corresponding to the value.
Haha, I wrote this number... which is nice and ugly to convey the point... but, I do think
using
the high bits is probably a good approach to stick with...
-tim
#include <stdio.h>
#include <errno.h>
#define OP_LESS ((char[2]){'<', ' '})
#define OP_LESS_EQUAL ((char[2]){'<', '='})
struct op_t {
char op[2];
};
struct compare_t {
struct op_t ops[0];
};
int main(void)
{
int i;
struct op_t op_one;
struct op_t op_two;
struct op_t this_op;
struct compare_t *c;
op_one.op[0] = '<';
op_one.op[1] = ' ';
op_two.op[0] = '<';
op_two.op[1] = '=';
c = (struct compare_t *)malloc(sizeof(*c) + (2 * sizeof(struct op_t)));
if (!c) {
perror("malloc");
exit(errno);
}
c->ops[0] = op_one;
c->ops[1] = op_two;
for (i = 0; i < 2; i++) {
this_op = c->ops[i];
if (!memcmp(this_op.op, OP_LESS, 2))
printf("Less than\n");
if (!memcmp(this_op.op, OP_LESS_EQUAL, 2))
printf("Less than or equal\n");
}
free(c);
return 0;
}
7:39 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
2:47 p.m.
On Thursday 06 October 2005 08:39, Amy Griffis wrote:
> We have to do this in a way that is backward compatible for old
> kernels.
Where is this requirement coming from?
If you are using fedora 4 and upgrade your kernel, you expect everything to
keep working.
> 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.
Sure, its simple to do. If the next set of bits have something in it, use it,
otherwise use the old one. This means 000 is backwards compatible. 101 could
be mapped to range.
How about introducing this feature in a 2.0 release?
2.0 of what? We are presumably working on kernel 2.6.1x.
-Steve
3:23 p.m.
On Thursday 06 October 2005 14:47, Steve Grubb wrote:
On Thursday 06 October 2005 08:39, Amy Griffis wrote:
> > We have to do this in a way that is backward compatible for old
> > kernels.
>
> Where is this requirement coming from?
If you are using fedora 4 and upgrade your kernel, you expect everything to
keep working.
> > 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.
Sure, its simple to do. If the next set of bits have something in it, use it,
otherwise use the old one. This means 000 is backwards compatible. 101 could
be mapped to range.
> How about introducing this feature in a 2.0 release?
2.0 of what? We are presumably working on kernel 2.6.1x.
-Steve
audit-2.0?
-tim
7:55 a.m.
Steve Grubb wrote: [Thu Oct 06 2005, 03:47:23PM EDT]
On Thursday 06 October 2005 08:39, Amy Griffis wrote:
> > We have to do this in a way that is backward compatible for old
> > kernels.
>
> Where is this requirement coming from?
If you are using fedora 4 and upgrade your kernel, you expect
everything to keep working.
It will. The problem is that specifying new rules with comparison
operators will not work on older kernels, and will produce unintended
results. So upgrading the audit tools to a version providing this
feature would require a kernel upgrade as well.
> > 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.
Sure, its simple to do. If the next set of bits have something in
it, use it, otherwise use the old one. This means 000 is backwards
compatible. 101 could be mapped to range.
Right, in new kernels. In older kernels, 101 doesn't mean anything.
> How about introducing this feature in a 2.0 release?
2.0 of what? We are presumably working on kernel 2.6.1x.
I was referring to audit tools 2.0. If you feel uncomfortable
requiring a kernel upgrade with minor version update, save the feature
for the next major version of the audit tools.
Amy
8:14 a.m.
On Friday 07 October 2005 08:55, Amy Griffis wrote:
Right, in new kernels. In older kernels, 101 doesn't mean
anything.
Right it will fail. However, if we had a capabilities command like I've been
asking for, userspace could query the kernel and see what the audit system's
capabilities are and make decisions. If we added the capabilities command
now, then I could identify old kernels because the capabilities command is
unsupported. I could then tell the user that the operator is unsupported.
> > How about introducing this feature in a 2.0 release?
>
> 2.0 of what? We are presumably working on kernel 2.6.1x.
I was referring to audit tools 2.0.
That's what we are working on. ;)
-Steve
9:27 a.m.
On Fri, Oct 07, 2005 at 09:14:14AM -0400, Steve Grubb wrote:
> I was referring to audit tools 2.0.
That's what we are working on. ;)
Based on this list, it looked like all future development was slated
for the 1.x version.
https://www.redhat.com/archives/linux-audit/2005-August/msg00072.html
If you've changed the roadmap, would you mind posting an update?
Thanks,
Amy
9:35 a.m.
On Friday 07 October 2005 10:27, Amy Griffis wrote:
Based on this list, it looked like all future development was slated
for the 1.x version.
Yes. That is the run up to 2.0. There will be so many releases that I can't
start numbering at 1.9.
If you've changed the roadmap, would you mind posting an update?
The road map hasn't changed.
-Steve
7061
days inactive
7070
days old
linux-audit@lists.linux-audit.osci.io
9 comments
3 participants
participants (3)
-
Amy Griffis -
Steve Grubb -
Timothy R. Chavez