* jamal <[EMAIL PROTECTED]> 2006-05-31 08:20 > The challenge is how to inform SELinux of these permissions. > The access limit could be done by putting a SELinux hook at the time the > skb gets to the generic netlink code? > Note: There's actually two things that can be classified for access > control, the genl family as well as the ops.
We already have the flag GENL_ADMIN_PERM which when set for a struct genl_ops calls security_netlink_recv(). It's not as fine grained as it could be though. The point is that adding fine grained SELinux support is no problem and even easier than for casual netlink families. > This is even further granularity that opens a whole new can of worms. I agree, the advantage is that the genetlink code already takes care of validating the attributes, all we have to do is allow genetlink families to provide a policy. > BTW, I abused the term "attribute" in my other email to James. In that > context it means metadata for the command and in the above case it means > the "T" in TLV. Despite that they are strongly related, just that > the packet offsets are different and the checks are for different > things: SELinux policy is a simple accept/deny based on some policy > (provisioned in user space??) and nla_policy is richer with a range > check for sanity reasons as opposed to access control and then > accept/deny. Right, the important point is that for genetlink we already have a point where we peek at the attributes and adding a hook is trivial unlike for other netlink families where they'd have to be spread in the code. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
