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 the 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, etc. 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 scenario. 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 would be very tricky. At best someone could get your data or cause the zone to reboot. 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 up 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: email@example.com 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 inefficient). 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. Nico -- _______________________________________________ zones-discuss mailing list firstname.lastname@example.org _______________________________________________ zones-discuss mailing list email@example.com