Weekly Edition
Return to the Kernel page
| |||||||||||||
RFC: updated networking hooks.
An updated set of networking hooks aimed at inclusion with the 2.5 mainline kernel is now available for review at: http://www.intercode.com.au/jmorris/patches/lsm/ 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). - James -- James Morris <jmorris@intercode.com.au> _______________________________________________ linux-security-module mailing list linux-security-module@wirex.com http://mail.wirex.com/mailman/listinfo/linux-security-module |
|||||||||||||