On Tue, 21 Aug 2001, Stephen Smalley wrote:
> similar test. Since LSM adds a lsm_security field to the sk_buff
> struct itself, it seems that we could save our security information
> using that field rather than adding a field to netlink_skb_parms,
> and replace the hardcoded tests with hook calls in rtnetlink_rcv_msg and
> netlink_receive_user_skb to perform any desired checking based on the
> saved security information. The current hooks for allocating and
> maintaining the sk_buff lsm_security field are probably sufficient for
> tagging the sk_buff itself.
>
> Comments?
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.
- James
--
James Morris
<jmorrisat_private>
_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Aug 21 2001 - 08:32:43 PDT