[PATCH 0/5] RFC: Multicast and filtering features on AF_UNIX

[Lennart Poettering]

1;2591;0cOn Mon, 27.09.10 16:03, Alban Crequy (alban.crequy at collabora.co.uk) wrote:

> setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...) checks and attaches
> the BPF to the socket successfully both on AF_INET and AF_UNIX. But in
> practice, sk_run_filter() is never called on AF_UNIX. I tried to attach
> a BPF to a SOCK_STREAM AF_UNIX socket and whatever my BPF is, I can
> still receive everything on the socket. I guess it could be implemented
> if it is found useful.

Hmm, not sure it makes a lot of sense to use a packet filter on a
non-dgram socket. However, I expected that BSD socket filters would work
just fine on AF_UNIX/SOCK_DGRAM. If they don't, then it is probably a
good idea to fix that. And my (uneducated) guess is that it would be
relatively easy.

> Is there any real use of BSD socket filters on a non-AF_NETLINK
> socket?

Off the top of my head I know only wireshark/tcpdump, libudev, ping,
dhcpcd who use them, but I guess a google code search should reveal
more. Of those listed I think udev is the only one using them on
AF_NETLINK and everybody else uses them on AF_INET/SOCK_RAW, but I might
be wrong on that.

> Do you suggest to put these additional hashes in the header of D-Bus
> messages sent by userspace D-Bus peers (hence modifying the D-Bus
> protocol)?

Well, you need to modify the protocol anyway if you use SOCK_DGRAM
instead of SOCK_STREAM as transport. And if you do that a few fixed size
hash fields in the prefix shouldn't hurt.

> If we use bloom filters for D-Bus match rules to replace the
> dbus-daemon's implementation of AddMatchRule(), we will possibly
> receive a few unexpected D-Bus messages. It is not so much
> an issue because it will be rare and applications still need to parse
> and check the messages anyway.

Nice thing is that you can size the bloom filters based on the
probabilities you want to reach, and as it turns out this works really
well and the filters remain relatively short.

Some awesome dude once wrote a blog story explaining how to use bloom
filters in real-life implementations:

http://0pointer.de/blog/projects/bloom.html

(The awesome dude put that together when Kay and I were discussing bloom
filter use in udev).

> But the bus security policy cannot be implemented with BSD Packet
> Filter because applications could upload any filter to receive secret
> messages. I don't see how to implement the bus security policy in the
> kernel without parsing the D-Bus messages.
> 
> Did you suggest socket filters only to avoid the cost of parsing D-Bus
> messages in the kernel, or is there other benefits?

BSD socket filters are not useful to fix security problems. They are
useful only for reducing wakeups. For policy enforcement we probably
will need something similar to iptables/ebtables/arptables/xtables maybe
dubbed untables. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.