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

[Stephen Smalley]

On Tue, 2005-01-04 at 16:51, Darrel Goeddel wrote:
> 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.

Interesting points, but capability bit space is _very_ limited, so I
think we have to be conservative about distinctions there. Finer-grained
distinctions could be easily accomodated via SELinux permission checks,
as you can always add a new class specifically for this purpose, but has
to be checked from the netlink_send hook.
 
-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency