seems?

to whom?

to people who never wrote a line of code and don't understand how

things work?
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Virtualization provides near absolute security - DOM0 is not visible to

the user at all, only passing network traffic and handling kernel calls.

The security comes about in that each DOMU is totally isolated from the

the others, while the core DOM0 is isolated from any attacks.
There is also a big benefit when maintaing VM images - restoring a VM in

the case of corruption/attach/whatever is as simple as reloading a copy of

that image and connecting to system data on the local SAN.
Irrespective of the guest OS, there is good security between the

virtualized machines. Running OBSD as the guest OS provides the best of

both worlds, and it would be great if OBSD would run paravirtualized for

the best performance, but apparently nobody has a need for that

Nobpdy has to write any code to understand that - the secuity benefits

are ovbious to everyone from the PHBs to the admins. Of course, this is

most obvious in 'enterprise space', which is pretty far removed from the

typical OBSD world.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

In theory, you're correct.
In practice there are (at least) four questions which all must be

answered in the affirmative for this to be true:
1) Does the hardware architecture provide all of the hooks needed to

   implement virtualization?

2) Does the specific hardware correctly implement that architecture?

3) Does the virtualization software architecture properly implement

   virtualization?

4) Does the specific software correctly implement that architecture?
Answering any of those questions takes both a lot of work and, all too

often, access to information which is not generally available.  And if

any of the answers is 'no', the security of anything run under that

virtualization may be fatally compromised -- no matter how secure that

software may be when run standalone.
	Dave
--

Dave Anderson

<dave@daveanderson.com>

And this increases the security for the hosted (DomU) OS's exactly how?

You know, the BIOS is safe from attack too, at least as much as Dom0

is, and each machine on my network is, amazingly enough, also totally
Actually they aren't. What are the "obvious" security benefits? I'm

not saying there aren't benefits, just that I can't see any obvious

security benefits.
---

Lars Hansson

dream on.

that is what marketing wants to tell you.

in fact the isolation is incredibly poor.
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Sorry, the kernel hacking world is pretty far removed from 'enterprise

reality' <not that it's a bad thing - I often wish it were that simple>!!

In reality, there are tons of SMEs out there using MS Crap and other risky

software! The few security risks you cite for XEN are negligable by comparison.
Anything we can do to increase security, *including* setting up VMs (of any

flavor) is an improvement [that also increased hardware utilization].
         Lee

This last sentence is such a lie.  
The fact is that you, and most of the other fanboys, only care about

the [that also increased hardware utilization].  The yammering about

security is just one thing -- job security.  You've got to be able to

sell increased harwdare utilization in a way that does not hang you up

at the end of the day.
If people were saying:
	"Yes, it increased hardware utilization, and the nasty

	security impact might be low"
it would be fine.
But instead we have many uneducated people saying:
       "Yes, it increased hardware utilization, and it improved security too".
And that's complete and utter bullshit.

That depends on your viewpoint. There certainly may be some issues at the

OS level (which have been mentioned previously), however the majority of VM

applications benefit from security *isolation*, which has nothing to do

with security issues of the underlying OS, and that was the viewpoint I was

communicating.
For example, say you have three departments within a company: Marketing,

Development, Production. Allowing each department to maintain their own

server instance allows each department to have their own users, home

directory configuration, samba (possibly) network config & authorization,

separate file/print sharing domain, etc.
That is simple not doable with a single OS, yet with a reasonable priced of

h/w all can be maintained on one platform.
Perhaps more correctly:
         "Yes, it increased hardware utilization, and it improves

security/isolation between different work domains"
However few outside this community would have any comprehension of the

difference.
         Lee

This is called a "tangent." It has nothing to do with the reliable

security aspects of segmentation via virtualization.
The point you may try making here is that by segmenting your servers

into individual instances for each department, rather than having all

departments on a shared server, an attack against one department's

server doesn't affect the other. _In theory_, that's true. _In

reality_, this is only a surface assumption as without strong

segmentation at the network level to separate a compromised department

from another department, the attacker can compromise the other

departments' servers from the first one and have the same result.
Remember back 10-ish years ago when VLANs were being touted as the

ultimate network segmentation technology by marketers of managed

switches? And now everyone hopefully realizes that while VLANs

technically do offer network segmentation, it's really rudimentary and

cannot be relied on for truly reliable security due to various layer 2

attacks that subvert them? Or that if there's any communication

conduits that allows one to talk to the other, that can simply be

leveraged to subvert security? That simply segmenting networks with

VLANs can't be considering to fully isolate them? That when people

want solid assurance of isolating hosts they often still air gap them?

That is the point that VM-based segmentation is at right now.
This isn't supposed to be a remedial lesson on network architectures;

you're supposed to pick up the parallels to separation of

systems/applications via VM technology. VM based segmentation or

isolation (whichever buzzword you prefer ATM) is fine on the surface

level, but please stop acting as if it is a security measure. People

much smarter than $you are blowing that idea out of the water right

now.
http://www.intelguardians.com/ndss.pdf

