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

It would seem that separate CAP_AUDIT_ADMIN/CAP_AUDIT_WRITE capabilities are much more important than having a separate CAP_ADMIN_READ capability. The CAP_AUDIT_WRITE capability should only allow a process to generate a userspace audit message. I do not think we should impose a trust equivalence for programs that can generate an audit message and programs that can modify the audit subsystem configuration. I think capability checks should map like this: AUDIT_GET -> none (possibly CAP_AUDIT_ADMIN) AUDIT_SET -> CAP_AUDIT_ADMIN AUDIT_LIST -> none (possibly CAP_AUDIT_ADMIN) AUDIT_ADD -> CAP_AUDIT_ADMIN AUDIT_DEL -> CAP_AUDIT_ADMIN AUDIT_USER -> CAP_AUDIT_WRITE AUDIT_LOGIN -> CAP_AUDIT_ADMIN The case of AUDIT_LOGIN has merit for a separate CAP_AUDIT_LOGIN capability because this carries much more importance than AUDIT_USER, but we really should not have the ability to mess with the rest of the configuration. However, this action is as important to the reliability of the audit logs as the configuration of the audit subsystem. I would prioritize this capability above CAP_AUDIT_READ as well.