L. V. Lammert: >At 12:08 PM 10/25/2007 -0400, Stuart VanZee wrote: > >>The reason that people are going to #2 is that, if you are concerned about >.security, that is the optimal way of setting things up. One box, one >>task. That is true "separation". In this light, the question of if #3 is >>more secure than #1 is truely a moot point. BUT.... To argue that a >>VM running a service is more secure than a system running that same service >>is rather weak... if the service can be exploited, it can be exploited. > >No, you need to read the last two discussion replies - they, at least, make >sense. > >Isolating ONE part of the discussion just posts extra traffic on the list. > >>Give me root access to a box (from an exploit or an account, don't matter) >>and I can crash the bitch. > >Very true, but is completely offtopic from the OP, but, then, that has been >forgotten long ago. I think everybody can agree that issues within a VM >configuration can significantly ADD security risks, *especially* if you're >running an OS that are not secure by default. > >The original discussion of VMs providing security for an application >domain, however (per the summary posted about an hour ago), has nothing to >do with this level of vulnerability. Providing separation of application >domains in an enterprise adds an excellent level of security for the >application users and admins. The fact that VM systems compound >vulnerabilities, though very significant, is not an issue related to the >OP. The fact that running those application domain on separate hardware to >provide better security is also a option, but, again, not related to the >OP. The fact that OBSD does not operate in that enterprise space, choosing, >instead, to focus on core services, is again, not related to the OP. > >All of these tangential discussions have added a lot of good information to >the list archives, thanks to all! > > Lee >
Quite frankly, I tire of your dumb-ass attitude. This was VERY ON TOPIC. Security for the "applecation domain" is a function of the level of vulnerability in the VM. If the VM is vulnerable, the "application domain" does not have an ice cubes chance in hell of being secure. So security of the VM is VERY on topic. Because you stated: "Virtualization provides near absolute security" The fact that a guest is running in a virtual environment provides NO extra protection to the users or the applications of THAT INDIVIDUAL GUEST. If it can be broken, it can be broken. PERIOD. I don't give a rats ass if they are running in a VM, not in a VM, or on a system made out of steaming piles of dog shit. What can be broken, can be broken. Add to that, if you have a virtualization server with a number of guests on it and even ONE of those guests get rooted, that ONE guest gives the interloper a much better platform to launch attacks against the other guest systems than if each guest was instead implemented on it's own hardware and secured separately. This is also on topic because make no mistake, that is the proper metric for this argument. Compairing each service being run in it's own guest to all services running on one system is not a proper comparison because it assumes that that is the normal accepted practice when security is of concern (Security is the topic that you are arguing after all). All it takes is some missed bit of bad code in any one of hundreds of "virtual" hardware services that the VM must provide to the guest operating systems and the rest of the guests are vulnerable. Even if they are systems that aren't usually vulnerable to attack if they are used stand alone, they now have to worry about not only attacks from the outside network, they have to worry about attacks from the VM stack itself because, as we have seen throughout the years, if it exists, some bad guy somewere will try to use it. If it is not perfect (and nothing is) sooner or later, some bad guy somewere will succeed. I have heard many people who are considered experts in the field of security say over and over again... (to the faithful) say it with me... Simplicity is the path to security. Complexity is the path to (security) RUIN. Virtualization adds VERY much to the complexity of a system. Argue with that and you might as well try to argue that Flan is good food (no offence intended to those who actually like flan... ew...).