http://www.pauldotcom.com/2007/08/27/pauldotcom_security_weekly_int_1.html

http://www.cutawaysecurity.com/blog/archives/170 (read Ed Skoudis'

comment on this post)
DS

err, that is a very bad comparision. I am not aware of any "layer2

attacks" (you probably mean vlan hopping things) that work against any

half reasonable configured switch from the last 10 years.

heck, these days even everybody except cisco has sane defaults.

(well, I dunno about those cheap switches, admittedly)
this comparision is wrong on another basis: vlans are dead simple, just

a tiny and simple header before the ethernet segment. virtualization is 
without bad config errors (that are getting harder to make, except on

cisco, they got the semantics completely wrong and stupid defaults) and

usedcorrectly, yes, VLANs perfectly isolate network segments.
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

On Oct 24, 2007, at 4:16 PM, Henning Brauer <lists-openbsd@bsws.de>  
Why does this continue to pop up in misc@ every year?
---

Jason Dixon

DixonGroup Consulting

http://www.dixongroup.net

I agree, the key is the reasonably configured part. Vlan hopping, STP

attacks, etc. and Cisco particularly. Even if Cisco is (now) one of

the few to not have sane defaults, they're common enough for it to be

a concern. And consider all the devices (even from good vendors) that

are behind on firmware (where the defaults weren't yet sane).
Yeah, I was commenting mainly on the flawed "silver bullet" mentality

that some LAN admins have with the "if I have VLANs, my hosts are

automatically perfectly segmented" mindset rather than the

implementation/design itself. Sadly, the average LAN admin these days,

at least in the states, isn't smart enough to understand the nuances.
DS

I'm curious about this.  Do you have any pointers I can go look up?  Thanx!
--

"This officer's men seem to follow him merely out of idle curiosity."

-- Sandhurst officer cadet evaluation.

> The security benefits are at the application level, *NOT* at the OS level.
What hogwash.
The security benefits are at the "ability to buy a steak for dinner"

level.
You've already made the decision to decrease security by

de-compartmentalizing onto one physical box, so you are just thrilled

with the ability to decrease security more by de-compartmentalizing

the software further.

Quite the opposite!! A VM provides a safe, sane, decently

compartmentalized way to run a specific application domain. It's obvious

we have different viewpoints, but both are equally valid - your's from the

OS, mine from the application.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

You have failed to satisfactorily explain why running a specific application

in a VM is more secure then running it in a standard OS. It's nonsense that

you think it's more secure that way. It saves a lot of money, yes -- you

don't necessarily want a separate box just to run an application - but

that's not the debate here. The debate is about security, and I'm amazed

that you think a virtual environment is somehow more secure then a dedicated

non-virtual environment.

Like I mentioned earlier, security has several contexts.  He could well

be talking about job security, if he's the only one who knows how it is

set up.
While probably the least, or at least one of the least, technically

skilled people here, I did spend a lot of time this spring reading up on

virtualization and paravirtualization.
*My* conclusion was that the main, and maybe only, place that

virtualization can help is in restoration after a compromise, assuming

one makes snapshots, etc.  That and maybe load balancing / resource

usage to help uptime.  Keeping people out, or data in?  Nah.  Probably

no more than spreading out over different architectures.
However, adding an extra layer otherwise made little sense and is

probably not more effective than sysjail or something like that.

Paravirtualization, *might* help in some cases, since the guest os must

be ported, but again the host is native and once you reach the host...
-Lars

My analogies usually go to custard, but I'll try this one.
You are in charge of getting four ambassadors to a meeting.  As well

as making sure they are happy and fed, you are in charge of their

security.
All four are hated in their home countries and you know their are

people wanting to kill them.
Some of your choices:
1. One car per ambassador.  If one gets taken out, at least three are

still OK (guess you would still be out of a job, though - so not a

perfect analogy.)  Obviously means four cars, four drivers, so more

expensive.  And more things to juggle.  And if you are very unlucky,

all four could still get taken out (but obviously means a lot of bad

guys being lucky.)  It takes four attacks to wipe you out.
2. All four in one car.  If any assassin tries to take out an

ambassador, chances are the rest are toast as well.  But only one

car / one driver - so less expensive.  It takes one attack to wipe

you out.
3. All four in one car - but you start to worry about the risk, so

you start adding stuff to the car.  Bigger engine, stronger body, try

and partition off the passengers, give them body armour, have a spare

driver, get the driver to drive randomly - lot more complexity and

things to juggle.  Unless you and the car builder are very good (did

you think of EVERYTHING?  What exactly did the car builder DO under

the bonnet - do you know?) - one attack will still wipe you out.
Which of these options is "most secure"?  (Sending them with Arnie in

his Hummer isn't an option.)
Now I'll send this and then think of how the analogy falls apart ... 8-)

(Oops, sorry about not removing the irrelevant stuff from that post.)
And - just to extend the analogy further - the risks may not be

malicious.  So if any of the above scenarios the risks would also be

accidental - car crashes, driver has heart attack, plane falls from

sky, etc.  Something outside your control.  Obviously for number 1 -

one accident does not wipe you out.
And one other extension - number 3 - the beefed up car - perhaps one

of the modifications goes wrong (so again, not a malicious attack) -

the engine overheats because of the extra weight, catches fire, and

your other mods mean that they're all locked in.  The glue from the

partitions is toxic and they are overcome by fumes.  Whatever.  One

accident wipes you out completely.
Enough!

Problem:  in your analogy, there is some limit to the number of bad guys

before they become obvious to local law-enforcement.  In the computer

case, best to consider the number of bad guys unlimited; you can only

limit the _rate_ at which they try to attack via the net (physical

security is back to the car analogy; how many datacentres do you need).
Answer to your question:
4 cars, all dummies.
Dress the diplomats up as cleaning staff and send them via public

transit.
This is where the analogy breaks down.  The safety of the ambasidors

relies on secrecy; if its blown, the bad guys will know which car the

good guys are in and will blow it up.  If it secrecy remains tight, they

won't know your plans whatever they are.  
Doug.

I would have thought this is further evidence of the analogy not being too bad.

 You are relying on secrecy - if that is blown, you're screwed across the board

- all four ambassadors.  So for virtualisation, you are relying on the separate

application domains being partitioned off from each other - and if that is

blown, you're screwed across the board again.  In both cases, the failure could

be malicious (bad guy tortures the maid for information / hacker gets into

system) or accidental (toxic leak on subway / some interaction between guest

process and host triggers previously undiscovered bug.)
But instead of going all James Bond-ish - I could have said is having all your

eggs in one basket more secure?

With all this discussion some questions went to me:
what's the hardware needed to do full and secure (para)?virtualization ?

is there some arch with this support ever created?

could the virtualization environment be secure if all guest OSes run in

userland? (User-Mode Linux, QEMU without acceleration, ...)
Thanks in advance

Some qemu bugs were specifically mentioned in the paper.

With all four cars loaded onto a single car-carrier truck.
-Lars

Exactly!
Have you made each of the ambassadors "more secure" by placing them

in separate cars?
Yes ... BUT NOT if you then put all those cars in the carrier truck -

one attack or accident will most likely wipe them all out.
(Does this mean one of my analogies is going to work?  That will be a

first!)

It's that extra 4MB of poo code, that is what makes it more secure.
It's slippery and sticky at the same time, so that the application

attackers slip and slide and fall into the page boundaries.
If the actual hardware let us do more isolation than we do today, we

would actually do it in our operating system.
The problem is the hardware DOES NOT actually give us more isolation

abilities, therefore the VM does not actually do anything what the say

they do.
While x86 hardware has the same page-protection hardware that an IBM

390 architecture machine has, modern PC machines are a mess.  They are

architecturally so dirty, that parts of the video, keyboard, and other

IO devices are interfaced with even to do simple things like context

switching processes and handling interrupts.  Those of us who have

experience with the gory bits of the x86 architecture can clearly say

that we know what would be involved in virtualizing it, and if it was

so simple, we would not still be fixing bugs in the exact same area in

our operating system going on 12 years.
We know what a VM operating system has to do to deal with the PC

architecture.  It is too complex to get perfectly right.
And now you've entered into the layered approach where *any error* in

the PC model exposed to the client operating system is not just a

crashing bug -- it is now exploitable.
It might be nice, but it is stupid.  And anyone who thinks there is

any security advantage at any level knows nothing about PC

architecture.

I concur with this assessment and the discussion of actual x86 PC

implementation vs. 390 architecture which led up to it.
--

Jack J. Woehr

Director of Development

Absolute Performance, Inc.

jwoehr@absolute-performance.com

303-443-7000 ext. 527

I vote to add it to theo.c.
Thanks
Daniel
Index: src/usr.bin/mg/theo.c

===================================================================

RCS file: /cvs/src/usr.bin/mg/theo.c,v

retrieving revision 1.101

diff -u -p -r1.101 theo.c

--- src/usr.bin/mg/theo.c       28 Aug 2007 17:57:16 -0000      1.101

+++ src/usr.bin/mg/theo.c       24 Oct 2007 21:19:08 -0000

@@ -147,6 +147,7 @@ static const char *talk[] = {

         "cache aliasing is a problem that would have stopped in 1992 if

someone had killed about 5 people who worked at Sun.",

         "Don't spread rumours about me being gentle.",

         "If municipal water filtering equipment was built by the gcc

developers, the western world would be dead by now.",

+       "The security benefits are at the 'ability to buy a steak for

dinner' level.",

  };
  static const int ntalk = sizeof(talk)/sizeof(talk[0]);

On Wed, Oct 24, 2007 at 01:41:38PM -0500, L. V. Lammert wrote:

| For example, say you have three departments within a company: Marketing,

| Development, Production. Allowing each department to maintain their own

| server instance allows each department to have their own users, home

| directory configuration, samba (possibly) network config & authorization,

| separate file/print sharing domain, etc.

|

| That is simple not doable with a single OS, yet with a reasonable priced of

| h/w all can be maintained on one platform.

|

| The security benefits are at the application level, *NOT* at the OS level.
Let's have a look at the case.
Three departments all on one machine, each under one VM.
Why compare this to all departments on one machine, all on the same

OS ? That's not a fair comparison.
Compare your one machine with 3 VMs to three machines. What do you

think is more secure ? If you really, honestly think that the one

machine/3 VM's solution is more secure, I'm actually very interested

in your reasoning for this.
You seperate and isolate each department on their own machine. As

secure as the OS and/or application running on that machine.
Now you join three machines into one machine with three VMs, adding a

layer of complexity/code that is quite useful (as it saves on hardware

costs) but maybe not very mature yet.
How does that joining *add* security ? Please elaborate.
Cheers,
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]

                 http://www.weirdnet.nl/

"Why"?  Because that's what happens *anyway*.

--

 Matthew Weigel

 hacker

 unique@idempot.net

The ends justify the means, even if the means don't actually perform as
This has NOTHING to do with security.  You are just saving pennies.
You did zero actual security assessment, so you are just talking out
You're so full of it.  There is no security/isolation.  You are making

it up out of thin air to justify the pennies you saved.
It's a total lie.

Huh? What does circular logic have to do with a simple statement? Running

different application domains on separate VMs provides isolation BETWEEN

those application domains. That's security by anyone's definition.
The fact is that the OS level security is *separate*, and could be an

issue has nothing to do with the point I'm making.
What if the client OS were Windoze? The security of that OS is crap, and

we all know it. Any sane sysadmin will have a good firewall in front of

that machine, whether it's running in a VM or on separate hardware.
What if the client OS were Linux with AppArmor? SE Linux is a BIG

improvement over regular Linux, and WAY more secure than ANY product from

Redmond.
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.
**IF** OBSD were available as a host OS, that would be good security. If

not, then security issues compound due to multiple guest OSs and each set

of inherent vulnerabilities.
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.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

You must be more qualified with regards to the actual code than I am
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".

I thought it was obvious, .. but I know you have beter things on your mind. 
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 
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 
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

There's something I think you don't see here.  Let's assume, for a

moment, that you have a VM host running two guests, one OpenBSD, one

Windows.
Now, the OpenBSD box is reasonably secure.  The Windows box, perhaps, is

not quite so secure.
An attacker compromises your Windows box.  He discovers that the machine

is running in a VM, and uses a vulnerability in the virtualization

server to execute code on the host itself.
Now, he can edit the memory of the OpenBSD guest, read/copy the disk,

whatever.  Even encryption doesn't help, you can just read the keys out

of RAM.  The OpenBSD guest is completely compromised, without exploiting

any vulnerability in OpenBSD itself.
Theo's point (I think) is that x86 virtualization is so hopelessly

complex that there's no way a human could account for every possible

attack.  That's why x86 virtualization reduces security.
I use VMware all the time, I just don't pretend it's a way to increase

security.

No, the expansion of the original statement into VM security is certainly

valid, but not the original point.
Thanks for the examples, however.
         Lee

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
[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Hi!
Sorry, it's YOU that missed the point! I never said or made any comparison

to physical machines - the entirety of that I said is:
"Running services/application domains in VMs increases security." As I

said in a previous email, only an idiot would think that separatey

physical machines would NOT increase security, and I give this crowd much

more credit than that so I did not bother to include such information.
I still stand by my original statement. Running application 'domains' in

VMs instead of on a single server increases security.
	Lee

It no worse security-wise to run applications on VMs rather than on the

one OS, but that isn't the only choice - is it?
You obviously didn't read Tavis' virtualisation security paper. VM escape

vulnerabilites are not theoretical. Tavis found vulnerabilities in every

VM he tested using only a couple of fuzzers.
Please stop pretending that virtualisation is about security, it isn't.

The benefits are cost savings and decoupling applications from hardware.
-d

Restating my earlier post again, in regards to Xen:
1. Ormandy states that Xen's design is congruent with good security
2. Ormandy doesn't actually demonstrate a DomU -> Dom0 escalation, and

in fact, didn't test any HVMs at all.
3. Ormandy hypothesizes that based on Qemu flaws, there may be lurking

issues. However, Qemu compromises != Xen HVM Qemu compromises
Furthermore:
1. Upstream patches already exist [1] in response to Ormandy's bug report [2]
The standard of security is 100% bug free code? If so, then OpenBSD is

certainly insecure, because the two remote root exploits demonstrated

in the last 10 years shows that OpenBSD is not 100% bug free. Also, a

flaw (along with demonstrated code) was pointed out earlier in this
Usually, when someone makes a claim that OpenBSD is insecure because

of some hypothetical vulnerability, the response is (rightly)

"Demonstrate an exploit. You'll be famous."
Can someone demonstrate a DomU->Dom0 exploit in the current, patched

version of Xen?
From my earlier post, did you look at:
http://shell.cse.ucdavis.edu/~bill/virt/virt.pdf
In particular, how does defending against certain classes of rootkits

and having known, good checksums for known, good binaries not increase

the security of the system?
Lets say DomU is OpenBSD (which HVM virtualizes fine, BTW). The few

rootkits (that could be installed by local, malicious users) for

OpenBSD can be detected using CDR, which wouldn't be the case

otherwise.
That I agree with.
But Xen is free ....
Adam
[1] https://launchpad.net/ubuntu/+source/xen-3.1/
[2] http://secunia.com/advisories/26986/

--

"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu

Don't need to, because that was not the original question. I totally agree 
Quite true! It is ALSO about application separation, the 'application

domains' that were summarized in another email.
         Lee

What you're saying, appears to be:
1)  3 applications in one OS - less secure.

2)  3 applications in 3 physical servers - more secure

