12:06 p.m.
I'm building an audit.40 with this in. Steve, does it look OK to you?
--- linux-2.6.9/include/linux/audit.h~ 2005-05-17 14:43:57.000000000 +0100
+++ linux-2.6.9/include/linux/audit.h 2005-05-17 15:10:33.000000000 +0100
@@ -128,6 +128,8 @@ struct atomic_t;
#define AUDIT_ARG2 (AUDIT_ARG0+2)
#define AUDIT_ARG3 (AUDIT_ARG0+3)
+#define AUDIT_KEY 0x1000 /* Identifying key for rule */
+
#define AUDIT_NEGATE 0x80000000
--- linux-2.6.9/kernel/auditsc.c~ 2005-05-17 15:17:40.000000000 +0100
+++ linux-2.6.9/kernel/auditsc.c 2005-05-17 15:15:11.000000000 +0100
@@ -140,6 +140,7 @@ struct audit_context {
unsigned int serial; /* serial number for record */
struct timespec ctime; /* time of syscall entry */
uid_t loginuid; /* login uid (identity) */
+ uint32_t key; /* Key of rule which triggered auditing */
int major; /* syscall number */
unsigned long argv[4]; /* syscall arguments */
int return_valid; /* return code is valid */
@@ -334,9 +335,11 @@ int audit_receive_filter(int type, int p
static int audit_filter_rules(struct task_struct *tsk,
struct audit_rule *rule,
struct audit_context *ctx,
- enum audit_state *state)
+ enum audit_state *state,
+ uint32_t *key)
{
int i, j;
+ uint32_t localkey = 0;
for (i = 0; i < rule->field_count; i++) {
u32 field = rule->fields[i] & ~AUDIT_NEGATE;
@@ -429,8 +432,9 @@ static int audit_filter_rules(struct tas
if (ctx)
result = (ctx->argv[field-AUDIT_ARG0]==value);
break;
+ case AUDIT_KEY:
+ localkey = value;
}
-
if (rule->fields[i] & AUDIT_NEGATE)
result = !result;
if (!result)
@@ -441,6 +445,8 @@ static int audit_filter_rules(struct tas
case AUDIT_POSSIBLE: *state = AUDIT_BUILD_CONTEXT; break;
case AUDIT_ALWAYS: *state = AUDIT_RECORD_CONTEXT; break;
}
+ if (key)
+ *key = localkey;
return 1;
}
@@ -451,11 +457,11 @@ static int audit_filter_rules(struct tas
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
struct audit_entry *e;
- enum audit_state state;
+ enum audit_state state;
rcu_read_lock();
list_for_each_entry_rcu(e, &audit_tsklist, list) {
- if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
+ if (audit_filter_rules(tsk, &e->rule, NULL, &state, NULL)) {
rcu_read_unlock();
return state;
}
@@ -475,13 +481,13 @@ static enum audit_state audit_filter_sys
{
struct audit_entry *e;
enum audit_state state;
- int word = AUDIT_WORD(ctx->major);
- int bit = AUDIT_BIT(ctx->major);
+ int word = AUDIT_WORD(ctx->major);
+ int bit = AUDIT_BIT(ctx->major);
rcu_read_lock();
list_for_each_entry_rcu(e, list, list) {
if ((e->rule.mask[word] & bit) == bit
- && audit_filter_rules(tsk, &e->rule, ctx, &state)) {
+ && audit_filter_rules(tsk, &e->rule, ctx, &state,
&ctx->key)) {
rcu_read_unlock();
return state;
}
@@ -677,6 +683,8 @@ static void audit_log_exit(struct audit_
if (!ab)
return; /* audit_panic has been called */
audit_log_format(ab, "syscall=%d", context->major);
+ if (context->key)
+ audit_log_format(ab, " key=%x", context->key);
if (context->personality != PER_LINUX)
audit_log_format(ab, " per=%lx", context->personality);
audit_log_format(ab, " arch=%x", context->arch);
--
dwmw2
12:49 p.m.
On Tuesday 17 May 2005 13:06, David Woodhouse wrote:
I'm building an audit.40 with this in. Steve, does it look OK to
you?
General comment, should you use uint32_t or __u32 ?
I looked through the patch. I see what you are doing, but its not quite the
same as we have in file system audit. The key is a text string that that gets
printed when an audit event gets logged.
I would imagine it to be a string that is 32 bytes long (use the same define
so we have symmetry), that would live in the audit_rule structure. The "case
AUDIT_KEY" that was in the audit_filter_rules function shouldn't be there.
Does this make sense? I think we want it to act just like the one in
filesystem audit.
-Steve
3:38 p.m.
On Tue, 2005-05-17 at 13:49 -0400, Steve Grubb wrote:
General comment, should you use uint32_t or __u32 ?
uint32_t is the C99 standard type.
I looked through the patch. I see what you are doing, but its not
quite the
same as we have in file system audit. The key is a text string that that gets
printed when an audit event gets logged.
That would be hard to introduce into audit rules without breaking binary
compatibility. The way it's done, you have 4 milliard possible keys for
syscall auditing rules. Do you really think that's insufficient?
--
dwmw2
3:47 p.m.
On Tuesday 17 May 2005 16:38, David Woodhouse wrote:
That would be hard to introduce into audit rules without breaking
binary
compatibility.
Could the string go at the end? Then based on nlmsg_len, either have the old
behavior or the new.
The way it's done, you have 4 milliard possible keys for
syscall auditing rules. Do you really think that's insufficient?
Its not that its insufficient - its not the same. The patch uses a number
while filesystem auditing is a text string. The idea is to provide a like
feature regardless of what kind of audit rule.
-Steve
12:29 a.m.
On Tue, 2005-05-17 at 16:47 -0400, Steve Grubb wrote:
> The way it's done, you have 4 milliard possible keys for
> syscall auditing rules. Do you really think that's insufficient?
Its not that its insufficient - its not the same. The patch uses a number
while filesystem auditing is a text string.
How about we change the latter then?
--
dwmw2
10:28 a.m.
On Wednesday 18 May 2005 07:18, Steve Grubb wrote:
On Wednesday 18 May 2005 01:29, David Woodhouse wrote:
> How about we change the latter then?
Then it severely impacts usability. Which is more meaningful to end users:
"attempted-shadow-write" or "9" ?
Well "9" (or rather a 32b/64b hash) could map to something in a userland table
of sorts which would produce "attempted-shadow-write" before it got to the
log. There's most definitely a space savings here and we shouldn't be so
free to use kernel memory as we do user memory, but is it really worth all
the extra complexity to try to decipher the meaning of "9" in userland?
IMHO, no. *shrug*
If we do decide to go with a string may we should consider a slab cache of
keys that both the file system watches and syscalls can us?
-tim
10:32 a.m.
On Wednesday 18 May 2005 11:28, Timothy R. Chavez wrote:
but is it really worth all the extra complexity to try to decipher
the
meaning of "9" in userland?
That's easy to say if you don't have to write the code ;)
If we do decide to go with a string may we should consider a slab
cache of
keys that both the file system watches and syscalls can us?
I wonder what IPTables does? I believe the answer lies therein.
-Steve
11:01 a.m.
On Wed, 2005-05-18 at 10:28 -0500, Timothy R. Chavez wrote:
Well "9" (or rather a 32b/64b hash) could map to something
in a userland table
of sorts which would produce "attempted-shadow-write" before it got to the
log. There's most definitely a space savings here and we shouldn't be so
free to use kernel memory as we do user memory, but is it really worth all
the extra complexity to try to decipher the meaning of "9" in userland?
IMHO, no. *shrug*
Agreed. Can you change the auditfs patch to use numeric keys in the next
incarnation, please? This kind of thing really doesn't live in the
kernel.
It doesn't actually need to be mapped by auditd before it hits the log.
Storing it as-is in the log probably makes more sense.
--
dwmw2
1:08 p.m.
On Wednesday 18 May 2005 11:01, David Woodhouse wrote:
On Wed, 2005-05-18 at 10:28 -0500, Timothy R. Chavez wrote:
> Well "9" (or rather a 32b/64b hash) could map to something in a userland
> table of sorts which would produce "attempted-shadow-write" before it got
> to the log. There's most definitely a space savings here and we
> shouldn't be so free to use kernel memory as we do user memory, but is it
> really worth all the extra complexity to try to decipher the meaning of
> "9" in userland? IMHO, no. *shrug*
Agreed. Can you change the auditfs patch to use numeric keys in the next
incarnation, please? This kind of thing really doesn't live in the
kernel.
I think we should hold off for the time being and put it as a "TODO" as it
will require work in both the kernel and the userland package to convert over
and change the offsets and what not. Something I can do later this
week/weekend perhaps. Is that OK? I just want to get out an update that
fixes (once I figure it out) the problem with some watch records not
appearing and the alterations needed to list watches without sleeping between
the rcu_read locks first. This is most needed by the testers here.
-tim
2:03 p.m.
On Wed, May 18, 2005 at 05:01:50PM +0100, David Woodhouse wrote:
It doesn't actually need to be mapped by auditd before it hits
the log.
Storing it as-is in the log probably makes more sense.
Storing only numbers makes it very hard to interpret older log entries;
the mapping table can potentially change at any time, and there's no sane
way to track the history of all changes to watches to do that.
I don't object to storing only numbers in the kernel and mapping in
userspace, but the mapping back to strings would need to happen before
they end up in the log.
-Klaus
2:17 p.m.
On Wednesday 18 May 2005 15:03, Klaus Weidner wrote:
Storing only numbers makes it very hard to interpret older log
entries;
I agree
the mapping table can potentially change at any time, and there's
no sane
way to track the history of all changes to watches to do that.
I've seen places that are required to have audit trails for 6 months. When a
disk is full, its removed and a new drive inserted. (These kind of places use
removable drives.) 5 months down the road, who knows what the rules were in
effect.
-Steve
11:57 a.m.
On Wed, 2005-05-18 at 10:28 -0500, Timothy R. Chavez wrote:
If we do decide to go with a string may we should consider a slab
cache of
keys that both the file system watches and syscalls can us?
Actually I'm entirely unconvinced that the keys on syscall rules are
buying us anything at all. I wonder if we should just forget about
adding them.
With the file system watches, the key serves a real purpose -- it
identifies the object which is accessed, because the logged action may
have been performed via a hard link which we would not otherwise be able
to associate with the original object being watched.
With syscall watches, it doesn't tell us anything we don't already know;
the fields which the different rules filter on are included in the log
output anyway.
Consider a case where we have two rules -- one of which will audit all
network access by the 'exim' user, and another of which audits all
outgoing connect() attempts. You can tell which audit records are
generated by each criterion just by looking at fields which are already
in the log, even _without_ adding keys to the syscall filtering rules.
Also, there will be audit records which meet _both_ of the above
criteria, and but unless we totally revamped the rule matching code
you'd only ever see _one_ key per record. So you couldn't even trust the
keys for filtering purposes when processing the logs.
I think this is a solution in search of a problem -- unless someone can
come up with a convincing use case for syscall rule keys, I think we
should drop them.
--
dwmw2
12:56 p.m.
On Friday 20 May 2005 11:57, David Woodhouse wrote:
I think this is a solution in search of a problem -- unless someone
can
come up with a convincing use case for syscall rule keys, I think we
should drop them.
I think the original purpose of the syscall keys were to provide user space
the potential for finer grained searching? I'm always in favor of KISS where
it makes sense though. Steve what do you think?
-tim
1:21 p.m.
On Friday 20 May 2005 13:56, Timothy R. Chavez wrote:
Steve what do you think?
David's question comes from a long dialog between he and myself. He is looking
for an actual scenario where it would help. I have already thought of many
uses...but I think he wants a real life scenario where it may help.
I can see the use for correlating syscall audits that are cooperatively
working together. Right now, all fields added to a search get "anded"
together. The way you get an "or" is to create another rule. But if you
wanted to keep the 2 rules together so you can pick any related events out of
a gigabyte of data, keys would be helpful.
If you have to do inode auditing and want a label to remind yourself what the
inode maps to, keys are needed.
If you want to have file audit and syscall audits to cover a specific
requirement and be able to find them by searching, keys are needed.
If you want to have some rules that are in effect at boot and be able to
*easily* pick them out for deletion once the system is operational, keys are
needed.
If you want to look at the data that was captured by the above boot scenario
and not see all the other data that may be similar, keys are needed.
I can think of more good reasons...but I think David wants to hear from other
people than myself. Then there is another part to the question...should the
key be numeric or a text string?
For human factors, I believe it should be a string. It would be good for other
people to state an opinion. Additionally, by having only a number for syscall
auditing - if you want to make it correlate with filesystem auditing, you
will have to choose a number also so searching produces the right results.
-Steve
2 p.m.
On Friday 20 May 2005 13:21, Steve Grubb wrote:
<snip>
I can think of more good reasons...but I think David wants to hear
from
other
people than myself.
We should talk on Tuesday and list and prioritize everything, including the
"nice to haves", that are left to do for development in both the kernel and
user space. If this work is not _needed_ for the CAPP evaluation then it
should be done after the freeze, IMO. It is a very useful feature, no doubt,
but there's a greater goal here
Then there is another part to the question...should the
key be numeric or a text string?
For human factors, I believe it should be a string. It would be good for
other
people to state an opinion. Additionally, by having only a number for
syscall
auditing - if you want to make it correlate with filesystem auditing,
you
will have to choose a number also so searching produces the right results.
I personally think keys are best stored numerically as hashes (a kind of
cookie if you will) in the kernel and then, if need be, translated into
something more meaningful to human eyes in userland. However, we just don't
have the resources right now to fully develop and test this strategy. And,
if we only go half way and convert them to numeric representations, this will
do no good for the administrator and we might as well not have them at all
(which isn't acceptable).
Grouping rules together and associating records can be done other ways without
the use of a string key. For instance, we could add rules to "groups" such
that one could correlate records by this association (which would just be an
integer id).... This would require a list of lists rather then just a list,
for rules. Again, resources would be the limiting factor. Anyway, I'm a
dreamer and it's Friday.
-tim
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
--
-tim
6:45 p.m.
On Fri, 2005-05-20 at 14:21 -0400, Steve Grubb wrote:
David's question comes from a long dialog between he and myself.
He is looking
for an actual scenario where it would help. I have already thought of many
uses...but I think he wants a real life scenario where it may help.
Indeed I do. And a _specific_ example, at that.
I can see the use for correlating syscall audits that are
cooperatively
working together. Right now, all fields added to a search get "anded"
together. The way you get an "or" is to create another rule. But if you
wanted to keep the 2 rules together so you can pick any related events out of
a gigabyte of data, keys would be helpful.
I don't see how they help. Even just loading the log in 'less' and using
a regex, I can go looking for these 'related events' of which you speak
without adding complexity to the kernel.
If you have to do inode auditing and want a label to remind yourself
what the
inode maps to, keys are needed.
If the user needs a 'reminder' about what it is that she's auditing,
then her problems are more severe than we can hope to help her with.
If you want to have file audit and syscall audits to cover a specific
requirement and be able to find them by searching, keys are needed.
Again, no. You don't need keys and as I said before you may even miss
events if you use just keys for it, because a given event might be
matched by more than one rule.
If you want to have some rules that are in effect at boot and be able
to
*easily* pick them out for deletion once the system is operational, keys are
needed.
You're thinking of the trick of logging all opens during system boot?
Again, you don't need keys. You just look for all the open syscalls
between startup and some point you choose as the endpoint. It isn't
hard.
If you want to look at the data that was captured by the above boot
scenario
and not see all the other data that may be similar, keys are needed.
OK, this is a slightly more specific example of the case immediately
above, but it's still far too hand-wavy. Show a sample logfile, show me
how keys would help. I don't believe they would.
I can think of more good reasons...but I think David wants to hear
from other
people than myself.
I'd like to hear _specific_ examples of how keys would actually be
useful in _practice_. I'm not really averse to adding them -- I've
already done a first attempt at it, after all -- but I'm not convinced
it's really worth it.
--
dwmw2
7155
days inactive
7158
days old
linux-audit@lists.linux-audit.osci.io
16 comments
4 participants
participants (4)
-
David Woodhouse -
Klaus Weidner -
Steve Grubb -
Timothy R. Chavez