audit capability checks not audited

[Stephen Smalley]

On Thu, 2005-05-19 at 11:49 -0500, serue at us.ibm.com wrote:
> Quoting Stephen Smalley (sds at tycho.nsa.gov):
> > No, CAP_AUDIT_WRITE would be worse, as any application that can generate
> > an audit message would then be able to also set its own loginuid.
> > Finer-grained control can be achieved using the SELinux permission
> > checks on netlink_audit_socket.  CAP_AUDIT_CONTROL then becomes
> > necessary but not sufficient to modify the audit rules; you also need
> > SELinux nlmsg_write permission to netlink_audit_socket.
> 
> So we can add a security_audit_loginuid() hook.  Do we consider this a
> good reason to switch from capabilities to LSM hooks for all the audit
> permissions?

Not clear you need such a hook.  The current situation is as follows:
1) Without SELinux, CAP_AUDIT_CONTROL allows both setting of loginuid
and control over audit rules and settings.
2) With SELinux, CAP_AUDIT_CONTROL allows setting of loginuid, and
CAP_AUDIT_CONTROL + netlink_audit_socket:nlmsg_write permission allows
setting of loginuid and control over audit rules and settings.

Hence, you can allow some programs to set their loginuid
(capability:audit_control) without allowing them to modify audit rules
or settings (netlink_audit_socket:nlmsg_write).  Only reason you would
need a hook on setting the loginuid is if you want to allow some
programs to modify audit settings and rules without being able to set
their loginuid, but it isn't clear that is justified, as they can always
just disable auditing entirely at that point (except for the event of
disabling auditing itself).

-- 
Stephen Smalley
National Security Agency