9:47 a.m.
Hey all,
I'm trying to understand better the user, watch and exclude auditctl
filter lists. I believe I have a reasonable understanding of exclude
from some examples Steve gave (see below), but I have very little idea
of how user is meant to be used, and none about watch.
Any enlightenment will be helpful.
For the exclude list,
exclude,always -F msgtype=SYSCALL
seems to be the only valid structure, where msgtype can be any value
(XXX) for the type in the audit.log? (where the 1st field in the audit
log is type=XXX)
Are there more filters that apply? (and does it have any meaning without
a filter?)
Any examples and/or explanations on "user" and "watch" would be
appriciated.
Thanks,
Mike
9:59 a.m.
Michael C Thompson wrote:
Hey all,
I'm trying to understand better the user, watch and exclude auditctl
filter lists. I believe I have a reasonable understanding of exclude
from some examples Steve gave (see below), but I have very little idea
of how user is meant to be used, and none about watch.
Any enlightenment will be helpful.
For the exclude list,
exclude,always -F msgtype=SYSCALL
seems to be the only valid structure, where msgtype can be any value
(XXX) for the type in the audit.log? (where the 1st field in the audit
log is type=XXX)
Are there more filters that apply? (and does it have any meaning without
a filter?)
Question, is it intended for:
auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
and
auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
(being active at different times) to both block the CONFIG_CHANGE
messages? I would assume that exclude,never to _not_ block messages of
that type?
Mike
10:41 a.m.
Michael C Thompson wrote:
Michael C Thompson wrote:
> Hey all,
>
> I'm trying to understand better the user, watch and exclude auditctl
> filter lists. I believe I have a reasonable understanding of exclude
> from some examples Steve gave (see below), but I have very little idea
> of how user is meant to be used, and none about watch.
>
> Any enlightenment will be helpful.
>
> For the exclude list,
>
> exclude,always -F msgtype=SYSCALL
>
> seems to be the only valid structure, where msgtype can be any value
> (XXX) for the type in the audit.log? (where the 1st field in the audit
> log is type=XXX)
>
> Are there more filters that apply? (and does it have any meaning
> without a filter?)
Question, is it intended for:
auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
and
auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
(being active at different times) to both block the CONFIG_CHANGE
messages? I would assume that exclude,never to _not_ block messages of
that type?
It also seems to be that:
auditctl -a exclude,always -F msgtype=CWD
auditctl -a exclude,always -F msgtype=PATH
and
auditctl -a exclude,always -F msgtype=CWD -F msgtype=PATH
do not work in the same way, in fact, "auditctl -a exclude,always -F
msgtype=CWD -F msgtype=PATH" does not remove either the CWD or the PATH
type from the message. Can the exclude list have only 1 msgtype per rule?
Mike
10:58 a.m.
On Thursday 18 May 2006 11:41, Michael C Thompson wrote:
It also seems to be that:
auditctl -a exclude,always -F msgtype=CWD
auditctl -a exclude,always -F msgtype=PATH
and
auditctl -a exclude,always -F msgtype=CWD -F msgtype=PATH
do not work in the same way,
This is true. The ones on the same line form an "and" expression. The ones on
different lines form an "or" expression.
-Steve
11:04 a.m.
Steve Grubb wrote:
On Thursday 18 May 2006 11:41, Michael C Thompson wrote:
> It also seems to be that:
>
> auditctl -a exclude,always -F msgtype=CWD
> auditctl -a exclude,always -F msgtype=PATH
>
> and
>
> auditctl -a exclude,always -F msgtype=CWD -F msgtype=PATH
>
> do not work in the same way,
This is true. The ones on the same line form an "and" expression. The ones on
different lines form an "or" expression.
So then it should be safe to say that having two -F msgtype=... is an
invalid construct for a rule? Since messages have only 1 type?
Mike
11:16 a.m.
On Thursday 18 May 2006 12:04, Michael C Thompson wrote:
So then it should be safe to say that having two -F msgtype=... is
an
invalid construct for a rule? Since messages have only 1 type?
Only if they are using the '=' operator. Other operators might be valid to
have multiple -F msgtype.
-Steve
2:01 p.m.
Steve Grubb wrote:
On Thursday 18 May 2006 12:04, Michael C Thompson wrote:
> So then it should be safe to say that having two -F msgtype=... is an
> invalid construct for a rule? Since messages have only 1 type?
Only if they are using the '=' operator. Other operators might be valid to
have multiple -F msgtype.
Ah yes, good point. I'll be sure to properly test the relational
operators. Other than the source code, is there any place for a user to
go and get the message types to determine their ordering?
Mike
10:55 a.m.
On Thursday 18 May 2006 10:59, Michael C Thompson wrote:
Question, is it intended for:
auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
and
auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
(being active at different times) to both block the CONFIG_CHANGE
messages? I would assume that exclude,never to _not_ block messages of
that type?
I can't see a reason to have both for the same msgtype. The first rule to
match "wins" though, so the second rule would not apply. I can see that you
may want to do something like this:
-a exclude,never -F msgtype=DAEMON_END
-a exclude,always -F 'msgtype>=DAEMON_START' -F
'msgtype<=DAEMON_ROTATE'
Together, this means exclude all messages in the DAEMON_* range except the
DAEMON_END message.
-Steve
10:58 a.m.
Steve Grubb wrote:
On Thursday 18 May 2006 10:59, Michael C Thompson wrote:
> Question, is it intended for:
> auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
> and
> auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
>
> (being active at different times) to both block the CONFIG_CHANGE
> messages? I would assume that exclude,never to _not_ block messages of
> that type?
I can't see a reason to have both for the same msgtype. The first rule to
match "wins" though, so the second rule would not apply.
True, but I didn't mean for you to interpret them as being active
together. Example:
auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
auditctl -a entry,always -S chmod -- no message logged
auditctl -D
auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
auditctl -a entry,always -S chmod -- no message logged
The 2nd no message logged doesn't make sense to me, as the exclude,never
is in fact causing the messages to not get logged.
Mike
11:13 a.m.
On Thursday 18 May 2006 11:58, Michael C Thompson wrote:
True, but I didn't mean for you to interpret them as being
active
together. Example:
auditctl -a exclude,always -F msgtype=CONFIG_CHANGE
auditctl -a entry,always -S chmod -- no message logged
auditctl -D
auditctl -a exclude,never -F msgtype=CONFIG_CHANGE
auditctl -a entry,always -S chmod -- no message logged
The 2nd no message logged doesn't make sense to me, as the
exclude,never
is in fact causing the messages to not get logged.
Looking at the kernel code...I don't think it takes the action into account.
If you have exclude list and msgtype matches, it gets excluded.
-Steve
10:50 a.m.
On Thursday 18 May 2006 10:47, Michael C Thompson wrote:
but I have very little idea f how user is meant to be used, and none
about
watch.
First, watch doesn't exist. I deleted it from the man pages yesterday.
User is used to filter userspace originating audit messages. For example, you
can use passwd and a message can be generated saying that a users password
has been changed. You can filter those events so that they do not hit the
audit logs.
auditctl -a user,always -F uid=500
For the exclude list,
exclude,always -F msgtype=SYSCALL
seems to be the only valid structure, where msgtype can be any value
(XXX) for the type in the audit.log? (where the 1st field in the audit
log is type=XXX)
Yes. But note that you can also do things like this:
-a exclude,always -F 'msgtype>=DAEMON_START' -F
'msgtype<=DAEMON_ROTATE'
to take out a whole range of message types.
Are there more filters that apply? (and does it have any meaning
without
a filter?)
No
-Steve
6792
days inactive
6792
days old
linux-audit@lists.linux-audit.osci.io
11 comments
2 participants
participants (2)
-
Michael C Thompson -
Steve Grubb