[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 ]

Serge E. Hallyn wrote:
The attached patch addresses Stephen's comments about re-using
dummy_capget code and properly checking capabilities in

To review, it

   1.  adds two new capabilities, CAP_AUDIT_READ and CAP_AUDIT_WRITE
   2.  changes dummy.c and selinux/hooks.c to set the
netlink_audit message's eff_cap field to accurately reflect
the capabilities of the sender,
   3.  checks for the capabilities required for the requested audit
action in the eff_cap field at audit_msg_recv
   4.  adds checks to ensure that the message lengths are at least
long enough to hold the structures they claim to hold.


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_LIST -> none (possibly 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.



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