Low-level network hooks and rtnetlink

From: James Morris (jmorrisat_private)
Date: Thu Aug 02 2001 - 12:14:08 PDT

  • Next message: Chris Wright: "Re: Low-level network hooks and rtnetlink"

    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
    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,
    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
    - James
    James Morris
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Thu Aug 02 2001 - 12:16:52 PDT