Re: New audit-perms patch [ Re: Audit perms check on recv ]
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