[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]