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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 02 Apr 2008 14:07:30 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
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

jamal wrote:
> 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". 

Yes, for ioctl it can't carry anything but zero because it
should contains the netlink socket pid, not the process ID,
which obviously doesn't exist in that case.

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

True, but that doesn't really matter. You also can't assume that
a positive number matches the process ID.

> c) what happens when processid goes to > 32-bit?

Wouldn't be a problem, its the netlink socket pids, which are 32
bit no matter what.

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

In my opinion we should try to set nlmsg_pid properly since thats
whats defined as unique identifier for netlink sockets.
--
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