Refactor Netlink connector?

Refactor Netlink connector?

[James Morris]

I've been looking through the kernel for new subsytems which might need 
LSM hooks, and we've got a proliferation of Netlink abstractions: generic 
Netlink, nfnetlink, connector and kobject_uevent.

I think we should look at consolidating some of these schemes, and if 
possible, into a unififed Netlink API.

As a first step, what would it take to adapt the single user of 
connector (the w1 driver) to use generic Netlink?

I suspect that some of the nfnetlink infrastructure can be used more 
generically, and that a simple API for the common case of kernel->user 
event notifications could be also be provided.

Thoughts?


- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[Patrick McHardy]

James Morris wrote:
> I've been looking through the kernel for new subsytems which might need 
> LSM hooks, and we've got a proliferation of Netlink abstractions: generic 
> Netlink, nfnetlink, connector and kobject_uevent.
> 
> I think we should look at consolidating some of these schemes, and if 
> possible, into a unififed Netlink API.
> 
> As a first step, what would it take to adapt the single user of 
> connector (the w1 driver) to use generic Netlink?
> 
> I suspect that some of the nfnetlink infrastructure can be used more 
> generically, and that a simple API for the common case of kernel->user 
> event notifications could be also be provided.
> 
> Thoughts?


No great thoughts at this point, but I agree 100%. In my
opinion netlink subsystems should be usable in a uniform way
(at least netlink specific parts like dump/query/set, ACKs,
attribute encoding and similar low-level stuff) without
implementation specific details. I guess from a SELinux point
of view having a single spot to place hooks with well defined
semantics is what counts, but it comes down to the same, there
is too much diversion among netlink users. I'll look into the
nfnetlink bits for a start, but I fear because of use of
network byteorder in lots of places it will not be able to
fully convert to generic netlink.

Re: Refactor Netlink connector?

[Evgeniy Polyakov]

On Fri, May 26, 2006 at 04:04:53PM -0400, James Morris (jmorris@namei.org) wrote:
> I've been looking through the kernel for new subsytems which might need 
> LSM hooks, and we've got a proliferation of Netlink abstractions: generic 
> Netlink, nfnetlink, connector and kobject_uevent.
> 
> I think we should look at consolidating some of these schemes, and if 
> possible, into a unififed Netlink API.
> 
> As a first step, what would it take to adapt the single user of 
> connector (the w1 driver) to use generic Netlink?

Process accounting, CIFS and OFS netfilter module use it too.
As long as quite a lot of out of the tree projects.

> I suspect that some of the nfnetlink infrastructure can be used more 
> generically, and that a simple API for the common case of kernel->user 
> event notifications could be also be provided.
>
> Thoughts?

I would like to ask, how LSM labeling supposed to work with encapsulated
netlink traffic. Will SELinux (for example) have some rules to allow w1
packets and block other for the same socket type?
And what happens when the same socket start to send packets with
different strucutre or some new protocol will be added? 
Should it consult with SELinux so it updated it's security processing code?

Or LSM supposed to work only on top of socket numbers (which could be
the best) and just control "raw" netlink messages?
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Refactor Netlink connector?

[James Morris]

On Sat, 27 May 2006, Evgeniy Polyakov wrote:

> > connector (the w1 driver) to use generic Netlink?
> 
> Process accounting, CIFS and OFS netfilter module use it too.

w1 is the only in-tree thing I can see using any of the exported connector 
symbols.  I can see that cifs has included a connector header but not how 
it's using the API.

> As long as quite a lot of out of the tree projects.

Out of tree code does not count.

> 
> > I suspect that some of the nfnetlink infrastructure can be used more 
> > generically, and that a simple API for the common case of kernel->user 
> > event notifications could be also be provided.
> >
> > Thoughts?
> 
> I would like to ask, how LSM labeling supposed to work with encapsulated
> netlink traffic. 

This is the problem I'm trying to solve in the general case.

Have a look at security/selinux/nlmsgtab.c, which includes lookups table 
for Netlink messages vs. permissions.

Currently this only covers plain netlink families, and should eventually 
work ok for encapsulated protocols as long as we know about them and can 
identify them (e.g. the genl->family field).

A further possibility is allowing netfilter protocols to register their 
own permission tables.

One of the problems is that different Netlink protocols bury their 
commands at different levels, so the SELinux code has to know how how deep 
to dig (and then do the digging) to determine exactly which command is 
being called.

