login
Search
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 ================================================
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/
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
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.
My VM: The World. -- "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation.
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.
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
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 ================================================
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
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
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
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 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
I may be full of shit, but at least **I** don't post crap like this on a
public list.
Lee
Now you're REALLY getting intelligent. Sheesh.
Lee
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
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 ================================================
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?
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 ...
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)
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]
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*.
No, I'm not. The discussion has nothing to do with hardware, but thanks for
the info.
Lee
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
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
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 ...
They aren't theoretical, they have been demonstrated. Read the paper: http://taviso.decsystem.org/virtsec.pdf
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 ...
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
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
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
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
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 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.
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]);
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.
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
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-)
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!)
(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!
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.
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?
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
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.
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
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
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
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>
