netdev - Re: [PATCH 0/5] Networking cgroup controller

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:   Thu, 25 Aug 2016 11:56:27 -0700
From:   Mahesh Bandewar (महेश बंडेवार) 
        <maheshb@...gle.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Tejun Heo <tj@...nel.org>, corbet@....net, lizefan@...wei.com,
        hannes@...xchg.org, David Miller <davem@...emloft.net>,
        kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
        kaber@...sh.net, linux-doc@...r.kernel.org,
        cgroups@...r.kernel.org, linux-netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Wei Wang <weiwan@...gle.com>, tom@...bertland.com
Subject: Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote:
>> On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo <tj@...nel.org> wrote:
>> > Hello, Anoop.
>> >
>> > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote:
>> >> This patchset introduces a cgroup controller for the networking subsystem as a
>> >> whole. As of now, this controller will be used for:
>> >>
>> >> * Limiting the specific ports that a process in a cgroup is allowed to bind
>> >>   to or listen on. For example, you can say that all the processes in a
>> >>   cgroup can only bind to ports 1000-2000, and listen on ports 1000-1100, which
>> >>   guarantees that the remaining ports will be available for other processes.
>> >>
>> >> * Restricting which DSCP values processes can use with their sockets. For
>> >>   example, you can say that all the processes in a cgroup can only send
>> >>   packets with a DSCP tag between 48 and 63 (corresponding to TOS values of
>> >>   192 to 255).
>> >>
>> >> * Limiting the total number of udp ports that can be used by a process in a
>> >>   cgroup. For example, you can say that all the processes in one cgroup are
>> >>   allowed to use a total of up to 100 udp ports. Since the total number of udp
>> >>   ports that can be used by all processes is limited, this is useful for
>> >>   rationing out the ports to different process groups.
>> >>
>> >> In the future, more networking-related properties may be added to this
>> >> controller.
>> >
>> > Thanks for working on this; however, I share the sentiment expressed
>> > by others that this looks like too piecemeal an approach.  If there
>> > are no alternatives, we surely should consider this but it at least
>> > *looks* like bpf should be able to cover the same functionalities
>> > without having to revise and extend in-kernel capabilities constantly.
>> >
>> My primary concern is the cost that need to be paid to get this functionality.
>> (a) The suggested alternatives eBPF either can't solve the problem in
>> the current form or need substantial work to get it done. e.g.
>> udp-port-limit since there is no notion of "maintaining
>> counters-per-group-of-processes". This is solved by the cgroup infra.
>
> what is specifically missing?
> there are several ways to do counters in bpf and as soon as bpf program
> is attachable to a cgroup, all of these counter features come for free.
> Counting bytes or packets or port bind failures or anything else per cgroup
> with bpf is trivial. No extra code is needed.
>
Alexei, I was referring to the association of eBPF to the cgroup. Lack
of it makes anyone wants to use it invest into additional
administrative infra that you are currently getting with cgroup-infra.

>> (b) Also the hooks implemented are mostly with a per packet cost vs.
>> once when you are establishing the channel. Also not sure if the LSM
>> approach will allow some privileged user to over-ride the filters
>> attached and thus override the limits imposed. This is on top of the
>> administrative costs that currently don't have solution for and you
>> get it for free with cgroup infra.
>>
>> In short most of the associated problems are handled by the
>> cgroup-infra / APIs while all that need separate solution in
>> alternatives.  Tejun, feels like I'm advocating cgroup approach to you
>> ;)
>>
>> Thanks,
>> --mahesh..
>>
>>
>> > Thanks.
>> >
>> > --
>> > tejun