From: Tejun Heo <tj@kernel.org>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: pablo@netfilter.org, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching
Date: Mon, 7 Oct 2013 12:46:47 -0400 [thread overview]
Message-ID: <20131007164647.GA2481@htj.dyndns.org> (raw)
In-Reply-To: <1380910855-12325-1-git-send-email-dborkman@redhat.com>
Hello,
On Fri, Oct 04, 2013 at 08:20:55PM +0200, Daniel Borkmann wrote:
> It would be useful e.g. in a server or desktop environment to have
> a facility in the notion of fine-grained "per application" or "per
> application group" firewall policies. Probably, users in the mobile/
> embedded area (e.g. Android based) with different security policy
> requirements for application groups could have great benefit from
> that as well. For example, with a little bit of configuration effort,
> an admin could whitelist well-known applications, and thus block
> otherwise unwanted "hard-to-track" applications like [1] from a
> user's machine.
>
> Implementation of PID-based matching would not be appropriate
> as they frequently change, and child tracking would make that
> even more complex and ugly. Cgroups would be a perfect candidate
> for accomplishing that as they associate a set of tasks with a
> set of parameters for one or more subsystems, in our case the
> netfilter subsystem, which, of course, can be combined with other
> cgroup subsystems into something more complex.
>
> As mentioned, to overcome this constraint, such processes could
> be placed into one or multiple cgroups where different fine-grained
> rules can be defined depending on the application scenario, while
> e.g. everything else that is not part of that could be dropped (or
> vice versa), thus making life harder for unwanted processes to
> communicate to the outside world. So, we make use of cgroups here
> to track jobs and limit their resources in terms of iptables
> policies; in other words, limiting what they are allowed to
> communicate.
>
> We have similar cgroup facilities in networking for traffic
> classifier, and netprio cgroups. This feature adds a lightweight
> cgroup id matching in terms of network security resp. network
> traffic isolation as part of netfilter's xtables subsystem.
I don't think the two net cgroups were a good idea and definitely
don't want to continue the trend. I think this is being done
backwards. Wouldn't it be more logical to implement netfilter rule to
match the target cgroup paths? It really doesn't make much sense to
me to add separate controllers to just tag processes. Please classify
tasks in cgroup and let netfilter match the cgroups.
Thanks.
--
tejun
next prev parent reply other threads:[~2013-10-07 16:46 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 [this message]
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
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=20131007164647.GA2481@htj.dyndns.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=dborkman@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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).