Double addition of rule yields two log messages

Double addition of rule yields two log messages

[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

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

Re: Double addition of rule yields two log messages

[Linda Knippers]

Michael C Thompson wrote:
> 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.

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

Re: Double addition of rule yields two log messages

[Michael C Thompson]

Linda Knippers wrote:
> Michael C Thompson wrote:
>> 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.
> 
> 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?

Yes, you are infact correct. I missed that with my testing. 1 for the 
first entry, 0 for all subsequent doubles.

> 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.

> 
> 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

Re: Double addition of rule yields two log messages

[Linda Knippers]

>> 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.

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

Re: Double addition of rule yields two log messages

[Steve Grubb]

On Friday 19 May 2006 11:21, Michael C Thompson wrote:
> 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.)

> 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.

> 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

Re: Double addition of rule yields two log messages

[Steve Grubb]

On Friday 19 May 2006 14:06, Linda Knippers wrote:
> 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.

> With the 1.2.1 tools ausearch with the '-i' option doesn't translate the
> number into a name. 

Right.

> 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.

> 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

Re: Double addition of rule yields two log messages

[Linda Knippers]

>>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.

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

Re: Double addition of rule yields two log messages

[Steve Grubb]

On Friday 19 May 2006 14:47, Linda Knippers wrote:
> 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.

> 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

Re: Double addition of rule yields two log messages

[Linda Knippers]

Steve Grubb wrote:
> On Friday 19 May 2006 14:47, Linda Knippers wrote:
> 
>>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?

> 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.

>>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

Re: Double addition of rule yields two log messages

[Steve Grubb]

On Friday 19 May 2006 15:28, Linda Knippers wrote:
> > 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.

> > 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.

Hmm. Should be there all the time or its a bug.

-Steve