Double addition of rule yields two log messages
Hey all,
Adding a rule successfully (i.e. not malformed and that rule didn't already exist) creates a log entry:
type=CONFIG_CHANGE msg=audit(1147986115.721:28510): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0
Then, adding the same rule again will resulting in an error message being reported to the user saying that rule exists (although it uses the work "File exists", which if that could be changed to "Rule exists", might be nice). However, despite this apparent failure, we get a log entry:
type=CONFIG_CHANGE msg=audit(1147986117.389:28511): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0
Most FYI, not sure if this is a problem or not.
Mike
Quoted 7 lines · Michael C Thompson
Hey all,
Adding a rule successfully (i.e. not malformed and that rule didn't already exist) creates a log entry:
type=CONFIG_CHANGE msg=audit(1147986115.721:28510): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0
Quoted 8 lines
Then, adding the same rule again will resulting in an error message being reported to the user saying that rule exists (although it uses the work "File exists", which if that could be changed to "Rule exists", might be nice). However, despite this apparent failure, we get a log entry:
type=CONFIG_CHANGE msg=audit(1147986117.389:28511): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0Most FYI, not sure if this is a problem or not.
That's interesting. When I do this sequence with the .22 kernel and the 1.2.1 tools:
# auditctl -a entry,always -S all -F pid=1005 # auditctl -a entry,always -S all -F pid=1005 Error sending add rule request (File exists)
I get these records:
type=CONFIG_CHANGE msg=audit(1148054817.056:575): auid=500 subj=user_u:system_r:auditctl_t:s0-s0:c0.c255 add rule to list=2 res=1 type=CONFIG_CHANGE msg=audit(1148054831.417:576): auid=500 subj=user_u:system_r:auditctl_t:s0-s0:c0.c255 add rule to list=2 res=0
I believe res=1 means the operation was successful and the res=0 means it failed. Are you sure one of your records doesn't have res=1? I don't know what the "add rule to list=2" means though.
What is the exact rule you're adding? And which kernel/tools are you running?
BTW, with RHEL4U2 we only got a record on the success case. type=CONFIG_CHANGE msg=audit(1148054734.395:10530): auid=500 added an audit rule
-- ljk
Quoted 26 lines · Linda Knippers
Quoted 7 lines · Michael C Thompson
Hey all,
Adding a rule successfully (i.e. not malformed and that rule didn't already exist) creates a log entry:
type=CONFIG_CHANGE msg=audit(1147986115.721:28510): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0Quoted 8 lines
Then, adding the same rule again will resulting in an error message being reported to the user saying that rule exists (although it uses the work "File exists", which if that could be changed to "Rule exists", might be nice). However, despite this apparent failure, we get a log entry:
type=CONFIG_CHANGE msg=audit(1147986117.389:28511): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0Most FYI, not sure if this is a problem or not.
That's interesting. When I do this sequence with the .22 kernel and the 1.2.1 tools:
# auditctl -a entry,always -S all -F pid=1005 # auditctl -a entry,always -S all -F pid=1005 Error sending add rule request (File exists)I get these records:
Quoted 7 lines
type=CONFIG_CHANGE msg=audit(1148054817.056:575): auid=500 subj=user_u:system_r:auditctl_t:s0-s0:c0.c255 add rule to list=2 res=1 type=CONFIG_CHANGE msg=audit(1148054831.417:576): auid=500 subj=user_u:system_r:auditctl_t:s0-s0:c0.c255 add rule to list=2 res=0
I believe res=1 means the operation was successful and the res=0 means it failed. Are you sure one of your records doesn't have res=1?
Yes, you are infact correct. I missed that with my testing. 1 for the first entry, 0 for all subsequent doubles.
Quoted 1 line
I don't know what the "add rule to list=2" means though.
list=2 means that it was added to the entry list, now the CONFIG_CHANGE messages tell you which filter list it was added to. 2 == entry, 5 == exclude, etc.
Quoted 3 lines
What is the exact rule you're adding? And which kernel/tools are you running?
auditctl -a entry,always -S chmod -F se_sen=s0-s15:c
However, the action seems to be independent of the rule. The audit is 1.2.2 and 25 kernel.
Thanks,
Mike
Quoted 5 lines
Quoted 1 line
I don't know what the "add rule to list=2" means though.
list=2 means that it was added to the entry list, now the
CONFIG_CHANGEmessages tell you which filter list it was added to. 2 == entry, 5 == exclude, etc.
Wow, not very intuitive. The auditctl manpage talks about lists by name (entry, exclude, etc), not by number. With the 1.2.1 tools ausearch with the '-i' option doesn't translate the number into a name. Does it with the 1.2.2 tools?
Speaking of ausearch, I just noticed that it emits this message:
# /sbin/ausearch -m CONFIG_CHANGE -i Warning - freq is non-zero and incremental flushing not selected.
Not sure what that means. Maybe its time I updated my tools.
-- ljk
Quoted 2 lines · Linda Knippers
Wow, not very intuitive. The auditctl manpage talks about lists by name (entry, exclude, etc), not by number.
The man pages don't ever talk about the numbers that are behind any of this.
Quoted 2 lines
With the 1.2.1 tools ausearch with the '-i' option doesn't translate the number into a name.
Right.
Quoted 1 line
Does it with the 1.2.2 tools?
No. I have not had time to work on user space tools. The intent is to make it do that with the -i param.
Quoted 4 lines
Speaking of ausearch, I just noticed that it emits this message:
# /sbin/ausearch -m CONFIG_CHANGE -i Warning - freq is non-zero and incremental flushing not selected.
That comes from the config file parser. You've got a problem in /etc/audit/auditd.conf that should be fixed.
-Steve
Quoted 7 lines
Quoted 4 lines
Speaking of ausearch, I just noticed that it emits this message:
Quoted 3 lines
# /sbin/ausearch -m CONFIG_CHANGE -i Warning - freq is non-zero and incremental flushing not selected.That comes from the config file parser. You've got a problem in
/etc/audit/auditd.confthat should be fixed.
Its true that my auditd.conf (which I don't think I've ever modified) has freq = 20 and flush = SYNC. I assume that SYNC means that freq is ignored. The manpage says freq is only valid if flush=incremental so it seems like an unnecessary warning.
But why does ausearch care? Seems like if anything cared it would be the auditd but I can't find an error or warning from it anywhere. Seems really odd that this message comes from ausearch.
-- ljk
Quoted 1 line · Linda Knippers
But why does ausearch care?
Ausearch doesn't care about this particular setting. Its looking at the config to find the log files. The parser is what cares and it is what emitted this warning. As such, you can use ausearch to make sure your config is sane before sending sighup to reconfigure the audit daemon.
Quoted 2 lines
Seems like if anything cared it would be the auditd but I can't find an error or warning from it anywhere.
Should be in the syslog.
-Steve
Quoted 7 lines · Steve Grubb
Quoted 1 line · Linda Knippers
But why does ausearch care?
Ausearch doesn't care about this particular setting. Its looking at the config to find the log files. The parser is what cares and it is what emitted this warning.
But why is it even a warning of the freq value is only valid if flush is set to incremental?
Quoted 2 lines
As such, you can use ausearch to make sure your config is sane before sending sighup to reconfigure the audit daemon.
Sounds like an odd use of ausearch.
Quoted 4 lines
Quoted 2 lines
Seems like if anything cared it would be the auditd but I can't find an error or warning from it anywhere.
Should be in the syslog.
I see it after doing a HUP and when doing an /etc/init.d/auditd restart but not when auditd starts at boot time.
-- ljk
Quoted 6 lines · Linda Knippers
Quoted 3 lines
Ausearch doesn't care about this particular setting. Its looking at the config to find the log files. The parser is what cares and it is what emitted this warning.
But why is it even a warning of the freq value is only valid if flush is set to incremental?
So that you fix it.
Quoted 4 lines
Quoted 1 line
Should be in the syslog.
I see it after doing a HUP and when doing an
/etc/init.d/auditdrestart but not when auditd starts at boot time.
Hmm. Should be there all the time or its a bug.
-Steve
Quoted 4 lines · Michael C Thompson
Adding a rule successfully (i.e. not malformed and that rule didn't already exist) creates a log entry:
type=CONFIG_CHANGE msg=audit(1147986115.721:28510): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0
This one is a failure. res=0. (I suspect you copied the wrong one.)
Quoted 4 lines
Then, adding the same rule again will resulting in an error message being reported to the user saying that rule exists (although it uses the work "File exists", which if that could be changed to "Rule exists", might be nice).
I'll fix that.
Quoted 3 lines
However, despite this apparent failure, we get a log entry:
type=CONFIG_CHANGE msg=audit(1147986117.389:28511): auid=0 subj=root:staff_r:staff_t:s0-s15:c0.c255 add rule to list=2 res=0
This is reporting that an attempt was made to add a rule and it failed. When you add a rule and it succeeds, res=1.
-Steve