netdev - Re: [PATCH net-2.6.26] netlink: make socket filters work on netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 02 Apr 2008 07:42:13 -0400
From:	jamal <hadi@...erus.ca>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, shemminger@...tta.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.26] netlink: make socket filters work on netlink

On Wed, 2008-02-04 at 12:00 +0200, Patrick McHardy wrote:

> No, in the case of events its supposed to be set to the pid of the
> socket that caused the event. Check out qdisc_notify() or rtmsg_ifa()
> for example.

nod - however, there is inconsistency;
for example if rtmsg_ifa() was in the code path of something invoked by
ioctl, the pid of the event will be 0. Alexey almost chewed my head off
when i tried to change that. His (valid) explanation was, if iirc:
a) that the pid belonged to the source - and 0 means "kernel". 
b) The pid could also be some negative number (even in qdisc_notify) if
you have multiple netlink sockets in one process (resolvable if you
getname())
c) what happens when processid goes to > 32-bit?

> nlmsg_seq is already used by userspace to match responses to requests,
> so that probably wouldn't work very well.

True, and thats what made me suggest earlier that if i had two sockets
in my app, one listening and the other sending (the way quagga does for
example), and that the app has a setting which says "all my netlink
messages to the kernel would have sequence 0x1234" - then the listening
socket could be told to set bpf to filter out any events with sequence
0x1234. This overcomes all of #a, #b and #c above but i admit it is
equally weak as using pids because it relies on the fact that only one
app is targeting something in the kernel with sequence 0x1234. You could
do it if you owned the box.
As one step further - route messages "proto" field on the other hand
overcomes that challenge of multiple applications ambiguity. of course
this has other challenges as well (ex: several apps claiming to be zebra
or if you intentionaly want to run multiple quaggas for VRs but wanted
to distinguish who added the route).

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html