3)  3 applications in 3 virtual servers each running one OS - in

between #1 and #2 for security
What the others are telling you is that you are wrong.  While there is

a continuum, is it closer to #1 or #2?  I believe it is closer to #1.

This is because, nobody has done an independent security audit of the

VMWare ESX platform.  When we say something is more secure, we can

show it in 2 ways - a track history, like openbsd, or some 3rd party

verification, fips, orange book, certification, whatever.  ESX's

recent history is extremely damaging.  Again, go look up all the

advisories.  Taking over a guest allows taking over a host?!?!?!

Where is your "separation" again?!
And yes, you did not specify VMWare in your statement.  But the

vulnerabilities being exploited in VMWare shows that the same kind of

attacks can be made against other VMs.
And you do understand the history of how the x86 platform came to be,

right?  IBM wanted to dip their toe in that "microcomputer" thing that

had the world so excited.  Gave the head guy 9 months, or kill the

project.  So, the revisionists now adays say "we use off the shelf

products to be compatible" is bullshit, they had a strict time limit,

and could design and fab their own cpu and other things.  Looked

around, checked out the motorola and intel CPUs.  Hey, lookie here,

the intel cpu's spec book comes with an appendix full of interesting

shit.  Look, they even have a simple design for a microcomputer you

can build with their cpu.
So, IBM basically took that design, and built a PC, and sold it.  Why

