Two netlink patches

[Stephen Smalley]

On Thu, 2004-12-16 at 11:55, Serge Hallyn wrote:
> 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.

Primarily just a policy change in this case, as the SELinux module just
uses CAP_TO_MASK() to convert the capability to an access vector. 
Likely no impact on targeted policy, as unconfined_domain is allowed the
full capability set.  Under strict, likely only need an update to
auditd.te; I think sysadm_t is already covered.

> 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...

The problem is that if that security field is dynamically allocated,
then you have the standard lifecycle management issues, so you need
other hooks to ensure that it is properly freed.  If we had a fixed size
field like the existing eff_cap field but for our own use, we could
compute an access vector based on the sender security context and store
it there for use by the receiving code.  But that obviously won't do for
stacking.

> So does extending NETLINK_CREDS seem (politically) feasible?

I doubt it, but one never knows.  Note btw that the netlink patches
shouldn't just go to lkml; they need to be routed through the proper
maintainers (likely netdev and DaveM, might want to check where the
original LSM netlink patches were submitted).

-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency