Auditing Attemtps to run Audit commands.

Auditing Attemtps to run Audit commands.

[Boyce, Kevin P (AS)]

[-- Attachment #1.1: Type: text/plain, Size: 672 bytes --]

Here is a silly question ( I don't know if this has been resolved in
newer releases, I am using audit-1.7.13).

 

I have an execve rule for any attempt to execute auditd for example.  I
never get any audit records when mortal users attempt to run the command
(even though they will fail).  I only see success events when the
commands are executed as root.

 

I know all of the executables that ship with the audit packages check to
see if root is executing them, but I think there is value in knowing who
might be attempting to stop the audit daemon from a security
perspective. 

 

 

Anyone have any thoughts on this?

 

Thanks,

Kevin


[-- Attachment #1.2: Type: text/html, Size: 2676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Auditing Attemtps to run Audit commands.

[Steve Grubb]

On Tuesday, October 05, 2010 12:30:41 pm Boyce, Kevin P (AS) wrote:
> I have an execve rule for any attempt to execute auditd for example.  I
> never get any audit records when mortal users attempt to run the command
> (even though they will fail).  I only see success events when the
> commands are executed as root.

The audit utilities are protected by file permissions. So, if the user cannot 
actually access the binary, they never made an attempt. This gets cutoff in the 
filename resolution phase so the audit rule never triggers. IOW, you have to 
have a fully resolved path in the kernel for it to count as an attempt.

 
> I know all of the executables that ship with the audit packages check to
> see if root is executing them, but I think there is value in knowing who
> might be attempting to stop the audit daemon from a security
> perspective.

You can add a watch to the init script if you want.
 
-Steve