Re: Two netlink patches
Well, the attached (compiled, but untested) patch does move the code
into audit.c the way Chris wanted, adding only one line to
dummy_netlink_send and cap_netlink_send. But it also would require some
changes to SELinux, I assume, to at least handle the new CAP_AUDIT bit.
By extending the NETLINK_CREDS(skb), I assume you mean adding a void
*security? Perhaps that's actually the cleaner way to go, if only
because it lets the actual receiving subsystem perform the check, rather
than netlink. That's the part I don't like about my patch. While in
this case it's just audit, that may change, and soon
security_netlink_send becomes a central location for checks for all
sorts of protocols...
So does extending NETLINK_CREDS seem (politically) feasible? Or does
the attached patch seem acceptable?
-serge
On Thu, 2004-12-16 at 10:29 -0500, Stephen Smalley wrote:
On Thu, 2004-12-16 at 11:25, Serge Hallyn wrote:
> Hi,
>
> I believe a single CAP_AUDIT_CONTROL bit should suffice for defining an
> MRMLOSPP-compliant audit role. I will send out a new patch asap which
> also nixes cap_netlink_audit_send and just leaves the code in dummy.
>
> Does this seem sufficient? Or do you (Chris) object to having this test
> in the netlink send codepath? As far as I can see, the only legitimate
> alternative would be to in fact move audit control to a different
> (pseudo-fs?) interface.
For just a capability check, you can check on the receive path based on
NETLINK_CREDS(skb)->eff_cap, as long as the security modules set all of
the capability bits in that field properly (commoncap already does so,
and SELinux and dummy could easily be changed to do so). In contrast,
we don't have that option for SELinux permissions, because we don't have
any way to convey either the sender security context or the computed
permissions in NETLINK_CREDS without extending that structure.
--
Serge Hallyn <serue(a)us.ibm.com>
Attachments:
- audit-fix-permchecks.diff (text/x-patch — 6.7 KB)