Re: [Devel] [RFC][PATCH] IP address restricting cgroup subsystem

[Grzegorz Nosek <root-AfQBxy1nhrQ00sYp1HPQUA@public.gmane.org>]

On pią, sty 09, 2009 at 01:58:42 -0800, Paul Menage wrote:
> While something to allow restricting network access from tasks in a
> cgroup is useful, the basic problem with the patches that have been
> proposed is the userspace API.
> 
> Once an API makes it into the kernel, we have to support it more or
> less indefinitely. So that means we want to come up with something
> that will satisfy say 95% of users *before* it gets anywhere near
> mainline.

Certainly. The patch is RFC, not mainline-me-now. While it scratches my
current itch, I'd definitely want it to be more useful. I just wanted to
receive some comments on the overall idea before I invest way too much
time in it.

> So for example, some people might want multiple IP addresses; others
> might want to specify a subnet, but exclude certain addresses;
> controlling which ports or port-ranges can be bound to is also useful
> (and in fact is what I'd be most interested in).

...and some people mignt not want the loopback special case. So we'd
need a black- and whitelist of:

IP address [/netmask] [port [- port]]

right? Would that cover a reasonable set of use cases? If there are
going to be multiple addresses, we'd probably want some mechanism to
determine which one should be used for remapping INADDR_ANY. BTW, do you
want to restrict connect() source ports too?

> Ideally we'd avoid making up a brand new userspace API for this. It
> would be great if we could somehow make use of the iptables API, which
> already has support for specifying these kinds of conditions.

The iptables interface is nice but only works with network packets and
not sockets and I'd find bind() remapping via iptables rather strange.
I'm currently using iptables to SNAT outgoing connections per uid but
I find the cgroup idea rather appealing (as many resources as possible
managed from a single virtual directory with simple shell tools).

So, are you opposed to the current implementation (single IP address) or
to the interface (a file in cgroupfs)?

> I did once hack together a proof-of-concept that let you use iptables
> for controlling connect/accept/bind operations, but it was a complete
> mess and wouldn't survive code review :-)

<shudder> :)

Best regards,
 Grzegorz Nosek
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers