open() syscall and success=0 question

open() syscall and success=0 question

[Keith Kaple]

Hi, I'm fairly new to auditd, I just want to make sure I understand this correctly, the "unsuccessfull opens" manpage example was recently changed from:

auditctl -a exit,always -S open -F success!=0

to

auditctl -a exit,always -S open -F success=0

The logic of 'success' is defined as:

              success     If the exit value is >= 0 this is true/yes otherwise its false/no. When writing a rule, use a 1 for true/yes and a 0 for false/no

So, for open() returning a positive number that is the file descriptor which the process will read/write from and thus success is true or 1.  When open fails, the open() manpage says it will return -1 so that will make success false or 0.  When success is false, auditd seems to use the negated value of ERRNO to populate the exit= field, is that correct?  So a rule such as:

auditctl -a exit,always -S open -F success=0 -F exit=-13 

Would log only permission related failures, correct?


thanks,

Keith


-- 
    |       |
. | | | . | | | .
    '       ' 
    C I S C O
    GGSG VoIP   

Re: open() syscall and success=0 question

[Steve Grubb]

On Tuesday 13 May 2008 10:13:53 Keith Kaple wrote:
> When open fails, the open() manpage says it will return -1 so that will make
> success false or 0.  When success is false, auditd seems to use the negated
> value of ERRNO to populate the exit= field, is that correct?

This is actually done by the kernel, not auditd. But you are correct.

> So a rule such as:
>
> auditctl -a exit,always -S open -F success=0 -F exit=-13
>
> Would log only permission related failures, correct?

Correct. But that can be reduced to:

auditctl -a exit,always -S open -F exit=-EPERM

Syscall rules affect every single syscall made by every program. So, you want 
the rule to be efficient. In this case, checking the success field is 
redundant.

-Steve

Re: open() syscall and success=0 question

[Keith Kaple]

Thanks Steve,

Can you ellaborate a little on EPERM vs. EACCES?

Say a normal user tries to cp /etc/passwd and gets "permission denied" in the shell, will exit=-EPERM or -EACCESS? 

I assume there will be an entry for both if perhaps success=0 alone is used..


Keith




On Tue, May 13, 2008 at 10:24:41AM -0400, Steve Grubb wrote:
> On Tuesday 13 May 2008 10:13:53 Keith Kaple wrote:
> > When open fails, the open() manpage says it will return -1 so that will make
> > success false or 0.  When success is false, auditd seems to use the negated
> > value of ERRNO to populate the exit= field, is that correct?
> 
> This is actually done by the kernel, not auditd. But you are correct.
> 
> > So a rule such as:
> >
> > auditctl -a exit,always -S open -F success=0 -F exit=-13
> >
> > Would log only permission related failures, correct?
> 
> Correct. But that can be reduced to:
> 
> auditctl -a exit,always -S open -F exit=-EPERM
> 
> Syscall rules affect every single syscall made by every program. So, you want 
> the rule to be efficient. In this case, checking the success field is 
> redundant.
> 
> -Steve

-- 
    |       |
. | | | . | | | .
    '       ' 
    C I S C O
    GGSG VoIP   

Re: open() syscall and success=0 question

[Steve Grubb]

On Tuesday 13 May 2008 10:36:58 Keith Kaple wrote:
> Can you ellaborate a little on EPERM vs. EACCES?
>
> Say a normal user tries to cp /etc/passwd and gets "permission denied" in
> the shell, will exit=-EPERM or -EACCESS?

According to man 2 open, both could be returned for a permission error. strace 
tells us this, though:

open("/etc/shadow", O_RDONLY)           = -1 EACCES (Permission denied)

So, for that scenario, you want to also have a rule of:

auditctl -a exit,always -S open -F exit=-EACCES


> I assume there will be an entry for both if perhaps success=0 alone is
> used..

Yes, and there will be one for any ENOENT and a host of other failed returns. 
You will need 2 rules to cover both permission denied return codes.

-Steve