auditctl usage for filter lists: "user" , "watch" and "exclude"
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
Quoted 6 lines · Michael C Thompson
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.
Quoted 7 lines
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
Quoted 13 lines · Michael C Thompson
Quoted 12 lines · Michael C Thompson
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)
Quoted 8 lines
Quoted 1 line
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_CHANGEmessages? 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
Quoted 10 lines · Michael C Thompson
It also seems to be that:
auditctl -a exclude,always -F msgtype=CWD
auditctl -a exclude,always -F msgtype=PATHand
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
Quoted 6 lines · Steve Grubb
Quoted 5 lines · Michael C Thompson
It also seems to be that:
auditctl -a exclude,always -F msgtype=CWD
auditctl -a exclude,always -F msgtype=PATH
Quoted 7 lines
Quoted 5 lines
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
Quoted 2 lines · Michael C Thompson
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
Quoted 5 lines · Steve Grubb
Quoted 2 lines · Michael C Thompson
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
Quoted 2 lines · Michael C Thompson
Other than the source code, is there any place for a user to go and get the message types to determine their ordering?
Not at this point. I want to update the docs at some point...but until then...source code.
-Steve
Quoted 8 lines · Michael C Thompson
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_CHANGEmessages? 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
Quoted 11 lines · Steve Grubb
Quoted 8 lines · Michael C Thompson
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_CHANGEmessages? 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
Quoted 6 lines · Michael C Thompson
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
Quoted 7 lines
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
Quoted 2 lines · Michael C Thompson
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
Quoted 7 lines
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.
Quoted 2 lines
Are there more filters that apply? (and does it have any meaning without a filter?)
No
-Steve