On Tue, Dec 28, 2010 at 11:31:20AM -0800, Octave Orgeron wrote:
> 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. 

There is always some attack surface on the host.

> 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 
> [...]

In general it does seem safer to trust hardware than software, but it's
not necessarily the case that hardware is bug free, much less firmware.

>                                            [...] 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. 

In any analysis of the security of the _host_ you must assume that one
or more guests have been compromised.

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

Exactly.  Good management practices are needed no matter what, whether
you virtualize or not.

> 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.

Yes, quite.

> 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. 

Me too, but paired with best practices.

zones-discuss mailing list

Reply via email to