Security of Solaris zones vs VirtualBox virtual machines

It's clear that running an application inside a VirtualBox virtual machine gives at least some degree of security protection. Likewise putting servers in a zone do too. But how do these compare in terms of security risks? Is a zone better than a Virtual machine, or the other way around (my gut feeling is zones are better). A 'belt and braces' approach of running a virtual machine in a zone seems like a sensible approach, but is it? I'm specifically thinking about the best way to run the server for the Sage mathematics project http://www.sagemath.org/ This basically allow any user to create an account to use the maths software. (Try it at http://www.sagenb.org/ if you want ) Sage is based on python, and the user has all the python commands available to them. So effectively, it is basically as good as a shell account, as the user can execute any operating system command. Currently this runs on a Linux machine in a linux virtual machine. Sage will build on Solaris SPARC, so I will soon run a public server on a T5240. I'm wondering the best approach to take given the fact that this effectively gives a user a shell account. For confidential things, I'd run the server in such a way as it was not available to the public. By default, the Sage server can only be accessed from the local host, but this behavior can be changed, and obviously needs to be for a public server. Dave -- I respectfully request that this message is not archived by companies as unscrupulous as 'Experts Exchange' . In case you are unaware, 'Experts Exchange' take questions posted on the web and try to find idiots stupid enough to pay for the answers, which were posted freely by others. They are leeches.

Ian Collins wrote: > Dave wrote: >> It's clear that running an application inside a VirtualBox virtual >> machine gives at least some degree of security protection. >> >> Likewise putting servers in a zone do too. >> >> But how do these compare in terms of security risks? Is a zone better >> than a Virtual machine, or the other way around (my gut feeling is >> zones are better). > > Zones are secure from each other and the global zone. The root user in > a zone can't see any other zones on the system. Don't forget a VM has a > considerable overhead that a zone does not. But a root use in a virtual machine can't see any other machines to my knowledge, though I've hardly ever used virtual machines. I have a bit of a problem with my Solaris 10 install in a virtual machine on OpenSolaris, but that is another topic, and probably best put on the VirtualBox forums. But another argument would be that a zone shares the same kernel as a global zone, whereas a virtual machine has an entirely different operating system. But then I guess that is not true, as ultimately it does use the kernel of the global zone. I Just looked at my machine (1 3.33 GHz Xeon CPU, 4 cores, 8 threads) and see that each of two virtual machines is taking up 0.4% when idle, which is certainly not insignificant on what is quite a fast machine. >> A 'belt and braces' approach of running a virtual machine in a zone >> seems like a sensible approach, but is it? > > It can be done, but more for resource control than security. Would it not offer better security too? Someone would have to break out of a virtual machine, then a zone. >> I'm specifically thinking about the best way to run the server for the >> Sage mathematics project >> >> http://www.sagemath.org/ >> >> This basically allow any user to create an account to use the maths >> software. > > Use zones. They can all share the same sage install. But so can they when run as in a virtual machine. >> Currently this runs on a Linux machine in a linux virtual machine. > > Linux doesn't have zones, so this is probably a sensible approach. > I realise that. I was thinking of when this is hosted on Solaris. At the minute, Sage does not build fully on OpenSolaris, so I'd have to use Zones anyway. But when it does build on OpenSolaris, there will be a choice. -- I respectfully request that this message is not archived by companies as unscrupulous as 'Experts Exchange' . In case you are unaware, 'Experts Exchange' take questions posted on the web and try to find idiots stupid enough to pay for the answers, which were posted freely by others. They are leeches.

