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 14:45:54 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	hadi@...erus.ca
CC:	Thomas Graf <tgraf@...g.ch>, 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 14:09 +0200, Patrick McHardy wrote:
> 
>> Yes, but it was the use of current->pid that was wrong.
> 
> There are many many apps out there which still use ioctls - hence the
> ambiguity of "is it the kernel that generated the command that caused
> the event or was it merely a proxy for some app". 
> You need to resolve that. 

Mhh .. we could use a magic nlmsg_pid value (just like zero)
to indicate it was done on behalf of a process using ioctls or
some other, non-netlink means. I'm wondering how useful this
(or any other "whodunit" identifier) would be for filtering
though, I think you're usually more interested in certain
objects than certain processes, like all routes to 192.168.0.0/16,
no matter who changes them.

>> If one of those calls are in a path invoked through netlink
>> it should set nlmsg_pid.
> 
> Nod - I think thats mostly taken care of; havent looked lately. I know
> Alexey didnt object to any patches i submitted that did change how
> nlmsg_pid was set on events to match this thought and I cant think of a
> reason it would violate any netlink ettiquette. 
> 
> Note, I find the whoddunit field (not the pid) to be also useful for
> aesthetics and debugging other than for the non-ambiguity in the
> filtering.

Unfortunately we can't add a new field to the existing headers
without breaking things, so anything new would likely be subsystem
specific.

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