Re: Low-level network hooks and rtnetlink

jmorrisat_private

On Fri, 10 Aug 2001, Stephen Smalley wrote:

>
> Actually, I would prefer to keep the netdev_ops ioctl hook call in
> devinet_ioctl.  At that point, the interface name has been copied into
> the kernel, so we can use it to control the ability of an application
> to configure a particular network interface.

Unfortunately for us, this does not catch all interface/device
configuration attempts.  Some ioctls follow a different path and work at
the generic device layer, such as those used to set the MTU and multicast
addresses.

For example, if you type:

# ifconfig eth1 mtu 999

the ioctl will not be seen in devinet_ioctl().

There are also some very low-level ioctls (such as SIOCETHTOOL and
wireless calls) which drop through the device layer to the hardware
drivers, and peform copy_from_user() at that level.

So, we start to end up with numerous hooks at the network, device and
hardware layers.  And this is just for ioctls.

Interfaces (and many other things) can also be configured via rtnetlink
messages, so we'd also need to add more hooks here to prevent users
bypassing the same policies.  Finding the right level of abstraction is
also an issue; do we have something like:

  netdev_ops->ioctl();
  netdev_ops->rtmsg();
  netdev_ops->procinfo();
  netdev_ops->sysctl();

with quite different types of arguments and processing requirements for
the LSM module developer, or something more consistent:

  netdev_ops->setattr(dev);
  netdev_ops->getattr(dev);

The latter seemed to work ok technically for the prototype (except for
rtnetlink broadcasts), but was becoming ugly in terms of the number of
hooks in the kernel.

If you only need getattr(), this would certainly reduce the number of
hooks and complexity.  Another issue, however, is that for ioctls below
the network layer, and for rtnetlink messages, we'd be putting hooks into
protocol-independent code.  This might look a little odd if we're only
using them for IPv4 initially.

- James
-- 
James Morris
<jmorrisat_private>

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module