netdev - Re: [PATCH net-2.6.25] Add packet filtering based on process's security context.

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:	Mon, 03 Dec 2007 08:58:59 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	James Morris <jmorris@...ei.org>
CC:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
	linux-security-module@...r.kernel.org,
	netfilter-devel@...ts.netfilter.org,
	Stephen Smalley <sds@...ho.nsa.gov>
Subject: Re: [PATCH net-2.6.25] Add packet filtering based on process's security
 context.

James Morris wrote:
> On Thu, 22 Nov 2007, Tetsuo Handa wrote:
> 
>> This patch allows LSM modules filter incoming connections/datagrams
>> based on the process's security context who is attempting to pick up.
>>
>> There are already hooks to filter incoming connections/datagrams
>> based on the socket's security context, but these hooks are not
>> applicable when one wants to do TCP Wrapper-like filtering
>> (e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).
> 
> This functionality looks like it could be useful in that we currently have 
> no direct security mapping from incoming packet to user process, but only 
> to the receiving socket, as you mention.  For SELinux, it may help us 
> simplify/clarify policy.
> 
> It's also been long-desired for netfilter/iptables, to allow ipt_owner to 
> work cleanly for incoming packets.
> 
> So, this probably needs to be implemented in a way which works for both LSM 
> and netfilter.  There have been several discussions on the issue from the 
> netfilter side, although I don't know what the latest status of that is 
> (I've expanded the cc list to hopefully get some more feedback).

No news on that. I'm also a bit sceptical if adding all this complexity
and overhead would really be worth it (considering only netfilter) just
to use the owner match and UID/GID matching. It wouldn't even be
accurate because there is not 1:1 mapping of sockets and processes.

I actually like Samir Bellabes' approach, which doesn't suffer from
these problems IIRC.

>>>From memory, one approach under discussion was to add netfilter hooks to 
> the transport layer, which could be invoked correctly by each type of 
> protocol when the target process is selected.

We can only invoke the hooks after the socket lookup, but we don't
know which process is going to call recvmsg() for that socket.
--
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