do you think while IRQ 5 has higher priority than 6 (lower IRQ has

higher priorty), but IRQ 10 has higher priority than IRQ 5?!?!

Because the original design had *8* slots, and *8* IRQs, but a bunch

was taken up by the system, and so you couldn't actually use all 8

slots.  So, in PC/XT, they kludged somethin...
[ message continues ]

Quoted directly from your first e-mail on this subject:
"Virtualization provides near absolute security - DOM0 is not visible to

the user at all, only passing network traffic and handling kernel calls.

The security comes about in that each DOMU is totally isolated from the

the others, while the core DOM0 is isolated from any attacks."
Your first sentence is provoking these responses.  You cannot make this

claim unless you are 100% certain the virtualization layer is bug free.
If theres a bug in the virtualization layer that allows a NORMAL USER

[1] in any of the guests to compromise the VM layer, host, or any of the

guests, the user has just escalated his privileges through a vector that

would never have been there outside of this VM environment.
Do you see what we're saying now?  You are adding a complex layer of

software to isolate things, when in fact you have no guarantee this

layer cannot cause an escalation by a normal user.
All of the theoretical attack vectors are exactly that: theoretical.

But by adding complex layers does not guarantee any increase in security.
If your application 'domains' are properly isolated on a single server,

by privilege separation and chroot'ing processes, all you have left to

