Re: Low-level network hooks and rtnetlink

jmorrisat_private

On Thu, 2 Aug 2001, Stephen Smalley wrote:

>
> On Fri, 3 Aug 2001, James Morris wrote:
>
> > 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.
>
> One other observation on this topic:  Notice that LSM has a hook in the
> capable() function.  So assuming that the existing capable() calls provide
> a consistent control over access to the routing table regardless of
> whether you use a rtnetlink socket or an ioctl call, then a security
> module also can provide a consistent control by performing its checking
> in the capable() hook.
>

Yes, ioctls which modify the main routing table, ARP table and the
netdevices all check for CAP_NET_ADMIN, so we can provide coarse yet
consistent controls on these objects.  Note that this will not provide
control over read operations.

> The only limitation of this approach is that the
> capabilities are fairly coarse-grained (CAP_NET_ADMIN, in this case)
> and cannot take into account other parameters.

There are at least two existing implementations which use fine-grained
controls on low-level network objects: selinux with labeled interfaces,
and Malcolm Beattie's MAC with labeled routing tables (I'm not sure if
this is currently under active development).

If any implementations depend on these kinds of fine-grained controls, and
have no viable workaround under LSM, capable() hooks will probably not be
enough.

Also, after further investigation of option #3 from my last post, it looks
like it will be a very messy job to hook all accesses to low-level network
objects at some level underneath both ioctl() and rtnetlink.  I haven't
come up with a good solution for this yet.

- James
-- 
James Morris
<jmorrisat_private>

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