Re: Refactor Netlink connector?

[Thomas Graf <tgraf@suug.ch>]

* jamal <hadi@cyberus.ca> 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.