How secure is vserver?

[Sthu Deus]

Good day.

How secure is vserver? From

http://linux-vserver.org/Welcome_to_Linux-VServer.org

it is not clear to me: "guarantee the required
security"

as what are the requirements. Can You explain its isolation level? Say, If I
place there a server, and one day it will be hacked so that the criminal gets
full control of the guest OS, - will it protect the host OS?

Thank You for Your time.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Izak Burger]

On Sun, May 31, 2009 at 8:56 PM, Sthu Deus <sthu.deus@...> wrote:
> as what are the requirements. Can You explain its isolation level? Say, If I
> place there a server, and one day it will be hacked so that the criminal gets
> full control of the guest OS, - will it protect the host OS?

Linux vserver shares the kernel between the various virtual hosts, a
little like BSD jails. There are restrictions on what one can do: not
even root can modify network interfaces or even create a node (using
mknod) or mount a filesystem, so breaking out of the virtualhost is
pretty hard. No guarantees, but to answer your question, yes, it does
protect the host OS.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sthu Deus]

Good day, Izak.

Thank You for Your reply:
>Linux vserver shares the kernel between the various virtual hosts, a
>little like BSD jails. There are restrictions on what one can do: not
>even root can modify network interfaces or even create a node (using
>mknod) or mount a filesystem, so breaking out of the virtualhost is
>pretty hard. No guarantees, but to answer your question, yes, it does
>protect the host OS.

Ok, what is Your opinion on qemu guest - does it offer more
protection/guarantee?


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Izak Burger]

On Thu, Jun 4, 2009 at 5:00 PM, <sthu.deus@...> wrote:
> Ok, what is Your opinion on qemu guest - does it offer more
> protection/guarantee?

The differences are in how much is virtualised.

Vserver does very little virtualisation and focuses on isolation.
There is no virtual cpu, virtual network device or any such thing, and
the virtual host doesn't boot its own kernel. Processes running one
security context cannot see processes running in another. You cannot
modify network interfaces and you cannot mount file systems. You
cannot even use mknod (unless you override it to allow this), because
access to mknod would allow me to for example create /dev/sda and just
read in the entire thing, thereby accessing the host.

Qemu, VirtualBox and VMWare is on the other end of the scale. They
virtualise the cpu, video, network and disk hardware, and you boot a
kernel on them.

On the question of security, the options with more virtualisation
should be safer, but vserver has a performance edge, see this:

http://www.playingwithwire.com/2009/06/virtual-failure-yippiemove-switches-from-vmware-to-freebsd-jails/

On vserver, the danger lies in the attacker finding a way to break
through to the host. On the virtualised options, the danger lies in
the attacker finding a way to trick the process into overwriting some
kind of memory/file it shouldn't, much like any other process. Because
vmware, virtualbox and qemu usually have kernel modules to improve
performance, these possibilities exist at least in theory.

If you push me for an answer, I'll say qemu, virtualbox and/or vmware
should be safer, but in practice I will likely choose vserver because
there is way less complexity involved and much better performance.


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Izak Burger]

On Fri, Jun 5, 2009 at 9:54 AM, Izak Burger<isburger@...> wrote:
> If you push me for an answer, I'll say qemu, virtualbox and/or vmware
> should be safer, but in practice I will likely choose vserver because
> there is way less complexity involved and much better performance.

One more thing. You have to factor in the goals of the attacker. If
the attacker is only interested in another node in his botnet, he
won't care about breaking through to the "host", he may not even care
about obtaining root as he may already have sufficient access to run
whatever malware he wants to run. He may not even know (nor care) that
he's running his software inside a UML (userspace linux) process.

I also suspect that the goal of breaking through to the "host" would
be to gain access to the other virtual hosts on that machine, and it
might be easier to just attack those other virtual hosts directly, or
to attack the host itself directly, since it will likely run the same
versions of software anyway. While this is no excuse for not picking a
secure solution in the first place, I do not currently know of any
exploits in linux-vserver, and picking a virtualised solution for
marginally better security seems a backwards way to go about things.
There are other factors: performance, ease of use, features,
portability, that are much more important when making the decision on
what virtualisation technique to use. In other words, it might be
easier to spend a little more time hardening your virtual hosts (to
keep attackers out in the first place) and have a better performing
and easier to manage solution, rather than having a very secure but
incredibly hard to live with setup.

This is my opinion though, worth about 0.02 ZAR (which isn't much, but
at least more than 0.02 ZWD) :-P


--
To UNSUBSCRIBE, email to debian-security-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...