From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching Date: Mon, 21 Oct 2013 17:48:54 +0200 Message-ID: <52654CE6.7030706@redhat.com> References: <1380910855-12325-1-git-send-email-dborkman@redhat.com> <87li1qp3l8.fsf@xmission.com> <526231E0.6060903@redhat.com> <526543A2.2040901@monom.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Eric W. Biederman" , pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org, netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tejun Heo , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Daniel Wagner Return-path: In-Reply-To: <526543A2.2040901-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On 10/21/2013 05:09 PM, Daniel Wagner wrote: > On 10/19/2013 08:16 AM, Daniel Borkmann wrote: >> On 10/19/2013 01:21 AM, Eric W. Biederman wrote: >> >>> I am coming to this late. But two concrete suggestions. >>> >>> 1) process groups and sessions don't change as frequently as pids. >>> >>> 2) It is possible to put a set of processes in their own network >>> namespace and pipe just the packets you want those processes to >>> use into that network namespace. Using an ingress queueing filter >>> makes that process very efficient even if you have to filter by port. >> >> Actually in our case we're filtering outgoing traffic, based on which >> local socket that originated from; so you wouldn't need all of that >> construct. Also, you wouldn't even need to have an a-prio knowledge of >> the application internals regarding their use of particular use of ports >> or protocols. I don't think that such a setup will have the same >> efficiency, ease of use, and power to distinguish the application the >> traffic came from in such a lightweight, protocol independent and easy way. > > Sorry for beeing late as well (and also stupid question) > > Couldn't you use something from the LSM? I mean you allow the > application to create the socket etc and then block later > the traffic originated from that socket. Wouldn't it make > more sense to block early? I gave one simple example for blocking in the commit message, that's true, but it is not limited to that, meaning we can have much different scenarios/policies that netfilter allows us than just blocking, e.g. fine grained settings where applications are allowed to connect/send traffic to, application traffic marking/ conntracking, application-specific packet mangling, and so on, just think of the whole netfilter universe.