worry about is that NORMAL USER escalating his privileges through some

unknown bug in the OS you choose to run.  You do not have to worry about

the complex VM layer having its own set of unknown bugs.
So, in the end, you are still not getting the point.  There are possible

attack vectors in both single server setups, and virtualized setups.  By

making the claim that security is increased by virtualizing is

fundamentally wrong.  You just don't know of or have heard of any

significant holes in the virtualization layers yet (minus vmware tools).
-Brian
[1] Think Dom0's job of virtualizing hardware for the guests.  If there

is some obscure bug in the Dom0's code, it could be possible for the

normal user inside the guest to provoke this bug through the guest OS

...
[ message continues ]

They aren't theoretical, they have been demonstrated. Read the paper:
http://taviso.decsystem.org/virtsec.pdf

Many IBM PCs vs IBM mainframe
Many mailboxes vs Fort Knox.
Many avenues of attack vs few.
People learn to count in kindergarden.

Apples and oranges.  When people compare one box to many, they're

talking about the same arch of box.  We are specifically NOT talking

about zVM and certainly are NOT considering that zVM and Xen are in the

No, I'm not. The discussion has nothing to do with hardware, but thanks for

the info.
         Lee

And when physical servers cost less than some vmware licenses........
Then it is even more dumb to defend such stupid practices.

I think you forgot to count power savings here?

Some but not all. If you buy a Dell 2950 quad and load it up with 8 Gig. You

can spend $500 on an ESX 3i license and run  10 - 15 512 MB OpenBSD single

processor VMs.  The difference here is that you can max out the duty cycle