Dave wrote: > It's clear that running an application inside a VirtualBox virtual > machine gives at least some degree of security protection. > > Likewise putting servers in a zone do too. > > But how do these compare in terms of security risks? Is a zone better > than a Virtual machine, or the other way around (my gut feeling is zones > are better). There is more seperation in the Virtual Machine model over that of Zones. Thus, VM is more secure. But that isn't to say it is immune, just more immune. Namely because the threat vectors are reduced in a VM as opposed to a zone which shares much. > A 'belt and braces' approach of running a virtual machine in a zone > seems like a sensible approach, but is it? > > I'm specifically thinking about the best way to run the server for the > Sage mathematics project > > http://www.sagemath.org/ Basically security boils down to two things. The quality of the administrator and the application. If either fail the security, they both fail. You can have a secure application fail with poor admins and you can have failed security with a lousy app and good admin. > This basically allow any user to create an account to use the maths > software. > > (Try it at http://www.sagenb.org/ if you want ) Tehn it is subject to abuse. Users invoking account creation is a no no. Sort of like a child standing in front of a moving train bitching why they got smucked. > Sage is based on python, and the user has all the python commands > available to them. So effectively, it is basically as good as a shell > account, as the user can execute any operating system command. Then it should be chroot'ed. > Currently this runs on a Linux machine in a linux virtual machine. Still should be chroot'ed. > Sage will build on Solaris SPARC, so I will soon run a public server on > a T5240. I'm wondering the best approach to take given the fact that > this effectively gives a user a shell account. Even more reason to chroot it or look at it's model using good security practices. Face the obvious irationalities of using insecure practices head on. > For confidential things, I'd run the server in such a way as it was not > available to the public. By default, the Sage server can only be > accessed from the local host, but this behavior can be changed, and > obviously needs to be for a public server. > > Dave You can build a ship through the eye of a needle, or neck of a bottle. Just takes one little itty bitty hole.

Ian Collins wrote: > Dave wrote: >> It's clear that running an application inside a VirtualBox virtual >> machine gives at least some degree of security protection. >> >> Likewise putting servers in a zone do too. >> >> But how do these compare in terms of security risks? Is a zone better >> than a Virtual machine, or the other way around (my gut feeling is >> zones are better). > > Zones are secure from each other and the global zone. The root user in > a zone can't see any other zones on the system. Don't forget a VM has a > considerable overhead that a zone does not. True. The strenght of zones is lightweight seperation and efficiency, but at the cost that it isn't as seperate. If I starge a shared object/library in Zone B, Zone A will know about it. Not so in a VM where two seperate objects exist. Zones share a lot between zones that a VM does not. Thus a VM has to be more secure and independant than zones. >> A 'belt and braces' approach of running a virtual machine in a zone >> seems like a sensible approach, but is it? > > It can be done, but more for resource control than security. Even enforced resource control is better in VMs. >> I'm specifically thinking about the best way to run the server for the >> Sage mathematics project >> >> http://www.sagemath.org/ >> >> This basically allow any user to create an account to use the maths >> software. > > Use zones. They can all share the same sage install. > >> Currently this runs on a Linux machine in a linux virtual machine. > > Linux doesn't have zones, so this is probably a sensible approach. Linux can do VM and can so something very similar to zones, in fact was able to do it before Solaris. So cut the crap. But agree, they didn't call them zones. Zones are not all that high tech. A few control back challels to a chroot. Ok, some more sophistication in IP management and seperation via the liberaries and kernal, but it is in essense chroot on steroids. Don't get me wrong, on Solaris I see value in zones. Use them too. Some seperation is better than none, and often you get sissy vendors insisting on root because their security model is so bad, then zones are great. Have used them lots, and with containers for a full solution it is even better. Most Solaris admins don't even know the diffence between a zone and container. VMs are also easier considering the human operating the environment may not be sophisticated enough to do zones/containers properly.

