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
Received on Wed Apr 26 08:07:06 2006