on the box where as a single OS running on the same Iron won't do that.  For

ESX it's designed for you to max out the hardware

I think you're off on price by almost an order of magnitude (ESX runs

about $3k per CPU socket, iirc).

I don't disagree with your point, though; virtualizing under-utilized

hardware can save you money and electricity.
--Matt

03, 2007   |   2

Comments<http://www.virtualization.info/2007/10/vmware-infrastructure-35-and-esx-server.html#comments>
The upcoming major update in VMware Infrastructure 3.x, called 3.5, and new ESX

Server 3i<http://www.virtualization.info/2007/09/vmware-announces-esx-server-3i-for.html>will

be available to general public in December 2007,

virtualization.info has learned. An official announcement is expected next

week.
virtualization already broke the

news<http://www.virtualization.info/2007/08/vmware-infrastructure-35-beta-2-feature.html>about

new features and enhancements that will appear in VI

3.5, including ESX Server 3i integration into servers from popular OEMs like

Dell, IBM, HP. But the biggest news emerges only now: *VMware will also sell

ESX Server 3i as stand-alone product, with support for SATA storage devices,

at less than $500*.

So you judge the security of the operating system by how many

(possibly brash) risks its developers are willing to take with it?

That's counter-intuitive.  If I'm looking for security, I'd rather

get my software from a developer who isn't satisfied because (s)he is

more likely to work harder to improve it and be much more careful

while doing it.  If confidence is all that matters, then heck, lets

get rid of all the privilege separation and other risk-minimizing

techniques because you don't need them when your code is flawless right?

Huh? What does that have to do with the number of known exploits for a

given OS?
A simple measure of an OS 'security' is the simple metrics of known

exploits that have been identified.
Certainly OBSD ranks high on the list, which is one reason why we're here.

Certailny good developers are important and appreciated.
The fact that Microshaft crap has hundreds or thousands of vulnerabilities

I have no clue what you're trying to say??? The original comment was the

the number of vulnerabilities is a inverse measure of the security risk

associated with a given OS.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

I have gone as far as to say Windows is "insecure by default" which is

still much more true than it should be. Of course I'm still holding out

some hope (not a lot) that Microsoft really, truly gives a damn someday.
--

Shawn K. Quinn <skquinn@speakeasy.net>

Why would you do that?  Go read The Software Conspiracy.  The author,

Minasi, got, on the record, interviews from VPs of development at

Microsoft, Netscape, Sun, Oracle, etc basically saying that they don't

give a shit about lousy software, because the customers continue to

buy them.
--

"This officer's men seem to follow him merely out of idle curiosity."

-- Sandhurst officer cadet evaluation.

http://www.youtube.com/watch?v=tGvHNNOLnCk

Sun also makes hardware.  Does that attitude flow into hardware design

and manufacture as well?
Doug.

Of course it does.  Did someone actually make money publishing a book

that states the incredibly obvious?
It's Business Economics 101.
It doesn't matter how many letters you write, it doesn't matter how loud

you yell and complain.  If you buy the product, you said, "I like this,

it suits my purpose, the manufacturer did their job".  If it is a non-

commercial product (i.e., open source; the idea could be extended to

bootlegged software) and you use it, they did their job.
[to extend the concept: if you use commercial software but don't

pay for it, but help make it The Industry Standard because you accept

using it, you have /aided the manufacturer/ even as you pat yourself on

the back and say, "I didn't give them any money!"]
If you build a better product that costs you more to make, and the

customer won't pay you more for it (either in per-unit sales or in total

unit sales, you are losing the economic game. If your goal is to make a

return on investment, you can't do that. Plain and simple.
If you are in it to profit, every extra 1 monetary unit you put into the

cost of producing a product better end up back on the bottom line.  And

then some.  Your goal is to make a profit, not shuffle the money around.
Most people whine about software quality, then buy the features, then

whine about the fact it didn't work as well as they hoped. The software

publisher has done exactly what they should, produce a product that

sells with the least cost of production.
Now, let's for the sake of speculation, say in 2004, Microsoft said, "Oh,

people want QUALITY, let's give 'em quality!".  So, they put Windows

Vespa ("Promised you a Harley, delivered a scooter") on hold, and send XP

