netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: "Ni, Xun" <xun.ni@intel.com>
Cc: Daniel Wagner <wagi@monom.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"pablo@netfilter.org" <pablo@netfilter.org>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>
Subject: Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
Date: Tue, 22 Oct 2013 09:42:13 +0200	[thread overview]
Message-ID: <52662C55.9020701@redhat.com> (raw)
In-Reply-To: <91E2D863603AD4478F101CE81E76E45D01828D59@SHSMSX103.ccr.corp.intel.com>

On 10/22/2013 09:15 AM, Ni, Xun wrote:
> Hello, Daniel:
>     can all your examples block early before doing network operations? What's the whole netfilter universe? Can you give us more clear examples?

As you can see from the code, the netfilter hooks are located
in NF_INET_LOCAL_OUT and NF_INET_POST_ROUTING.

> Thanks
> 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.
> --
> To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

  reply	other threads:[~2013-10-22  7:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 18:20 [PATCH nf-next] netfilter: xtables: lightweight process control group matching Daniel Borkmann
2013-10-07  3:07 ` Gao feng
2013-10-07  9:17   ` Daniel Borkmann
     [not found]     ` <52527C3E.1060004-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-07  9:42       ` Gao feng
2013-10-07 16:46 ` Tejun Heo
2013-10-08  8:05   ` Daniel Borkmann
     [not found]     ` <5253BCAE.5060409-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-09 17:04       ` Tejun Heo
2013-10-09 19:12         ` Daniel Borkmann
     [not found]         ` <20131009170409.GH22495-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-10-10 21:55           ` Daniel Borkmann
     [not found] ` <1380910855-12325-1-git-send-email-dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-18 23:21   ` Eric W. Biederman
     [not found]     ` <87li1qp3l8.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-10-19  7:16       ` Daniel Borkmann
2013-10-21 15:09         ` Daniel Wagner
     [not found]           ` <526543A2.2040901-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
2013-10-21 15:48             ` Daniel Borkmann
2013-10-22  7:15               ` Ni, Xun
2013-10-22  7:42                 ` Daniel Borkmann [this message]
2013-10-22  7:45                 ` Daniel Wagner
     [not found]               ` <52654CE6.7030706-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-10-22  7:36                 ` Daniel Wagner
     [not found] <cover.1382101225.git.dborkman@redhat.com>
2013-10-18 13:28 ` Daniel Borkmann
     [not found]   ` <ee0fb538d6e43e23d0488d3edd741de9c4589fb1.1382101225.git.dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-11-05 13:03     ` Daniel Borkmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52662C55.9020701@redhat.com \
    --to=dborkman@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=tj@kernel.org \
    --cc=wagi@monom.org \
    --cc=xun.ni@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).