New audit-perms patch [ Re: Audit perms check on recv ]

Darrel Goeddel dgoeddel at trustedcs.com
Thu Jan 6 16:11:43 UTC 2005


Stephen Smalley wrote:
> On Thu, 2005-01-06 at 11:40, Serge Hallyn wrote:
> 
>>Hi,
>>
>>So to be clear, are the following associations correct?
>>
>>AUDIT_GET:  no capability
>>AUDIT_LIST: no capability
>>AUDIT_USER: CAP_AUDIT_WRITE
>>AUDIT_LOGIN: CAP_AUDIT_WRITE
>>AUDIT_SET: CAP_AUDIT_CONTROL
>>AUDIT_ADD: CAP_AUDIT_CONTROL
>>AUDIT_DEL: CAP_AUDIT_CONTROL
> 
> 
> I actually got the impression (possibly wrong) from Casey's posting that
> the desired associations were CAP_AUDIT_WRITE for AUDIT_USER only, and
> CAP_AUDIT_CONTROL for all other operations, even AUDIT_GET and
> AUDIT_LIST (and AUDIT_LOGIN).  That allows applications to write records
> to the audit trail without any other access.  Of course, it means that
> login would be able to arbitrarily control auditing, since it needs
> AUDIT_LOGIN.
> 

I agree with Stephen's assessment.  AUDIT_LOGIN needs to be in a separate 
"class" from AUDIT_USER because it controls the reliability of audit records by 
setting the login id.  SELinux will be great to further restrict the actions of 
a process requiring CAP_AUDIT_CONTROL just to use AUDIT_LOGIN :)

-- 

Darrel




More information about the Linux-audit mailing list