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

[Alban Crequy]

Le Sun, 26 Sep 2010 07:47:29 +0300,
"Rémi Denis-Courmont" <remi at remlab.net> a écrit :

>    Hello,
> 
> On Saturday 25 September 2010, Lennart Poettering wrote:
> > Note that BSD socket filters are generic and should work on any
> > kind of socket, be it AF_INET, AF_NETLINK or AF_UNIX. Right now, as
> > we speak, not needing any kernel patches. They can be used to
> > minimize the amount of wakeups as every client could upload its own
> > filters into its socket that matches exactly what it is interested
> > in.
> 
> Slightly off topic... I never understood how the BPF syntax can be
> applied to SOCK_STREAM sockets though? I realize it is supposed to
> work with TCP on Linux... does anybody know the semantics?

It seems implemented at the TCP level on AF_INET, so the BSD Socket
Filter can read the TCP segment with source port, destination port, etc.
and the data after the TCP header. I don't see any possible usage of
socket filtering on AF_INET. Filtering on the data after the TCP
header does not make sense since the boundaries of packets can change.

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.

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


Le Sat, 25 Sep 2010 21:06:46 +0200,
Lennart Poettering <mzqohf at 0pointer.de> a écrit :

> To make use of BSD socket filters for the routing in D-Bus a scheme
> inspired by this could be used: put hashes of the destination, member
> and interface into the header, plus a bloom filter for the member
> arguments. Then, on the receiving side simply upload the appropriate
> BSD socket filter into the AF_UNIX and hence receive only the packets
> you are interested in. 

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)?

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.

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?

-- 
Alban