Oliver Welter wrote: >Hi Manish, > > > >>Has anybody done any work or study on security of vserver. What are the >>possible security downsides and possible areas of attack on vserver both >>from other vservers on the same host and from external agent. Any pointers >>on this would be very helpful. Thanks, >> >> > >I havent done a study, but from the basic idea behind vserver following >issues are relevant: >* if we assume, the context isolation works without errors, the risk for >guest - guest attacks is equal to physical independent server > >
That's quite a foolish assumption. It's probably safe to assume by default that "local exploit" vulnerabilities now affect your cross-vserver cluster, unless proven otherwise. Let's not be cavalier about this. No-one has done the full auditing yet to prove that any of the single-kernel virtualisation systems are truly isolated. As far as we know, all the holes have been closed - certainly since the /proc filtering the level of uncertainty has dropped sharply - but there are still an awful lot of entry points into the kernel, each of which might have a security bug. Sam. >* for non root users it is impossible to attack a guest from the host side >* it IS possible - and with a faulty setup very likely - that a raising >need for ressources (IO, mem, network) of a guest affects the other >guests - as they share the same physikal maschine. The scheduler concept >might help here >*If there is a flaw in the isolation code of vserver OR someone manages >to exploit a kernel bug to load some modules from inside a guest, all of >the above is no longer true. I dont know if anybody here has practical >results on this > >As I dont know what you mean with "external agents" I cant help you on >this. If you simply mean attacks from outside, vserver is not more >vulnerable like any other system. A bad setup of some services might >enable an attacker to take over the guest with root privs, but even in >this case he will not have that much fun, as a lot of things are not >allowed inside a guest. E.g. he cant spawn new IPs, compromise your >kernel, etc. This behaviour can be improved by tailoring the >capabilities of the guest. > >HTH > >Oliver > > > >------------------------------------------------------------------------ > >_______________________________________________ >Vserver mailing list >Vserver@list.linux-vserver.org >http://list.linux-vserver.org/mailman/listinfo/vserver > > _______________________________________________ Vserver mailing list Vserver@list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver
