netdev - Re: [PATCH nf-next] netfilter: xtables: lightweight process control group matching

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]

Message-ID: <20131009170409.GH22495@htj.dyndns.org>
Date:	Wed, 9 Oct 2013 13:04:09 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Daniel Borkmann <dborkman@...hat.com>
Cc:	pablo@...filter.org, netfilter-devel@...r.kernel.org,
	netdev@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [PATCH nf-next] netfilter: xtables: lightweight process control
 group matching

Hello,

On Tue, Oct 08, 2013 at 10:05:02AM +0200, Daniel Borkmann wrote:
> Could you elaborate on "Wouldn't it be more logical to implement netfilter
> rule to match the target cgroup paths?". I don't think (or hope) you mean
> some string comparison on the dentry path here? :) With our proposal, we
> have in the network stack's critical path only the following code that is
> being executed here to match the cgroup ...

Comparing path each time obviously doesn't make sense but you can
determine the cgroup on config and hold onto the pointer while the
rule exists.

> ... where ``info->id == skb->sk->sk_cgrp_fwid'' is the actual work, so very
> lightweight, which is good for high loads (1Gbit/s, 10Gbit/s and beyond), of
> course. Also, it would be intuitive for admins familiar with other subsystems
> to just set up and use these cgroup ids in iptabels. I'm not yet quite sure
> how your suggestion would look like, so you would need to setup some "dummy"
> subgroups first just to have a path that you can match on?

Currently, it's tricky because we have multiple hierarchies to
consider and there isn't an efficient way to map from task to cgroup
on a specific hierarchy.  I'm not sure whether we should add another
mapping table in css_set or just allow using path matching on the
unified hierarchy.  The latter should be cleaner and easier but more
restrictive.

Anyways, it isn't manageable in the long term to keep adding
controllers simply to tag tasks differently.  If we want to do this,
let's please work on a way to match a task's cgroup affiliation
efficiently.

Thanks.

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