Dave wrote: > Ian Collins wrote: >> Dave wrote: >>> It's clear that running an application inside a VirtualBox virtual >>> machine gives at least some degree of security protection. >>> >>> Likewise putting servers in a zone do too. >>> >>> But how do these compare in terms of security risks? Is a zone better >>> than a Virtual machine, or the other way around (my gut feeling is >>> zones are better). >> >> Zones are secure from each other and the global zone. The root user >> in a zone can't see any other zones on the system. Don't forget a VM >> has a considerable overhead that a zone does not. > > But a root use in a virtual machine can't see any other machines to my > knowledge, though I've hardly ever used virtual machines. I have a bit > of a problem with my Solaris 10 install in a virtual machine on > OpenSolaris, but that is another topic, and probably best put on the > VirtualBox forums. > > But another argument would be that a zone shares the same kernel as a > global zone, whereas a virtual machine has an entirely different > operating system. But then I guess that is not true, as ultimately it > does use the kernel of the global zone. > > I Just looked at my machine (1 3.33 GHz Xeon CPU, 4 cores, 8 threads) > and see that each of two virtual machines is taking up 0.4% when idle, > which is certainly not insignificant on what is quite a fast machine. > >>> A 'belt and braces' approach of running a virtual machine in a zone >>> seems like a sensible approach, but is it? >> >> It can be done, but more for resource control than security. > > Would it not offer better security too? Someone would have to break out > of a virtual machine, then a zone. > >>> I'm specifically thinking about the best way to run the server for >>> the Sage mathematics project >>> >>> http://www.sagemath.org/ >>> >>> This basically allow any user to create an account to use the maths >>> software. >> >> Use zones. They can all share the same sage install. > > But so can they when run as in a virtual machine. > >>> Currently this runs on a Linux machine in a linux virtual machine. >> >> Linux doesn't have zones, so this is probably a sensible approach. >> > > I realise that. I was thinking of when this is hosted on Solaris. > > At the minute, Sage does not build fully on OpenSolaris, so I'd have to > use Zones anyway. But when it does build on OpenSolaris, there will be a > choice. Solaris and OpenSolaris both do zones and both will operate in a VM. But, I don't believe you can have a Soalris zone in an OpenSolaris as he guest, for that, VM them both.

Canuck57 <Canuck57@nospam.com> wrote: > But, I don't believe you can have a Soalris zone in an OpenSolaris as he > guest, for that, VM them both. You can, actually, though it's new. See: http://hub.opensolaris.org/bin/view/Community+Group+on/2009102201 -- Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/

Canuck57 wrote: > Ian Collins wrote: >> Dave wrote: >>> It's clear that running an application inside a VirtualBox virtual >>> machine gives at least some degree of security protection. >>> >>> Likewise putting servers in a zone do too. >>> >>> But how do these compare in terms of security risks? Is a zone better >>> than a Virtual machine, or the other way around (my gut feeling is >>> zones are better). >> >> Zones are secure from each other and the global zone. The root user >> in a zone can't see any other zones on the system. Don't forget a VM >> has a considerable overhead that a zone does not. > > True. The strenght of zones is lightweight seperation and efficiency, > but at the cost that it isn't as seperate. If I starge a shared > object/library in Zone B, Zone A will know about it. Not so in a VM > where two seperate objects exist. If you what? > Zones share a lot between zones that a VM does not. Thus a VM has to be > more secure and independant than zones. In theory yes, but in practice? Zones are designed to be secure. >>> A 'belt and braces' approach of running a virtual machine in a zone >>> seems like a sensible approach, but is it? >> >> It can be done, but more for resource control than security. > > Even enforced resource control is better in VMs. Is it? Can you change the available resources of a running VM? >>> I'm specifically thinking about the best way to run the server for >>> the Sage mathematics project >>> >>> http://www.sagemath.org/ >>> >>> This basically allow any user to create an account to use the maths >>> software. >> >> Use zones. They can all share the same sage install. >> >>> Currently this runs on a Linux machine in a linux virtual machine. >> >> Linux doesn't have zones, so this is probably a sensible approach. > > Linux can do VM and can so something very similar to zones, in fact was > able to do it before Solaris. So cut the crap. But agree, they didn't > call them zones. What crap? > Zones are not all that high tech. A few control back challels to a > chroot. Ok, some more sophistication in IP management and seperation > via the liberaries and kernal, but it is in essense chroot on steroids. Do you have a spell checker? A zone is lot more than a chroot on steroids. > Don't get me wrong, on Solaris I see value in zones. Use them too. Some > seperation is better than none, and often you get sissy vendors > insisting on root because their security model is so bad, then zones are > great. Have used them lots, and with containers for a full solution it > is even better. Most Solaris admins don't even know the diffence > between a zone and container. Most probably don't have cause to. > VMs are also easier considering the human operating the environment may > not be sophisticated enough to do zones/containers properly. How can something that requires a full install and individual patching be easier than something that can be created in a few minutes (even less with clones)? -- Ian Collins

