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]

Message-ID: <20080402142834.GE20815@postel.suug.ch>
Date:	Wed, 2 Apr 2008 16:28:34 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	jamal <hadi@...erus.ca>
Cc:	Patrick McHardy <kaber@...sh.net>,
	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 <hadi@...erus.ca> 2008-04-02 09:10
> I think both are of interest.
> Historically in routes for example, the interest would be apps/processes
> (not direct mapping to processids) that are of interest (eg a route
> added by OSPF vs one added by RIP etc). Filtering is done in user space
> so you dont repropagate routes added by the "OSPF process" to RIP if
> policy says so etc.
> That of course has evolved to application name (gated vs zebra vs bird
> etc) which implements all of OSPF/RIP/BGP etc and can keep track of
> things. Theres further evolution which desires to run multiple instances
> of quagga on the same machine etc.
> I dont think the processid is the right thing, but some 32 bit id which
> maps to a name would be useful or even a static field defined in some
> header file. The name serving could be out of the kernel for simplicity
> if the process dies and is re-incarnated it knows what to read(some of
> these ideas are already in genetlink).

I think this is over the top. The netlink port already provides good
means to retrieve information about the originator of a netlink message.
An additional genl interface which would resolve a netlink port to a
a process id / process name would be very helpful though.

If you want to keep track of netlink processes which have already closed
the socket then a userspace daemon which subscribes to all groups and
keeps a log of netlink port plus eventually message sequence numbers
would be a better solution IMHO. The daemon could be used to log netlink
events in general and even have triggers to invoke commands upon certain
events.

However, I'm positive to the idea of storing the netlink port on a per
object basis. It would be nice to know which application is responsible
for the creation of certain qdiscs without having to listen to events.

We could define the netlink port as follows to cover both netlink and
non netlink applications:

  port identifier (10 bits) + process id (22 bits)

A special value for the port identifier is defined (e.g. all zeros) which
specifies that the netlink port is really a ioctl based application. This
way we can encode the process id for both netlink and ioctl, distinguish
between them and support 1023 netlink sockets per application.
--
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