L. V. Lammert <[EMAIL PROTECTED]> wrote: >> > If not, then security issues compound due to multiple guest OSs and >> each set >> > of inherent vulnerabilities. >> >>security issues and protections do not add up like numbers. > > Sure they do. If I'm running Windoze as a guest OS, there are hundreds or > thousands of possible vulnerabilities. If I'm runng OBSD as a guest OS, > guess what (I hope you don't have to??) - few to none. There is no way to > 'compound threat [interaction]', but that doesn't detract from the basic > truth - the lower the risk/number of vulnerabilities of the OS, the better > off you are. As a corollary, you might also say that there is no way to > improve the security of a server without improving the security of the OS.
This has *nothing* to do with VM security. The issue with VM security is that: 1. if any guest is compromised you all guests and the host are in danger. 2. if any user or admininstrator of a guest is malicious, all guests and the host is in danger. This threat is NOT because of any possible interaction (network/services etc.) between the guests and/or the host. It is because of a completely different attack vector, the VM system. The 'virtual hardware' that *all* host and guest OS systems implicitly trust to behave well can be subverted. You should NEVER trust a virtual machine to properly isolate the guests. It is a good approximation to having separate boxes, but it is NOT a security barrier. >> > No matter how you twist the logic, however, a VM provides a good level of >> > application domain security, from the standpoint that each set of domain >> > users and applications can only see the services provided within that >> > domain guest OS. >> >>The phrase "application domain security" is a cover-up statement that >>means "I have already decided to run the multiple things on one box >>because I am cheap, and I need to invent reasons why I can continue >>doing so". > > Huh?? Do you know what an application domain is? Guess not - here's a > definition: > > Application + Users + Access Method = Application Domain > > Examples: File/Print, httpd, DB, . . . > > The more discrete the security model (i.e. File/Print users are not valid > on the httpd server) the better. What you try to describe in a somewhat clumsy and round about way corresponds to moving different "applications" to their respective/isolated machines. This is actually a good thing to do for security. However, depending on the applications and the interactions between them, you may sometimes end up being with a more complex/less secure architecture. But this is not the point. What you fail to realize is that, when you try to implement this using a VM system, you actually break the isolation. The fact that well behaved applications and OS's work peacefully side by side under a VM setup DOES NOT mean that a malicious program and/or user is not able to break that isolation. Consider a web application login form with an SQL injection vulnerability. It validates the users and works perfectly fine %100 of the time, passes all tests. Denies incorrect passwords etc. UNTIL one malicious user decides to enter ' or 1=1;-- as his password. In a VM system the security of the *entire* system depends on the weakest link in only one of the OS's. To continue your example, you can install as many OpenBSD guests as you like. It takes one windows/linux whatever guest to break them all. That is why the protections do not 'add up'. Can