e.g. TIPC only registers one genl_ops and embeds all commands inside 
TIPC_GENL_CMD, while unencapsulated netlink protocols use the nlmsg_type 
field of the actual netlink header.

It's inconsistent.

Actually, if people are going to use genl this way, perhaps we can get rid 
of dynamic genl_ops registration.  Alternatively, require that modules use 
a different genl_ops for each type of command (not possible now for TIPC 
as it's already in-tree).


> Will SELinux (for example) have some rules to allow w1 packets and block 
> other for the same socket type?

Yes, once userspace policy is updated to include support for the w1 
netlink socket, otherwise it will fall through to generic netlink perms.


> And what happens when the same socket start to send packets with
> different strucutre or some new protocol will be added? 
> Should it consult with SELinux so it updated it's security processing code?

This is where allowing protocols to register their own message perms would 
make things work automatically: add a new message type and then signify 
whether it's read, write or readpriv.


> Or LSM supposed to work only on top of socket numbers (which could be
> the best) and just control "raw" netlink messages?

It can work at that level, too, by falling back to generic netlink perms.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[James Morris]

On Sat, 27 May 2006, James Morris wrote:

> One of the problems is that different Netlink protocols bury their 
> commands at different levels, so the SELinux code has to know how how deep 
> to dig (and then do the digging) to determine exactly which command is 
> being called.

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.

One of the issues still to resolve for SELinux and generic netlink is that 
we don't know what the netlink protocol for the socket really is until 
messages are sent over it, so some socket-level perms for NETLINK_GENERIC 
will have to be handed out to all potential users (although actual 
transfer of data can be mediated at a finer granularity).


- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[Evgeniy Polyakov]

On Sat, May 27, 2006 at 01:21:05PM -0400, James Morris (jmorris@namei.org) wrote:
> On Sat, 27 May 2006, James Morris wrote:
> 
> > One of the problems is that different Netlink protocols bury their 
> > commands at different levels, so the SELinux code has to know how how deep 
> > to dig (and then do the digging) to determine exactly which command is 
> > being called.
> 
> 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.
> 
> One of the issues still to resolve for SELinux and generic netlink is that 
> we don't know what the netlink protocol for the socket really is until 
> messages are sent over it, so some socket-level perms for NETLINK_GENERIC 
> will have to be handed out to all potential users (although actual 
> transfer of data can be mediated at a finer granularity).

Does SELinux have security handlers for each type of possible ioctls
over the world? Each ioctl number is like each netlink type of message,
but instead there is only one check per ioctl syscall as long as lsm
hook for socket's send/recv syscall. 
It could be interesting and quite challenging to force all ioctl users
to have the same structure under each ioctl number so SELinux could
control for example disk geometry or time and date requests...
And, btw, what is the purpose of controlling netlink messages?
Does it prevent malicious userspace application to receive events from
malicious kernel module?
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Refactor Netlink connector?

[David Miller]

From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Date: Sun, 28 May 2006 19:33:21 +0400

> Does SELinux have security handlers for each type of possible ioctls
> over the world? Each ioctl number is like each netlink type of message,
> but instead there is only one check per ioctl syscall as long as lsm
> hook for socket's send/recv syscall. 

Yes, the problem is similar to what the compat layer needs to face.
But I think James will tell us that SELinux has a way that it handles
the mess that is ioctl(). :-)

More to the point I think that none of this will be handled
transparently unless the onus is put on new netlink module users.
Ie. make the register of a netlink subsystem user (either direct
netlink or via generic netlink) fail if the operations don't
provide the SELinux handlers.

Otherwise, the SELinux folks will continually be playing catchup
writing the handlers.  That doesn't scale.

Re: Refactor Netlink connector?

[jamal]

On Sun, 2006-28-05 at 23:36 -0700, David Miller wrote:
[..]
> 
> More to the point I think that none of this will be handled
> transparently unless the onus is put on new netlink module users.
> Ie. make the register of a netlink subsystem user (either direct
> netlink or via generic netlink) fail if the operations don't
> provide the SELinux handlers.
>
> Otherwise, the SELinux folks will continually be playing catchup
> writing the handlers.  That doesn't scale.

The scaling problem may be more related to SELinux trying to have
ultimate knowledge of all the subsystems classification. It breaks when
it is something that is not simple as a type (as in this case).

