On Fri, Feb 27, 2004 at 08:26:53PM +0100, Thomas Gelf wrote:
> Am Fre, den 27.02.2004 schrieb Herbert Poetzl um 17:50:
> > ad TUN/TAP, that is a solution, but you do not want that,
> > because it would slow down the network implementation
> > very much (similar to the slowdown UML imposes) and it
> > isn't required at all ...
>
> on my uml servers I moved many many gigabytes over TUN/TAP
> devices and I didn't notice any performance problems. did
> you run any tests to prove this "very much slowdown"? uml
> performance problems result mostly from the poor performance
> of loopback-mounted sparse-files. cpu, ram and network
> performance is very good on uml.
well, the thing is, in that case you would need two
tuntap devices to get the same as the UML implementation
uses, one converting the packets to a data stream, and
the other converting it back from data stream to packets
(which doesn't make much sense)
and this doesn't even cover the restrictions, not
present in UML (so you have to use iptables & co on
the host)
> as there is no other usable solution at the moment I wouldn't
> say that it isn't required at all. it is easy to implement,
hmm, I'd like to know what problems you ahve with the
current approach, except for the fact, that it doesn't
look nice to have eth0:XYZ instead of eth0?
> you can give CAP_NET_RAW and CAP_NET_ADMIN to your vservers
> (if it would be possible to limit them to one single interface
> - and that is the only thing you should have to change in the
> vserver patches).
>
> > latest 2.6 patches of linux-vserver allow private namespaces
> > and the next step might be to extend this to the network
> > interface (which could give you the eth0 you want)
>
> what exactly does "private namespaces" mean? is there some
> documentation lying around? and will they allow full access
> to one (or more) interfaces without security problems? it's
> no problem if the interface isn't called eth0, the main
> problem is the ridiculous networking support - no native
> ping (ok, we solved that problem with dummy0 and a bridge),
> no loopback device, as I've read on this list (never tried
> out by myself) problems with nmap, portmap, samba...
I'd appreciate a list of things you are 'missing'
together with a small comment, how to make that feature
secure on a vserver, as example:
- missing: ping doesn't work like on linux server xy
why: ping requires CAP_NET_RAW, giving that would mean
- vserver can generate arbitrary packets
- vserver can fake packets from other vservers
- vserver can generate fake arp replies
this can be secured by:
- checking every raw packet via some packet checker
- filtering out malicious packets ...
> > So 'adapting' FreeVPS network stuff, would be similar
> > to rewriting it from scratch, unless Alexey or Say break
> > out and document or explain the network stuff in small
> > chunks ...
>
> rewriting from scratch is not a bad thing - it is often
> the best thing that could be done.
agreed, that is why the current vserver code is basically
a rewrite of the version known as ctx17 ...
> > personally I don't think that the FreeVPS network approach
> > is the best, because it is very intrusive, and in most
> > cases not required ...
>
> I agree with you on the fact that it is very intrusive,
> as far as I can judge that. maybe the "approache" is not
> the best, but nonetheless network support in freevps is
> MUCH BETTER - and we should try to realize something like
> that in the vserver project.
hmm, could you do some security tests regarding the
network tricks possible with FreeVPS, I would be very
interested, what they allow and what not ...
> > this doesn't mean that I would not accept tested patches
> > against linux-vserver kernels which add virtualized
> > networking ...
>
> unfortunately I'm not a c programmer and I've no practice
> in kernel hacking. you can ask me many many things about
> networking, databases, web development and system & network
> administration (routers, switches, firewalls, web-, mail-,
> fileservers,...) - but ('til now :) I cannot provide patches
> against linux-vserver.
>
> the easiest solution from my point of view is using bridges,
> tun/tap interfaces and give every vservers FULL ACCESS to
> only one (or more) of them. all but limiting the access to
> only the specified interface(s) is already done and ready
> for use. and this last thing requires a kernel patch. got
> it?
yeah, we should talk about that on irc, I'm very
interested in your findings and your approaches and
ofcourse your ideas, maybe together we can find that
better solution, which is still missing ...
> > you won't be able to get 'real networking support', because
> > that would be a security issue in any case ...
> >
> > just think about manipulating arp/icmp and other stuff ...
>
> BULLSHIT! a bad boy on a vserver with full network support is
> only as dangerous as a bad boy on a real server on your network
> segment or somewhere else out there. and if you use a bridge
> inside the host server, using iptables or the powerful ebtables
> in kernel v2.6 you can do very, very powerful things (also
> inside the bridge, much more than you can do on a switch) - that
> would send all the bad boys to another playground, and give
> anyone else powerful networking support inside a vserver and
> NO CHANCE to disturb you or others.
well, real servers have separate network cards, and
switches guarding between them, but yes, all that is
possible in software too (see example above)
> all the nice things like traffic shaping can easily be done,
> no alias interfaces are needed - but you could create them
> inside the vserver if you like...
agreed
> > but a good start would be to draft up a document (maybe
> > on the wiki) which describes what abilities and limitations
> > such a network support for vserver would have ...
>
> I'll try to clearly write my ideas down again an publish this
> document somewhere. a draft describing where and how the vserver
> patches interfere in the kernel would also be a great help,
> prevent many stupid question and may lead to some good ideas
> from other people.
>
> have a nice evening!
you too!
TIA,
Herbert
> --
> Thomas Gelf <[EMAIL PROTECTED]>
>
> _______________________________________________
> Vserver mailing list
> [EMAIL PROTECTED]
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver
