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