back for a code audit.  And a few years later (it's a big project!), the

media will be all over Microsoft saying, "What's the big deal??  It's the

same product as it was before!!!".  Not only that, by necessity, it will

have to break a lot of behaviors people are very used to.  Now what?

No one will buy the u...
[ message continues ]

Right, so if I want to buy a computer (hardware) that is actually

designed and built well from the ground up, what then?  Most are i386

which, no matter how well built, being i386 is a pile of legacy crap.

Amd64 still has to be able to run i386 so still has the legacy crap.
HP's now are i386/amd64.  Sun is Sun; designed to meet market forces

competing against i386/amd64.  IBM has a whole slew of Power-based stuff

that costs an arm and a leg new (lots of old stuff available though)

that I'd like to try but you can't run OpenBSD on it.
So if nobody makes really good hardware then there's nobody to reward

for it, so you end up buying bad hardware and rewarding the maker for

it.
Doug.

If given a choice, I think I like Sun's sparc hardware most of all.

Though IBM's boxes do allow LPARs from what I understand.  And

apparently the new power6 boxes will also run/translate x86

software(!), or so I heard.
--

"This officer's men seem to follow him merely out of idle curiosity."

-- Sandhurst officer cadet evaluation.

http://www.youtube.com/watch?v=tGvHNNOLnCk

However, looking at what old Sun sparc stuff is on Ebay, there isn't

much that could translate into something usefull around the home.  Most

are 1U boxes; great for application servers but you can't load them up

with disk drives.  Whereas the IBM pSeries 7025 or 7026 has more room in

which to play.
As for LPARs, I don't really need them.  Unless, I suppose if they

really do provide rock-solid virtualization so I can run an OpenBSD

firewall in one LPAR and another instance of OpenBSD (or Debian,

whatever) in another LPAR for doing work or setting up a file server.
Doug.

I don't think you can run OpenBSD in LPARs.  From the official IBM

docs, all I see available is:
- AIX

- RHEL

- SuSE
I would love to hear about anyone that made OBSD work on p-Series in LPARs.
B)

Please stop feeding this trolling. LV you should know better --

if it is LV -- then again you are known for odd spurts. How are

your twe drivers coming along?

L. V. Lammert wrote:

<gibberish>

Wow, such intelligence!!!! Now we get crap instead of ostrich logic. Sheesh.
         Lee

Actually, that's a fair assessment at this point.
Looking at what you've written, you seem to consider OpenBSD to be

pretty secure. By extension, let's assume the developers, and Theo in

particular, have some darned good knowledge about security and some

priorities in that regard. Then, when Theo and developers (and others in

this community) weigh in and tell you that virtualization is not more

secure, but less, you continue and continue.
As someone who doesn't know a great deal about virtualization, I can

tell you that you're not convincing me of anything with your arguments.

I feel confident in saying that you're not convincing any of the devs,

either. And I doubt you've done much for this cause with the list

members at large.
So what the hell are you doing? Just flaming now? Gave up trying to show

something and just trying to get a few jabs in?
As someone who reads this list and would like to know more about

virtualization, pros and cons, I ask you to put more actual meat into

your posts if you're going to continue. As it stands, <gibberish> fits

all too well.
--

Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG

dwchandler@stilyagin.com   |  http://phxbug.org/      |  http://metabug.org/

http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG Federation

Well, since a lot of people on this list like to continue diverting the

discussion way out in space with far reaching, unrelated tangential

arguments, I can only say that this discussion has descend well below any

level of utilization.
So far, nobody has bother to substiante the argument against the

The points were made, and have been stated on at least numerous occasions.

Nobody has offerred any logic to refute them, only mis-directing the

As you agreed to earlier, your ostrich logic is truly amazing.
	Lee
==============================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

You misunderstood my meaning, and I suspect you did it on purpose.
I haven't been part of this thread until now. I don't have an agenda

here, I'd just like something more meaningful on the topic. Apparently

I'm not going to get that from you. Ok. I'll keep reading, though,

because I'm learning some things from other people who're making some

sense and giving reasons.
--

Darrin Chandler            |  Phoenix BSD User Group  |  MetaBUG

dwchandler@stilyagin.com   |  http://phxbug.org/      |  http://metabug.org/

http://www.stilyagin.com/  |  Daemons in the Desert   |  Global BUG Federation

You apparently missed my post.  Allow me to re-summarize the situation.
There is *nothing* in any virtualization software that makes having

it *more secure* than not having it at all.
Is that direct enough for you?
---

Jason Dixon

DixonGroup Consulting

http://www.dixongroup.net

No, because it's wrong. If you had, perhaps, asked for clarifiction of the

original statement instead of jumping all over someone like they were a

neophyte shithead, you would have, perhaps, learned a little instead of

fostering all the crap on this thread.
That was, in fact, not even part of what I said - better go back and look

at it.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

You're full of shit.  Period.
---

Jason Dixon

DixonGroup Consulting

http://www.dixongroup.net

Now you're REALLY getting intelligent. Sheesh.
         Lee

I may be full of shit, but at least **I** don't post crap like this on a

public list.
         Lee

no, it does not.
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Is that your ostrich response?
         Lee

it has been pointed out several times that virtualization does not

provide the isolation you keep talking about. you keep repeating it

does. just like vmware marketing & co.
--

Henning Brauer, hb@bsws.de, henning@openbsd.org

BS Web Services, http://bsws.de

Full-Service ISP - Secure Hosting, Mail and DNS Services

Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

On Wed, Oct 24, 2007 at 08:31:26AM -0500, L. V. Lammert wrote:

| On Wed, 24 Oct 2007, Henning Brauer wrote:

|

| > * adam.getchell@gmail.com <adam.getchell@gmail.com> [2007-10-24 03:03]:

| > > Virtualization seems to have a lot of security benefits

| >

| > seems?

| > to whom?

| >

