Hi!

I think you are missing the point about x86 hardware being a mess.  Theo
made an excellent point about the architecture itself having so many
filthy quirks.  If a VM is compromised through any means, that attacker
can now leverage the dirty architecture to bypass the hypervisors
(supposed) isolation techniques.  If the attacker can utilize the VM to
infiltrate the hypervisor, even more damage can be done.

The entire point is this:  You cannot increase security by putting more
things on one physical server.  You can run your different 'Application
Domains' on different physical servers.  That is much closer to security
than through obscurity.

-Brian

L. V. Lammert wrote:
quoted text
> At 03:31 PM 10/24/2007 -0600, Theo de Raadt wrote:
>> > Certainly there is a small, compount risk increase due to multiple OS
>> > images involved, but the OS images must be analyzed independently
>> FIRST,
>> > and THOSE risks addressed.
>>
>> Certainly you pulled that assesment out of your ass.
>
> I thought it was obvious, .. but I know you have beter things on your
> mind. I DO mind you liking my ass, however - ain't gonna happen.
>
>> > **IF** OBSD were available as a host OS, that would be good security.
>>
>> You must be more qualified with regards to the actual code than I am
>> because I flat out don't believe this at all.
>
> Believe what? OBSD is secure? I thought you were proud of the project?
> Sheesh! If our leader doesn't believe OBSD is secure, we ALL better be
> running for cover. Linux, anyone?
>
> If you're saying that OBSD will never be modified to run AS a XEN
> hypervisor, that's probably a true statement. No need to corrupt a
> decent OS with GPL s/w.
>
>> > 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.
>
>> > 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.
>
>         Lee

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]