If SELinux should provide ways to add "filters" more dynamically at its
hooks - instead of having people go and look for that table and update
it then it would simplify things and we may be able to easily have
netlink users to register such filters at startup; infact we may be able
to hide this from the users in genetlink. 
One could argue that if SELinux is capable of adding such filters at its
hooks, then the problem could be moved to user space policy perhaps? 

cheers,
jamal

Re: Refactor Netlink connector?

[James Morris]

On Mon, 29 May 2006, jamal wrote:

> If SELinux should provide ways to add "filters" more dynamically at its
> hooks - instead of having people go and look for that table and update
> it then it would simplify things and we may be able to easily have
> netlink users to register such filters at startup; infact we may be able
> to hide this from the users in genetlink. 
> One could argue that if SELinux is capable of adding such filters at its
> hooks, then the problem could be moved to user space policy perhaps? 

This is similar to what the secmark stuff does, allows selection and 
labeling to be done via iptables, so the SELinux kernel stuff then just 
needs to look at the labels.

In this case, I'm not sure it's worthwhile adding a filtering layer to 
Netlink, probably simpler just to have the different Netlink protocols 
define whether each command is one of 'read', 'write' and 'readpriv' (the 
latter is pretty rare), so nothing has to be scanned on the fly at all.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[jamal]

On Tue, 2006-30-05 at 10:22 -0400, James Morris wrote:
> On Mon, 29 May 2006, jamal wrote:
> 
> > If SELinux should provide ways to add "filters" more dynamically at its
> > hooks - instead of having people go and look for that table and update
[..]
> 
> This is similar to what the secmark stuff does, allows selection and 
> labeling to be done via iptables, so the SELinux kernel stuff then just 
> needs to look at the labels.

hopefully SELinux is taught about such labels semantics at runtime.

> In this case, I'm not sure it's worthwhile adding a filtering layer to 
> Netlink, probably simpler just to have the different Netlink protocols 
> define whether each command is one of 'read', 'write' and 'readpriv' (the 
> latter is pretty rare), so nothing has to be scanned on the fly at all.
> 

We could start by just adding a check for NETLINK_GENERIC in your table
(as is done generally for other netlink families/protocols with SELinux)
and then do the fine-grained stuff. I think that checking for attributes
instead of types will need to be generic for all of netlink.
Thomas?

cheers,
jamal

Re: Refactor Netlink connector?

[Thomas Graf]

* jamal <hadi@cyberus.ca> 2006-05-31 08:00
> We could start by just adding a check for NETLINK_GENERIC in your table
> (as is done generally for other netlink families/protocols with SELinux)
> and then do the fine-grained stuff. I think that checking for attributes
> instead of types will need to be generic for all of netlink.

I'm not sure I perfectly understand the check we're heading for, is the
goal to check whether unknown/forbidden attribute types are being
provided by userspace, i.e. compare the provided attribute types against
a list of allowed attribute types maybe in combination with a list of
required permissions for certain attributes?

Re: Refactor Netlink connector?

[James Morris]

On Sun, 28 May 2006, Evgeniy Polyakov wrote:

> Does SELinux have security handlers for each type of possible ioctls
> over the world? Each ioctl number is like each netlink type of message,
> but instead there is only one check per ioctl syscall as long as lsm
> hook for socket's send/recv syscall. 
> It could be interesting and quite challenging to force all ioctl users
> to have the same structure under each ioctl number so SELinux could
> control for example disk geometry or time and date requests...

It has a generic control for ioctls, but also does some special handling 
for some ioctls.

> And, btw, what is the purpose of controlling netlink messages?
> Does it prevent malicious userspace application to receive events from
> malicious kernel module?

It provides control over which types of applications can send and receive 
different types of Netlink messages.  e.g. you can specify that Apache can 
read the routing table but not write to it.



- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[Evgeniy Polyakov]

On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris (jmorris@namei.org) wrote:
> > And, btw, what is the purpose of controlling netlink messages?
> > Does it prevent malicious userspace application to receive events from
> > malicious kernel module?
> 
> It provides control over which types of applications can send and receive 
> different types of Netlink messages.  e.g. you can specify that Apache can 
> read the routing table but not write to it.
 