Ian Collins wrote: > Canuck57 wrote: >> Ian Collins wrote: >>> Dave wrote: >>>> It's clear that running an application inside a VirtualBox virtual >>>> machine gives at least some degree of security protection. >>>> >>>> Likewise putting servers in a zone do too. >>>> >>>> But how do these compare in terms of security risks? Is a zone >>>> better than a Virtual machine, or the other way around (my gut >>>> feeling is zones are better). >>> >>> Zones are secure from each other and the global zone. The root user >>> in a zone can't see any other zones on the system. Don't forget a VM >>> has a considerable overhead that a zone does not. >> >> True. The strenght of zones is lightweight seperation and efficiency, >> but at the cost that it isn't as seperate. If I starge a shared >> object/library in Zone B, Zone A will know about it. Not so in a VM >> where two seperate objects exist. > > If you what? If I starved. As in consumbed all the resources.... >> Zones share a lot between zones that a VM does not. Thus a VM has to >> be more secure and independant than zones. > > In theory yes, but in practice? Zones are designed to be secure. Yes, but the fact remains there are more threat vectors. Namely the who API. >>>> A 'belt and braces' approach of running a virtual machine in a zone >>>> seems like a sensible approach, but is it? >>> >>> It can be done, but more for resource control than security. >> >> Even enforced resource control is better in VMs. > > Is it? Can you change the available resources of a running VM? Many resources can't be changed at run time in Solaris without rebooting the VM either, your point? >> Zones are not all that high tech. A few control back challels to a >> chroot. Ok, some more sophistication in IP management and seperation >> via the liberaries and kernal, but it is in essense chroot on steroids. > > Do you have a spell checker? Nope, I rely on your lip. Hadn't had any coffee yet. > A zone is lot more than a chroot on steroids. I don't see how. Other than the OS and liberies are altered for more advanced support of it, it is. >> Don't get me wrong, on Solaris I see value in zones. Use them too. >> Some seperation is better than none, and often you get sissy vendors >> insisting on root because their security model is so bad, then zones >> are great. Have used them lots, and with containers for a full >> solution it is even better. Most Solaris admins don't even know the >> diffence between a zone and container. > > Most probably don't have cause to. Not any more. People are moving away from Solaris. >> VMs are also easier considering the human operating the environment >> may not be sophisticated enough to do zones/containers properly. > > How can something that requires a full install and individual patching > be easier than something that can be created in a few minutes (even less > with clones)? Simple. With zones you have to remember patches can affect all zones if they are at all sparce. Real PITA when you have 20 zones and 1 app owner will not let you patch as it affects their app. So unless the zones are whole root zones, well, side effects occur. In a VM, patch them as the opportunity exists using snapshots as your backout. Much cleaner and less complex.

