New audit-perms patch [ Re: Audit perms check on recv ]
Stephen Smalley
sds at epoch.ncsc.mil
Tue Jan 4 21:58:50 UTC 2005
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
More information about the Linux-audit
mailing list