On Thursday 14 January 2010 05:43:07 Sthu Deus wrote: > Thank You for Your time and answer, randall: > >thanks to the fact it shares the same kernel with the host and all the > >guests, but this could be a disadvantage if you need a seperate kernel > >per guest. > > One of the reasons I would like to use virtualization is security... so, > how does using of a single kernel affect total security/separation - at my > view - it does not help in this view. Though I do not know how openvz or > xen work...
There is no memory protection in kernel space. This means that if there is a security issue with the (shared) kernel or one of the loaded modules, it can be used to attack all the guests and the host, irrespective of where it originated. -- for VServer (and OpenVZ?) With Xen/KVM/Qemu the guests are not fully protected from the host, but even kernel-level tasks/processes in the guests cannot affect the host unless there is a security issue with the specific virtualization technologies involved. This means that your exposure profile is a bit smaller with Xen/KVM/Qemu. The track record indicates that has resulted in fewer vulnerabilities in the past. That doesn't immediately mean they are the right choice. If users were being given shell access to the guest, or if the guest was going to be hosting a service that needs an "unusual" kernel module, or didn't drop permissions from root -- I'd want to use Xen/KVM/Qemu. If I'm just separating one or more Apache 2 instances from one or more Exim instances from one or more Dovecot instances from one or more Postgres instances... They all have fairly good security records, and they all do the majority of their work as a non-privileged user, so sharing the kernel would allow be to get better use out of my hardware. VServer or OpenVZ would make more sense. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
