Along with netdevices (netdev_ops), there are a few other low-level networking objects which are candidates for LSM hooks. For example, selinux implements coarse-grained controls for routing, ARP and RARP tables (all IPv4 specific). As a simple solution, accesses to all of these objects can be caught via the sys_ioctl() hook, and we won't need to add any more hooks for them. However, things become more complicated if the kernel is configured with rtnetlink enabled. This is a separate mechanism for managing the same set of objects (see rtnetlink(7)), as well as a few others which may also need access/audit hooks for some implementations. There is a point in the code where we could insert a single hook to catch all rtnetlink accessess to these objects, however, the rtnetlink code is very generic, and we could end up with an odd-looking LSM API. For example, to catch all accesses to a netdevice, an LSM module would need to provide functions for both netdev_ops->ioctl() and, say rtnetlink_ops->recv(), both with quite different arguments and granularities, and significant processing overhead in for the latter. I've been looking at a few possible solutions: 1. Don't worry about rtnetlink for phase 1, we're just building a prototype (it will be one of a few kernel options that will need to be disabled). 2. Implement the simple hooks per the example above and have a strange API. I don't think this idea is worth pursuing. 3. Change the abstraction and present a consistent API to the LSM module developer. This would mean going down below the ioctl() and rtnetlink levels and putting in fine-grained hooks based on the actual operation being interposed. So, rather than the example above, accesses via both the ioctl() and rtnetlink paths would call the same hooks in netdev_ops, say: netdev_ops->getmtu(); netdev_ops->setmtu(); netdev_ops->setaddr(); netdev_ops->getaddr(); (etc). I think this is the best solution, conceptually, although it will mean more hooks in the kernel. More investigation is needed to determine if it will work well, but I'd like to get some feedback from the list first. Any comments, or suggestions for other solutions would be most appreciated. - James -- James Morris <jmorrisat_private> _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Thu Aug 02 2001 - 12:16:52 PDT