Canuck57 wrote: > Ian Collins wrote: >> Canuck57 wrote: >>> Ian Collins wrote: >>>> Dave wrote: >>>>> It's clear that running an application inside a VirtualBox virtual >>>>> machine gives at least some degree of security protection. >>>>> >>>>> Likewise putting servers in a zone do too. >>>>> >>>>> But how do these compare in terms of security risks? Is a zone >>>>> better than a Virtual machine, or the other way around (my gut >>>>> feeling is zones are better). >>>> >>>> Zones are secure from each other and the global zone. The root user >>>> in a zone can't see any other zones on the system. Don't forget a >>>> VM has a considerable overhead that a zone does not. >>> >>> True. The strenght of zones is lightweight seperation and efficiency, >>> but at the cost that it isn't as seperate. If I starge a shared >>> object/library in Zone B, Zone A will know about it. Not so in a VM >>> where two seperate objects exist. >> >> If you what? > > If I starved. As in consumbed all the resources.... Ah. In that case, you would apply resource controls to the zone. >>> Zones share a lot between zones that a VM does not. Thus a VM has to >>> be more secure and independant than zones. >> >> In theory yes, but in practice? Zones are designed to be secure. > > Yes, but the fact remains there are more threat vectors. Namely the who > API. Is that still current? >>>>> A 'belt and braces' approach of running a virtual machine in a zone >>>>> seems like a sensible approach, but is it? >>>> >>>> It can be done, but more for resource control than security. >>> >>> Even enforced resource control is better in VMs. >> >> Is it? Can you change the available resources of a running VM? > > Many resources can't be changed at run time in Solaris without rebooting > the VM either, your point? My point was I hadn't had any coffee yet..... Even so, resource controls on zones are more flexible than those for a VM. They also have the advantage of centralised management. See http://blogs.sun.com/JeffV/entry/layered_virtualization for an example of VMs within zones, the best of both worlds? >>> VMs are also easier considering the human operating the environment >>> may not be sophisticated enough to do zones/containers properly. >> >> How can something that requires a full install and individual patching >> be easier than something that can be created in a few minutes (even >> less with clones)? > > Simple. With zones you have to remember patches can affect all zones if > they are at all sparce. Real PITA when you have 20 zones and 1 app > owner will not let you patch as it affects their app. So unless the > zones are whole root zones, well, side effects occur. True, there's always a down side to shared resources. The solution is to use a mix of whole and sparse root zones. Some applications will only run in a whole root zone. > In a VM, patch them as the opportunity exists using snapshots as your > backout. Much cleaner and less complex. Again, using your own example, this can be a PITA if you have 20 VMs! Twenty zones on a quad core with 16GB of RAM is manageable, twenty VMs would be interesting! There's no escaping the fact that N kernel instances and installs will consume a lot more machine resources than N zones. -- Ian Collins

In article <HpbQm.5816$y%5.5700@newsfe03.iad>, Canuck57 <Canuck57@nospam.com> writes: > Most Solaris admins don't even know the diffence > between a zone and container. Neither does Sun. The definitions of the two changed too many times and is specified too inconsistently for there to be any meaningful distinction anymore. -- Andrew Gabriel [email address is not usable -- followup in the newsgroup]

On 2009-11-28 09:47:04 +0000, Dave <foo@coo.com> said: > But how do these compare in terms of security risks? Is a zone better > than a Virtual machine, or the other way around (my gut feeling is > zones are better). A VM is better, or at least has a smaller number of possible places where bad things can happen. Because zones share a kernel, anything which can cause some kind of compromise to that kernel will compromise all the zones on it. A similar compromise on a VM-based system would require a compromise of the hypervisor, which should be much harder.

On Sun, 29 Nov 2009 12:56:44 +0000 Tim Bradshaw <tfb@tfeb.org> wrote: > On 2009-11-28 09:47:04 +0000, Dave <foo@coo.com> said: > > > But how do these compare in terms of security risks? Is a zone > > better than a Virtual machine, or the other way around (my gut > > feeling is zones are better). > > A VM is better, or at least has a smaller number of possible places > where bad things can happen. Because zones share a kernel, anything > which can cause some kind of compromise to that kernel will > compromise all the zones on it. A similar compromise on a VM-based > system would require a compromise of the hypervisor, which should be > much harder. Given that most x86 hypervisors are based on Linux, the problem is not much different from compromising a Solaris kernel. -- Stefaan A Eeckels -- Effective cryptography is not about strong cryptographic algorithms. It is instead about key management. -- Russell Nelson

