I would argue that even with VMware you have certain risks to consider when 
you're depending on an underlining kernel or hypervisor that can actually see 
into a guest memory or I/O space. And while there are add-ons like vSafe for 
VMware, there are other products that allow you to examine and even record 
what's happening in your guests. So there has to be methods for attacks if 
someone can gain access to the console vm. 

Para-virtualization like LDoms and LPARs are safer in my opinion by having the 
hypervisor in the firmware and depending more on hardware features. Like with 
LDoms, the CPUs and memory blocks are partitioned at the hypervisor layer in 
iLOM by loading machine descriptions. And while the Logical Domain Channels 
(LDCs) use shared memory for networking and disk I/O, it's again at the iLOM 
level with the hypervisor. You do have to protect the control and service 
domains to prevent someone from snooping network traffic through the virtual 
switches (VSWs). This is pretty easy to do with LDoms, just have them connected 
to a private management network and access restricted with SSH, LDAP, RBAC, 
Plus you'd want to connect your iLOM to a private management network as well, 
since that's the real point of failure in LDoms. Of course the question here 
would be if it's possible to hijack a guest and send LDC messages that could 
corrupt data or cause performance issues in a denial-of-service type of 

Regardless of what virtualization technology you use, you still have to protect 
your VMs using firewalls, intrusion detection, restricted access, accounting, 
auditing, etc. 

For containers, I think that the least privilege model helps out a lot in this 
space by restricting rights. With the granular resource controls, you can even 
prevent exhaustion of resources. There are plenty of security blueprints that 
talk about protecting the global zone and having the non-global zones on 
separate networking for things like DMZs. While having a single kernel is a 
point of failure for containers, if you knock out the vmkernel in VMware, you 
knock out everything. So is it really all that different? I think it comes down 
to the amount of effort that's required to attack a virtualized environment and 
bring it down. VMware would require compromising a VM and then either 
compromising the other VMs or the vm console, which would probably be a matter 
of standard OS hacking or compromising the APIs in VMware. Containers would 
require compromising a zone and then trying to escalate privileges which would 
be very difficult with the least privileges model, and faulting the kernel 
be very tricky. At best someone could get your data or cause the zone to 
But the rest of the zones and the global zone would probably be unaffected. 

BTW, even if you reboot your control domain in LDoms, your guests will remain 
and wait until the virtual I/O services return, kind of a nifty feature of 
having the hypervisor in the firmware.

At the end of the day, I'd bank my money on Containers and LDoms. Just have to 
use common sense on configuring them and securing them to reduce your security 
risks down to point where someone would have to know the Solaris kernel or the 
UltraSPARC hypervisor really well. 

Octave J. Orgeron
Solaris Virtualization Architect and Consultant
Web: http://unixconsole.blogspot.com
E-Mail: unixcons...@yahoo.com

----- Original Message ----
From: Nicolas Williams <nicolas.willi...@oracle.com>
To: Orvar Korvar <knatte_fnatte_tja...@yahoo.com>
Cc: zones-discuss@opensolaris.org
Sent: Tue, December 28, 2010 12:41:42 PM
Subject: Re: [zones-discuss] "Security through virtualization is a failure":

On Tue, Dec 28, 2010 at 06:45:00AM -0800, Orvar Korvar wrote:
> "....My advice to the paranoid regarding regarding VMs would be to disable
> extensions allowing the guest broader communication channels to services
> on the host..."
> I didnt understand. You mean, for each local zone: disabling ssh and
> all other connections to the outside world?

No, I mean don't enable too many features that involve the guest talking
to the host.  For example, in VBox, don't enable display sharing, nor
file sharing between the gues and the host.

In LDoms-type architectures I'd avoid the use of shared memory for
inter-guest, cross-backplane communications (this might mean having to
use NICs to communicate between the guests, which is rather

In Zones this pinciple is harder to apply because the g-z's kernel is
shared with all guests.  For example, not using VNICs isn't likely to
reduce the attack surface all that much.  But g-z user-land services for
ngzs could still be avoided.

zones-discuss mailing list

zones-discuss mailing list

Reply via email to