|| ||James Morris <firstname.lastname@example.org>|
|| ||RFC: updated networking hooks.|
|| ||Tue, 4 Feb 2003 00:24:39 +1100 (EST)|
An updated set of networking hooks aimed at inclusion with the 2.5
mainline kernel is now available for review at:
These changes are based on feedback from the failed submission last week,
as well as some discussion with the network maintainers over the weekend.
In a nutshell, we keep the socket.c hooks, the socket_sock_rcv_skb() hook
(important for mediating incoming packets against user process), the
af_unix hooks and the netlink hooks.
Currently, the netdevice, skb, ipv4 and tcp hooks are not going to be
accepted, nor is the security field for the sock struct (use the socket
inode field instead). Very generally, the maintainers do not want
security hooks spreading into network protocols or low level structures,
and for the security framework to be as generic as possible.
Here's a summary of changes to the network hooks since last week:
The socket.c and af_unix hooks are unchanged.
To have the socket_sock_rcv_skb() hook accepted, it had to be made more
generic (i.e. cover all important protocols) and at the suggestion of Dave
Miller, encapsulated within sk_filter(). This has also led to a nice
cleanup of some of the core networking code, removing some #ifdef junk.
Not yet done is addition of an sk_filter() call to the SCTP code, which
I'm still looking into and may supply as an additional patch (this is a
'bug' in the existing code which we may have to inherit briefly :-).
The Netlink hooks have been updated so that they cost nothing for existing
code, a requirement of inclusion. The Netlink capability calls are now
inlined in security.h, which kind of sucks, so if anyone can think of a
better way, please post some code. The coverage of these hooks has also
been extended to ip6_queue.c and xfrm_user.c.
I'd really appreciate any technical feedback on the patches. They have
been reworked a bit over the last few days, so more people looking for
bugs will be a big help.
How do these hooks fare in terms of being generally useful? I know that
some of the SELinux features will not be supported directly now (some
further patching may be required for labeled networking and the extended
sockets API). Any feedback from people working on LSM modules which use
networking will be appreciated.
Stephen: would you please let me know if the placement of the sk_filter()
hook within tcp_ipv4.c will be workable with SELinux? It changes the
placement of the socket_sock_rcv_skb() hook, but AFAICT, should still be
ok (we can't change the sk_filter() placement, btw).
linux-security-module mailing list