On 2009-11-29 14:41:41 +0000, Stefaan A Eeckels <hoendech@ecc.lu> said: > Given that most x86 hypervisors are based on Linux, the problem is not > much different from compromising a Solaris kernel. It is enormously different. The interface a virtual machine has to the hypervisor is via the machine the hypervisor is emulating. So to compromise the hypervisor I'd need to try and execute some kind of instruction sequence which caused the hypervisor to do something bad. The interface a zone has to the Solaris kernel is almost the entire Solaris system call interface. I suspect that a zone which does not intend to compromise the underlying OS but merely to establish some channel of communication through which it could leak data to another zone would also have a much easier time than a VM instance trying to do an equivalent thing - there are fairly obvious tricks involving PIDs. --tim

On 2009-11-29 14:57:31 +0000, Tim Bradshaw said: > So to compromise the hypervisor I'd need to try and execute some kind > of instruction sequence which caused the hypervisor to do something bad. Such things are possible - see the recent observations about the Nehalem CPU bugs which only affect a Windows hypervisor. I don't know how you'd exploit that... -- Chris

Ian Collins wrote: > Canuck57 wrote: >> Ian Collins wrote: >>> Canuck57 wrote: >>>> Ian Collins wrote: >>>>> Dave wrote: >>>>>> It's clear that running an application inside a VirtualBox virtual >>>>>> machine gives at least some degree of security protection. >>>>>> >>>>>> Likewise putting servers in a zone do too. >>>>>> >>>>>> But how do these compare in terms of security risks? Is a zone >>>>>> better than a Virtual machine, or the other way around (my gut >>>>>> feeling is zones are better). >>>>> >>>>> Zones are secure from each other and the global zone. The root >>>>> user in a zone can't see any other zones on the system. Don't >>>>> forget a VM has a considerable overhead that a zone does not. >>>> >>>> True. The strenght of zones is lightweight seperation and >>>> efficiency, but at the cost that it isn't as seperate. If I starge >>>> a shared object/library in Zone B, Zone A will know about it. Not >>>> so in a VM where two seperate objects exist. >>> >>> If you what? >> >> If I starved. As in consumbed all the resources.... > > Ah. In that case, you would apply resource controls to the zone. But why not just set and forget for the whole machine? I hate getting into tissy fights with applications people over shared memory, disk etc. I like it partitioned off the top right off. VMs are better this way, I can nail them down up front and get it in ink. >>>> Zones share a lot between zones that a VM does not. Thus a VM has >>>> to be more secure and independant than zones. >>> >>> In theory yes, but in practice? Zones are designed to be secure. >> >> Yes, but the fact remains there are more threat vectors. Namely the >> who API. > > Is that still current? Yep. It is a fact, there are more avenues to compromise in a zone than a VM, although I grant both have them. I will not say you can't escalate from a VM to the host, just that it is a whole lot more probablt of going zone to the host. >>>>>> A 'belt and braces' approach of running a virtual machine in a >>>>>> zone seems like a sensible approach, but is it? >>>>> >>>>> It can be done, but more for resource control than security. >>>> >>>> Even enforced resource control is better in VMs. >>> >>> Is it? Can you change the available resources of a running VM? >> >> Many resources can't be changed at run time in Solaris without >> rebooting the VM either, your point? > > My point was I hadn't had any coffee yet..... Even so, resource > controls on zones are more flexible than those for a VM. They also have > the advantage of centralised management. Tehy are, I agree. But given they are not on by default, most just create zones and don't get proper containers, and is always an afterthought. And the fights break out when you do. > See http://blogs.sun.com/JeffV/entry/layered_virtualization for an > example of VMs within zones, the best of both worlds? With the effort, yes. And when I do use zones, I do. But know most of my peer admins don't. Often the zone is created in a way the machine is theres, no limits. >>>> VMs are also easier considering the human operating the environment >>>> may not be sophisticated enough to do zones/containers properly. >>> >>> How can something that requires a full install and individual >>> patching be easier than something that can be created in a few >>> minutes (even less with clones)? >> >> Simple. With zones you have to remember patches can affect all zones >> if they are at all sparce. Real PITA when you have 20 zones and 1 app >> owner will not let you patch as it affects their app. So unless the >> zones are whole root zones, well, side effects occur. > > True, there's always a down side to shared resources. The solution is > to use a mix of whole and sparse root zones. Some applications will > only run in a whole root zone. Yep. Understand that. Especially the poorly written ones, they like the whole root zone. >> In a VM, patch them as the opportunity exists using snapshots as your >> backout. Much cleaner and less complex. > > Again, using your own example, this can be a PITA if you have 20 VMs! The practical nature of the business owners often dictates you will almost never get all 20 zones at once, then VM is better as you can do them as they become available. But agree, if they are all sparse, and you can get all the zones at once, it is a whole lot more efficient. But tell that to a non-technical management twirp. > Twenty zones on a quad core with 16GB of RAM is manageable, twenty VMs > would be interesting! There's no escaping the fact that N kernel > instances and installs will consume a lot more machine resources than N > zones. Agreed. My point is both have their places. One should not blindly choosse either one over the other and consider both based on your knowledge of the actual environment it operates in. And include political and ractical issues. Zones work great in environments where the applications don't own the iron. It allows IT the flexability to assign resources as needed. And so long as they don't over extend the the things (VM or zones), works well. I like zones, for doing Solaris Sparc, my preferred way. For Intel... I tend towards VMs as most shops already have them and the expertise. Your average Intel shop is void in knowledge of zones and VMs are a big challenge for many as it is. Being on the applications size once though. The zone on a T2000 or something. They put 20 whole roots on it. Pig assed slow, while they saved money on iron, they lost 9 times that in meeting to discover they grossly over extended it and that is why the users found the performance unacceptable. And the admins were uncooperative on the discovery as the shared services manager wanted to cover their asses. The next system was dictated to them on my recommendation as no zones, Sparc IV procs and it ran well.

