Re: Refactor Netlink connector?

[jamal <hadi@cyberus.ca>]

On Wed, 2006-31-05 at 05:00 +0200, Thomas Graf wrote:
> * James Morris <jmorris@namei.org> 2006-05-27 13:21
> > Actually, a possible solution here is to completely remove all internal 
> > knowledge of netlink messages from SELinux and have the netfilter 
> > framework and protocols provide methods to determine message types and 
> > permissions.
> 
> Right, regarding generic netlink we can extend struct genl_ops to
> include a policy stating what permissions are required. 

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.

> Besides
> that we can extend struct nla_policy to support validating of
> attributes.

This is even further granularity that opens a whole new can of worms. 

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. 

cheers,
jamal