| Virtualization provides near absolute security - DOM0 is not visible to

| the user at all, only passing network traffic and handling kernel calls.

| The security comes about in that each DOMU is totally isolated from the

| the others, while the core DOM0 is isolated from any attacks.
This is the theory. In theory, there's no bugs in OpenBSD. In

practice, many of the commits to the tree are not new features/drivers

but actual bugfixes. Read the paper by Tavis Ormandy, referenced by

Theo. There is a real problem with virtualization. Until all bugs are

fixed, virtualization is worse than real hardware. And it'll be hard

to prove all the bugs are fixed.
Cheers,
Paul 'WEiRD' de Weerd
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]

                 http://www.weirdnet.nl/

Practice also. XEN is a great tool for 'duplicating' a machine in an

entererprise environment (IME running 'user level' tools for hundreds or

thousands of users). Separating applications is invaluable, and the

ability to do a machine restore in minutes, using the most recent data

from a local SAN is also a major advantage.
Nobody in the XEN (or VM) world in their right mind would put a VM on the

'Net without significant protection (an OBSD PF machine, perhaps), and

I'm certainly not suggesting that.
Remember that there is more than one world from a technology standpoint!

The vast majority of the SME marketspace (where we operate) is heavily

infiltrated with MS crap; OTOH, OBSD is the only choice for public

servers, or as a front-end to other OSs. The virtualization space

will have to mature significanty, if ever, to meet the security standards

of OBSD.
In the meantime, virtualization provides a great solution for those

applications that benefit from running separately & isolated, while

maximizing h/w utilization.
	Lee
================================================

  Leland V. Lammert            lvl@omnitec.net

    Chief Scientist     Omnitec Corporation

 Network/Internet Consultants   www.omnitec.net

================================================

I am just astounded by how some people who love "virtualization"

                       ^^^^^^^^^^
                                         ^^^^^^^^^^^^^^^^^^^^^
This, it does do.  But the people who want to maximize hw utilization

are trying to lie to themselves about the security aspects.
You can't run more code and then have less failures.

When you read Ormandy's paper, referenced by Damien Miller, in regards

to Xen, you find:
1. Ormandy states that Xen's design is congruent with good security
2. Ormandy doesn't actually demonstrate a Dom0 -> DomU escalation, and

in fact, didn't test any HVMs at all.
3. Qemu compromises != Xen HVM Qemu compromises
Furthermore:
Unless you are using a purely functional language implemented directly

on provably correct hardware, it's impossible to (mathematically)

prove a program is free of bugs. Since you want to solve real-world

problems, you make a tradeoff between features you want and issues you

can live with.
OpenBSD is very, very, very good at security.
On the other hand, if you want to program a fast, parallelized quantum

gravity model to run on a large cluster of OpenMosix nodes, it's not

the right tool for the job.
In the scientific cluster computing and enterprise spaces, it's

already well demonstrated, by many, many practitioners in those fields
[1] https://launchpad.net/ubuntu/+source/xen-3.1/
[2] http://secunia.com/advisories/26986/
[3] In addition to my own work, I can point to colleagues and

organizations, for example, http://cse.ucdavis.edu and

http://immunetolerance.org
Adam

--

"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu

So what?  Someone showed up here and said it is actually all about

security.
That is obviously false to anyone skilled in the field.  You don't

build better security by building another gigantic layer.  That

is obvious to anyone who actually works in the field.
The people who are being fooled are just being 'users'.  They need it,

so they invent all sorts of judgements to make it OK.

Having worked in REAL VM :-) (IBM VM/ESA now z/VM) it isn't per se

about security like we mean security ... preventing cracking

attempts ...

it is about isolation of processes. Isolation of processes does

contribute

to security but it's not the only point of flexion.
In practice, mainframe VM varies greatly in security from installation

to installation ... the protection of processes from one another in the

VM operating system is as hardware/software perfect as the wit and

skill of humankind can provide ... but I've found VM installations with

accounts like USER passwd USER :-(
All things being equal, the safest base installations in the universe

would be those whose user instances were encased in some kind of

solid VM and whose base instance administrators were provided

with and followed best practices.
In re that "solid" VM ... As Theo pointed out the other day, the

Intel hardware support for virtualization is less than complete, i.e.,

less mature than the 35-year-old support for virtualization in the

IBM 370/390 architecture.
So we still gots a ways to go.
--

Jack J. Woehr

Director of Development

Absolute Performance, Inc.

jwoehr@absolute-performance.com

303-443-7000 ext. 527

My VM:  The World.
--

"This officer's men seem to follow him merely out of idle curiosity."

-- Sandhurst officer cadet evaluation.

Bottom-line is, the more complicated your setup gets, the more chances

you get to fuck-up.
All that stuff about extra permissions, extra layers. Each thingie you

add you need to configure. And you won't be 100%, not all the time.
So, Xen is just another opportunity to get fucked.
Instead of designing security, you add another plugin, wave your magic

wand, and say `this is improved security' (take your deepest booming voice,

if you want to be convincing).
Security theater, once again.