Tim Bradshaw wrote: > On 2009-11-28 09:47:04 +0000, Dave <foo@coo.com> said: > >> But how do these compare in terms of security risks? Is a zone better >> than a Virtual machine, or the other way around (my gut feeling is >> zones are better). > > A VM is better, or at least has a smaller number of possible places > where bad things can happen. Because zones share a kernel, anything > which can cause some kind of compromise to that kernel will compromise > all the zones on it. A similar compromise on a VM-based system would > require a compromise of the hypervisor, which should be much harder. And I have had that happen where some shared libraries got stuck in a zone, and the application owner said tough, my zone is working great...you are not going to get the reboot. Ends up to be a political fiasco with a tech admin wishing he/she worked elsewhere. If it were a VM, just reboot the offender, case closed.

On 2009-11-29 17:50:44 +0000, Canuck57 <Canuck57@nospam.com> said: > Ends up to be a political fiasco with a tech admin wishing he/she > worked elsewhere. If it were a VM, just reboot the offender, case > closed. Similar things apply with patching-related outages and so on on zone-based systems. It's imortant to design things which use zones for maintainability, and if you don't you can get seriously screwed later on.

Similiar Articles:

Is there a way to determine the host machine from within the local ...
That would be a security risk. -- Dick ... Or do "virtual" interfaces have ... unix.solaris... zonename in Solaris 10 report the machine name that is the global zone ...

[comp.publish.cdrom] CD-Recordable FAQ, Part 1/4 - comp.publish ...
Archive-name: cdrom/cd-recordable/part1 Posting-Frequency: monthly Last-modified: 2008/10/09 Version: 2.71 Send corrections and updates to And...

Oracle Solaris 10 VM Downloads
Security Alerts Customer Replaceable Units ... variety of links to Oracle Solaris Virtual Machine ... Database in an Oracle Solaris Zone; Oracle VM Virtualbox Oracle Solaris 10 ...

zone hung in shutting_down status - Der Keiler UNIX: The source ...
(comp.unix.solaris) Re: Security of Solaris zones vs VirtualBox virtual machines... Because zones share a kernel, anything which can cause some kind of compromise to that ...

7/30/2012 9:39:31 AM