Re: Capability tests in netlink and oom_kill

sdsat_private

On Wed, 22 Aug 2001, James Morris wrote:

> This seems reasonable.  For the netlink code, would you be adding hooks
> along the lines of:
> 
> struct netlink_security_ops {
> 	void (*cap_effective) (struct sk_buff *skb);
> 	int (*cap_raised)     (struct sk_buff *skb, int cap);
> };
> 
> If so, existing behaviour could be preserved in the dummy plugs using the
> existing netlink_skb_parms field.

Actually, the dummy plug is supposed to just provide the
traditional superuser logic.  The capabilities behavior goes
into the optional capabilities plug.  So the dummy plug would
want to save the effective uid of the current process in the
skb and then test for the superuser in rtnetlink_rcv_msg and
netlink_receive_user_skb.

If we use the struct sk_buff security object, the dummy plug
can save the effective uid in it and the capability plug can save
the capability set in it when it is allocated, without requiring
any additional hooks for that purpose.  We can then replace the
cap_raised checks in rtnetlink_rcv_msg and netlink_receive_user_skb
with a call to a new hook in security_ops, like:
	int (*netlink_rcv)(struct sk_buff *skb, struct nlmsghdr *nlh);

The netlink_rcv hook function can extract the euid
or eff_cap from the skb and extract the kind of request from nlh.
If it is a privileged request, then the hook function can either perform 
a superuser test (dummy plug) or the CAP_NET_ADMIN test (capabilities
plug).  

The only disadvantage of this approach is that it assumes that
we will be successful in gaining acceptance for the sk_buff
security field.  But even if we were to instead add a void *security
field to netlink_skb_parms (in place of eff_cap) and use it,
we would have the problem of ensuring that it is maintained
properly during its lifetime (copying, deallocating, etc).
That might not be an issue for the dummy or capability plugs,
which can just store the euid or eff_cap directly in the void *
field, but it would be a problem for more complex modules.  
We would have to recreate the same functionality that we already
have for the sk_buff security field.  So I would lean toward
just using the sk_buff security field and dropping eff_cap entirely
from netlink_skb_parms.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module