Apache still can setup routes using ioctl or execve("ip route add/route
add");

Anyway you can easily add lsm hook into both sending/receiving pathes in
connector code, it fully controls the traffic before it reached socket
queue or user's callback.
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Refactor Netlink connector?

[James Morris]

On Tue, 30 May 2006, Evgeniy Polyakov wrote:

> On Tue, May 30, 2006 at 10:18:32AM -0400, James Morris (jmorris@namei.org) wrote:
> > > And, btw, what is the purpose of controlling netlink messages?
> > > Does it prevent malicious userspace application to receive events from
> > > malicious kernel module?
> > 
> > It provides control over which types of applications can send and receive 
> > different types of Netlink messages.  e.g. you can specify that Apache can 
> > read the routing table but not write to it.
>  
> Apache still can setup routes using ioctl or execve("ip route add/route
> add");

Depends on the policy.  You can specify which types of files/sockets 
apache can perform ioctl on, and whether it can execve 'ip', and if so, 
which security context that runs in, and then whether that security 
context can add routes.

Security in SELinux is not based on the name of the application, it's 
based on the security label bound to the binary being executed.

> Anyway you can easily add lsm hook into both sending/receiving pathes in
> connector code, it fully controls the traffic before it reached socket
> queue or user's callback.

There are already LSM hooks which allow this, it's a matter of not wanting 
to have to parse arbitrarily implemented Netlink protocols to determine 
what the messages are.


- James
-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[Evgeniy Polyakov]

On Tue, May 30, 2006 at 02:58:11PM -0400, James Morris (jmorris@namei.org) wrote:
> > Apache still can setup routes using ioctl or execve("ip route add/route
> > add");
> 
> Depends on the policy.  You can specify which types of files/sockets 
> apache can perform ioctl on, and whether it can execve 'ip', and if so, 
> which security context that runs in, and then whether that security 
> context can add routes.

With applications like phpmmyadmin apache must be allowed to perform such
operations no matter hacked it is or not...

> Security in SELinux is not based on the name of the application, it's 
> based on the security label bound to the binary being executed.

I know how selinux works.
I see your point, selinux is supposed to control each datflow even if it
sometimes is not that good idea.

> > Anyway you can easily add lsm hook into both sending/receiving pathes in
> > connector code, it fully controls the traffic before it reached socket
> > queue or user's callback.
> 
> There are already LSM hooks which allow this, it's a matter of not wanting 
> to have to parse arbitrarily implemented Netlink protocols to determine 
> what the messages are.

I mean you can control messages based on cn_mcg->id structure, since
cn_msg is a header for all connector messages.
 
> - James
> -- 
> James Morris
> <jmorris@namei.org>

-- 
	Evgeniy Polyakov

Re: Refactor Netlink connector?

[Thomas Graf]

* 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. Besides
that we can extend struct nla_policy to support validating of
attributes.

Re: Refactor Netlink connector?

[jamal]

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

Re: Refactor Netlink connector?

[Thomas Graf]

* 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.

Re: Refactor Netlink connector?

[jamal]

On Wed, 2006-31-05 at 15:06 +0200, Thomas Graf wrote:
> * 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. 

To also answer your other email:
Look at  security/selinux/nlmsgtab.c for example for NETLINK_ROUTE
and compare with NETLINK_GENERIC to see the hole. I was suggesting if
we started by just adding checks for NETLINK_GENERIC first in those
tables (currently lacking), that would be a good start.

> The point is that adding
> fine grained SELinux support is no problem and even easier than
> for casual netlink families.
> 

indeed. And it would be the first to check for a lot more fine graining
than exists today.
If you look at security/selinux/nlmsgtab.c (after we add checks for
NETLINK_GENERIC) then it seems hard to just "hardcode" all commands and
families/ids in there because the idea is people could even be doing
this via modules. Not sure if that made sense.

>  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.

nod.

cheers,
jamal

Re: Refactor Netlink connector?

[James Morris]

On Wed, 31 May 2006, jamal wrote:

> To also answer your other email:
> Look at  security/selinux/nlmsgtab.c for example for NETLINK_ROUTE
> and compare with NETLINK_GENERIC to see the hole. I was suggesting if
> we started by just adding checks for NETLINK_GENERIC first in those
> tables (currently lacking), that would be a good start.

They're currently mediated as a generic netlink socket type at a higher 
level: they're not unmediated, just not fine grained enough to know what 
kind of message is being sent.


-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[Thomas Graf]

* James Morris <jmorris@namei.org> 2006-05-31 11:42
> On Wed, 31 May 2006, jamal wrote:
> 
> > To also answer your other email:
> > Look at  security/selinux/nlmsgtab.c for example for NETLINK_ROUTE
> > and compare with NETLINK_GENERIC to see the hole. I was suggesting if
> > we started by just adding checks for NETLINK_GENERIC first in those
> > tables (currently lacking), that would be a good start.
> 
> They're currently mediated as a generic netlink socket type at a higher 
> level: they're not unmediated, just not fine grained enough to know what 
> kind of message is being sent.

It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
for NETLINK_ROUTE into the definitions of the generic netlink
operations, could look like this:

struct genl_ops some_op = {
	[...]
	.perm	 = NETLINK_GENERIC_SOCKET__NLMSG_READ,
};

int genl_lookup_perm(u16 nlmsg_type, u8 cmd)
{
	struct genl_family *family;
	struct genl_ops *ops;

	family = genl_family_find_byid(nlmsg_type);
	ops = genl_get_cmd(cmd, family);

	return ops->perm;
}

int genl_peek_cmd(struct nlmsghdr *nlh)
{
	struct genlmsghdr *hdr = nlmsg_data(nlh);

	if (nlh->nlmsglen < nlmsg_msg_sizeo(GENL_HDRLEN))
		return -EINVAL;

	return hdr->cmd;
}


selinux_lookup() must take struct nlmsghdr as an additional argument

	case SECCLASS_NETLINK_GENERIC_SOCKET:
		cmd = genl_peek_cmd(nlh)
		*perm = genl_lookup_perm(nlmsg_type, cmd);
		break;

Re: Refactor Netlink connector?

[James Morris]

On Thu, 1 Jun 2006, Thomas Graf wrote:

> It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
> for NETLINK_ROUTE into the definitions of the generic netlink
> operations, could look like this:
> 
> struct genl_ops some_op = {
> 	[...]
> 	.perm	 = NETLINK_GENERIC_SOCKET__NLMSG_READ,
> };

We wouldn't need the socket class outside of SELinux, just the perm, so 
something like:

NL_PERM_READ

> int genl_peek_cmd(struct nlmsghdr *nlh)
> {
> 	struct genlmsghdr *hdr = nlmsg_data(nlh);
> 
> 	if (nlh->nlmsglen < nlmsg_msg_sizeo(GENL_HDRLEN))
> 		return -EINVAL;
> 
> 	return hdr->cmd;
> }

Unless I'm mistaken, people are already multiplexing commands inside genl 
commands (and if so, why even bother with registerable ops?).


I'll look at it in more detail soon.


-- 
James Morris
<jmorris@namei.org>

Re: Refactor Netlink connector?

[jamal]

So whats the resolution on this? I actually have some cycles this coming
weekend that i was hopping to spend updating the doc instead.

cheers,
jamal

On Thu, 2006-01-06 at 10:24 -0400, James Morris wrote:
> On Thu, 1 Jun 2006, Thomas Graf wrote:
> 
> > It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
> > for NETLINK_ROUTE into the definitions of the generic netlink
> > operations, could look like this:
> > 
> > struct genl_ops some_op = {
> > 	[...]
> > 	.perm	 = NETLINK_GENERIC_SOCKET__NLMSG_READ,
> > };
> 
> We wouldn't need the socket class outside of SELinux, just the perm, so 
> something like:
> 
> NL_PERM_READ
> 
> > int genl_peek_cmd(struct nlmsghdr *nlh)
> > {
> > 	struct genlmsghdr *hdr = nlmsg_data(nlh);
> > 
> > 	if (nlh->nlmsglen < nlmsg_msg_sizeo(GENL_HDRLEN))
> > 		return -EINVAL;
> > 
> > 	return hdr->cmd;
> > }
> 
> Unless I'm mistaken, people are already multiplexing commands inside genl 
> commands (and if so, why even bother with registerable ops?).
> 
> 
> I'll look at it in more detail soon.
> 
> 

Re: Refactor Netlink connector?

[James Morris]

On Wed, 14 Jun 2006, jamal wrote:

> 
> So whats the resolution on this? I actually have some cycles this coming
> weekend that i was hopping to spend updating the doc instead.

Haven't had a chance to look at it since.

-- 
James Morris
<jmorris@namei.org>