Re: About Xen: maybe a reiterative question but ..
On 08/11/2007, Don Jackson [EMAIL PROTECTED] wrote: As a minor note, I also found this article to be in interesting introduction to Xen: http://www.acmqueue.org/modules.php?name=Contentpa=printer_friendlypid=443page=1 The article is interesting, however it also claims: virtualization (...) decreases server count and reduces overall system complexity. I think that is plain wrong. Surely the hardware consolidation doesn't outweigh the added complexity of the virtualization software. Yes, your datacenter hardware may look leaner and cleaner, but just because the complexity of virtualization does not manifest itself in hardware form doesn't mean it isn't there. The article further claims: Virtualization has a long history, starting in the mainframe environment and arising from the need to provide isolation between users. This makes it sound as if virtualization had been invented as a security technique. Maybe, MAYBE, one VM for each user one one box might be deemed somewhat more separate than many users on one box w/o VM -- but users most definitely are not more separate when the box with VMs is compared to separate computers. Also, the seperation with VMs one one box is questionable because of the added code and complexity. On page 2, the article includes a hefty gulp of security Kool Aid, including this claim: In a system such as Xen, nontrusted applications (...) may be seconded to their own virtual machines and thus completely separated from both the underlying system software and other more trusted applications. Completely separated my arse. Yes, I'd still LOVE to see Christoph's OpenBSD/Xen port be officially included, but I can hardly help much to make it happen, nor do I expect OpenBSD/Xen to be a security godsend. --ropers
Re: About Xen: maybe a reiterative question but ..
2007/11/8, Don Jackson [EMAIL PROTECTED]: It is not at all clear to me that the existance of a Xen port of OpenBSD would detract from the security or performance of the non-Xen ports of OpenBSD. Since you believe to know more about security then Theo, why don't you fork your own XenBSD? Shut up and code. :-p Best Martin
Re: About Xen: maybe a reiterative question but ..
Just a bit more follow up on this topic: Kirk Ismay wrote: I don't think it would be appropriate to have Xen included with the stock OpenBSD kernel/distribution, due to both the security issues, and license issues (Xen is GPL). It may be better for the project to have Xen available as a port, Yes, I agree. Best not to burden the current OS ports with Xen support, but it would be great to have ports like i386-xen and/or amd64-xen available as well. It is not at all clear to me that the existance of a Xen port of OpenBSD would detract from the security or performance of the non-Xen ports of OpenBSD. You may recall I mentioned the Amazon EC2 compute cloud Xen-based service. Yesterday, Red Hat announced support for RH Enterprise Linux on Amazon's EC2: http://aws.typepad.com/aws/2007/11/red-hat-enterpr.html http://www.redhat.com/solutions/cloud/?intcmp=7016000HCbi This is interesting, RH is providing a consistent platform for premise-based, hosted, or cloud-based deployment of applications. I maintain that it would be a good thing if OpenBSD developers had similar deployment options. As a minor note, I also found this article to be in interesting introduction to Xen: http://www.acmqueue.org/modules.php?name=Contentpa=printer_friendlypid=443page=1 Best regards, Don On 10/25/07, Don Jackson [EMAIL PROTECTED] wrote: I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. Like it or not, Xen is a very popular VM environment. (Granted, this may change if Citrix makes changes that people can't live with) One of the most interesting services supporting Xen is the Amazon EC2 service, where you can buy time on their cloud to run VMs. I'd like to be able to build/define/buy AMIs that are based on OpenBSD, and run them on the EC2 cloud. If my application ever needs dedicated hardware, I'll move to that, and I'd remove the VM layer, and I'd gain more security, and more performance. http://www.amazon.com/gp/browse.html?node=201590011 Today, one has no choice but to run Linux-based AMIs on EC2. It would be great if people could define and build OpenBSD 'software appliances' that could be deployed both standalone and virtualized. The ability to participate in VM ecosystems like EC2 would benefit the broader OpenBSD initative. So, if the changes to OpenBSD to support running under VM frameworks can be made without reducing the security/stability/performance of OpenBSD when it is NOT running under VM, and if these changes can be made with licensing terms that are consistent with the OpenBSD license (and acceptable to Theo), then I would really like to see this happen. Don
Re: About Xen: maybe a reiterative question but ..
On 08/11/2007, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/11/8, Don Jackson [EMAIL PROTECTED]: It is not at all clear to me that the existance of a Xen port of OpenBSD would detract from the security or performance of the non-Xen ports of OpenBSD. Since you believe to know more about security then Theo, why don't you fork your own XenBSD? Shut up and code. :-p Best Martin When did Theo claim that the mere existance of a Xen port of OpenBSD would detract from the security or performance of regular (non-Xen) OpenBSD? I don't remember Theo saying that at all, and I've just re-read Theo's posts to the thread and I could not find anything along the lines of what you seem to imply he said. What Theo did say about virtualization was: 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. Don's email made a very specific point which did not contradict Theo in any way. I think you're implying something about Theo's opinion that he in fact never said. Thanks and regards, --ropers
Re: About Xen: maybe a reiterative question but ..
On Sun, Oct 28, 2007 at 10:31:31PM -0400, Nick Holland wrote: It's a pretty simple concept, really. A few years ago, I was giving a talk at a local high school. One of the students asked me why his computer crashed a lot, why can't they build an operating system that doesn't crash?. I told him they can, they do, but he doesn't want it because it doesn't have all the bells and whistles he expects. And, it's bad because that's what he was willing to pay for. This class seems to have understood, it doesn't matter what you say, it's what you buy. Talk all you want, when you BUY or USE the product, you have said This is what I want, and I want it more than I want the money (goal, standard, ideal, whatever) in the only terms that matter. It is a great honor to work with a group like OpenBSD that will not compromise its ideals for the sake of convenience or expediency. It's a very rare thing to find... 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.
Re: About Xen: maybe a reiterative question but ..
On 10/29/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: 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. 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
Re: About Xen: maybe a reiterative question but ..
On Mon, Oct 29, 2007 at 09:11:01AM -0400, bofh wrote: On 10/29/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: 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. 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. 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.
Re: About Xen: maybe a reiterative question but ..
On 10/29/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: 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. 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)
Re: About Xen: maybe a reiterative question but ..
On Wed, 2007-10-24 at 20:27 -0500, L. V. Lammert wrote: The fact that Microshaft crap has hundreds or thousands of vulnerabilities is the other extreme of the list. 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 [EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
On 10/28/07, Shawn K. Quinn [EMAIL PROTECTED] wrote: On Wed, 2007-10-24 at 20:27 -0500, L. V. Lammert wrote: The fact that Microshaft crap has hundreds or thousands of vulnerabilities is the other extreme of the list. 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. 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
Re: About Xen: maybe a reiterative question but ..
On Sun, Oct 28, 2007 at 05:34:17PM -0400, bofh wrote: 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. Sun also makes hardware. Does that attitude flow into hardware design and manufacture as well? Doug.
Re: About Xen: maybe a reiterative question but ..
Douglas A. Tutty wrote: On Sun, Oct 28, 2007 at 05:34:17PM -0400, bofh wrote: 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. 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 upgrade, no one will pay extra for the software on their new PC, and all the old XP users will be saying, It should have been free Service Pack 3, not a new product!. Result: no new revenue after probably the largest development effort ever put into a software product. Do you think that will ever happen again? Do you think I'm so wrong that you are ready to bet a multi-billion dollar software company on the good judgment of the mass market consumer? It's a pretty simple concept, really. A few years ago, I was giving a talk at a local high school. One of the students asked me why his computer crashed a lot, why can't they build an operating system that doesn't crash?. I told him they can, they do, but he doesn't want it because it doesn't have all the bells and whistles he expects. And, it's bad because that's what he was willing to pay for. This class seems to have understood, it doesn't matter what you say, it's what you buy. Talk all you want, when you BUY or USE the product, you have said This is what I want, and I want it more than I want the money (goal, standard, ideal, whatever) in the only terms that matter. It is a great honor to work with a group like OpenBSD that will not compromise its ideals for the sake of convenience or expediency. It's a very rare thing to find... If you don't swim to win, you'll never lose. :) Nick.
Re: About Xen: maybe a reiterative question but ..
Well, this post seems to get a lot of attention throughout the Internet. I normally do not participate on argumentations about opinions. However, I feel like I should get involved, as this is the field I am currently commencing my PhD research in. First, I think Theo is right when he states, that adding another layer of software doesn9t increase security. That9s what we all learned painfully in the past Chroot and jails come to mind (One has to dig deeper to find the problem) It is also true that the x86 was never designed to provide virtualization, besides, it also lacks proper separation. It wasn9t designed to be a success it just happened and we have to live with it. (This reminds me of Microsoft introducing their extension to DOS, called Windows) There are A LOT of caveats when it comes to virtualize the x86 architecture. That9s the reason why Intels VT and AMDs SVM are necessary at all. (SVM which, btw, stands for secure virtual machine - marketing is also something we have to live with, whether you believe in it or not.) It would be desirable to start over, design a new, none backwards compatible, virtualizable hardware. Best, put an extra abstraction layer on top of the hardware (put it in the BIOS or Firmware) and only deal with those interfaces. Add some crypto features et. voila. **sigh** Unfortunately, we are not living in a perfect world. So what can virtualization do for us? Speaking of paravirtualization as in the previous posts, it may add a little security in comparison to jails, but it adds a lot of convenience as handling of VMs gets easier. Which is the main selling point, so the major interest in the near future will be the handling of those virtual machines, and unfortunately not security. Security, or the way we (I/some) see it, does not sell as good as features. I have no doubt that exploiting a VM will become reality sooner or later. However, I would like to keep the discussion going, maybe in a less offensive way?! Cheers Carlo
Re: About Xen: maybe a reiterative question but ..
On 10/25/07, Tom Van Looy [EMAIL PROTECTED] wrote: I think you forgot to count power savings here? Theo de Raadt wrote: And when physical servers cost less than some vmware licenses Then it is even more dumb to defend such stupid practices. 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
Re: About Xen: maybe a reiterative question but ..
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
Re: About Xen: maybe a reiterative question but ..
On 10/26/07, Matt Rowley [EMAIL PROTECTED] wrote: 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 Commentshttp://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 3ihttp://www.virtualization.info/2007/09/vmware-announces-esx-server-3i-for.htmlwill be available to general public in December 2007, virtualization.info has learned. An official announcement is expected next week. virtualization already broke the newshttp://www.virtualization.info/2007/08/vmware-infrastructure-35-beta-2-feature.htmlabout 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*.
Re: About Xen: maybe a reiterative question but ..
Kevin Stam wrote: ... 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
Re: About Xen: maybe a reiterative question but ..
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-) On 25/10/2007, at 7:14 PM, Lars Noodin wrote: Kevin Stam wrote: ... 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
Re: About Xen: maybe a reiterative question but ..
On 25/10/2007, at 8:28 PM, Richard Toohey wrote: 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!
Re: About Xen: maybe a reiterative question but ..
Richard Toohey wrote: My analogies usually go to custard, but I'll try this one. .. 1. One car per ambassador. ... With all four cars loaded onto a single car-carrier truck. -Lars
Re: About Xen: maybe a reiterative question but ..
On 25/10/2007, at 9:00 PM, Lars Noodin wrote: Richard Toohey wrote: My analogies usually go to custard, but I'll try this one. .. 1. One car per ambassador. ... 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!)
Hardware support for secure virtualization (was: About Xen: maybe a reiterative question but ..)
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
Re: Hardware support for secure virtualization (was: About Xen: maybe a reiterative question but ..)
On 2007/10/25 08:50, Rodrigo V. Raimundo wrote: could the virtualization environment be secure if all guest OSes run in userland? (User-Mode Linux, QEMU without acceleration, ...) Some qemu bugs were specifically mentioned in the paper.
Re: Non-x86 (was: About Xen: maybe a reiterative question but ..)
On 24/10/2007, Lars Noodin [EMAIL PROTECTED] wrote: Seriously, what (affordable) non-x86 hardware options are available, especially those without AMT or AMT-like backdoors? http://softwarecommunity.intel.com/articles/eng/1148.htm http://www.intel.com/pressroom/archive/releases/20050301net.htm http://www.intel.com/cd/ids/developer/asmo-na/eng/320959.htm Or is workstation and server hardware covered by CALEA now, too? Relevancy links: http://en.wikipedia.org/wiki/Intel_Active_Management_Technology http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Ac t
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 10:07:59PM -0500, Tony Abernethy wrote: only an idiot would think that separatey physical machines would NOT increase security Many IBM PCs vs IBM mainframe 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 same class (or universe for that matter). Many mailboxes vs Fort Knox. Many avenues of attack vs few. People learn to count in kindergarden.
Re: About Xen: maybe a reiterative question but ..
On Thu, Oct 25, 2007 at 08:37:02PM +1300, Richard Toohey wrote: On 25/10/2007, at 8:28 PM, Richard Toohey wrote: 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.) 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. 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.
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Jason Dixon wrote: You apparently missed my post. Allow me to re-summarize the situation. No, I didn't. 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? 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
At 05:56 PM 10/24/2007 -0700, you wrote: L. V. Lammert [EMAIL PROTECTED] wrote: security issues and protections do not add up like numbers. Sure they do. If I'm running Windoze as a guest OS, there are hundreds or thousands of possible vulnerabilities. If I'm runng OBSD as a guest OS, guess what (I hope you don't have to??) - few to none. There is no way to 'compound threat [interaction]', but that doesn't detract from the basic truth - the lower the risk/number of vulnerabilities of the OS, the better off you are. As a corollary, you might also say that there is no way to improve the security of a server without improving the security of the OS. This has *nothing* to do with VM security. Exactly! As my OP had nothing to do with VM security! That was a tangent posted by others to distract from the main topic. The issue with VM security is that: 1. if any guest is compromised you all guests and the host are in danger. 2. if any user or admininstrator of a guest is malicious, all guests and the host is in danger. Again, very true! No matter how you twist the logic, however, a VM provides a good level of application domain security, from the standpoint that each set of domain users and applications can only see the services provided within that domain guest OS. The phrase application domain security is a cover-up statement that means I have already decided to run the multiple things on one box because I am cheap, and I need to invent reasons why I can continue doing so. Huh?? Do you know what an application domain is? Guess not - here's a definition: Application + Users + Access Method = Application Domain Examples: File/Print, httpd, DB, . . . The more discrete the security model (i.e. File/Print users are not valid on the httpd server) the better. What you try to describe in a somewhat clumsy and round about way corresponds to moving different applications to their respective/isolated machines. This is actually a good thing to do for security. Thank you, sir! Finally, somebody admits understanding the original question, I think. In the interest of less bandwidth, let's not continue the discussion about VM architecture and/or separate machines? I think we can all agree on those points, and the discussion on VM security, while tangential, is certainly food for thought. Lee
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Damien Miller [EMAIL PROTECTED] wrote: 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. 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] On 10/24/07, Brian [EMAIL PROTECTED] wrote: Your first sentence is provoking these responses. You cannot make this claim unless you are 100% certain the virtualization layer is bug free. 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 thread by Christopher Eggart. 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. 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? On 10/24/07, Jason Dixon [EMAIL PROTECTED] wrote: There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. 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. On 10/24/07, Theo de Raadt [EMAIL PROTECTED] wrote: And when physical servers cost less than some vmware licenses 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
Re: About Xen: maybe a reiterative question but ..
At 09:46 PM 10/24/2007 -0400, you wrote: On 10/24/07, L. V. Lammert [EMAIL PROTECTED] wrote: 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. 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 Yes, indeed! 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?! The fact that #3 is more secure than #1 is the original hypothesis, at least from an 'application domain' standpoint. Others diverted the discussion to #2 which, while I assumed everyone would already accept this as fact, still proved an excellent discussion. The information about VMWare, itself, is also good information, though we normally use XEN because most of the applications we build do not include commercial s/w. Lee
Re: About Xen: maybe a reiterative question but ..
At 09:53 PM 10/24/2007 -0400, you wrote: L. V. Lammert wrote: The more discrete the security model (i.e. File/Print users are not valid on the httpd server) the better. 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. No, the expansion of the original statement into VM security is certainly valid, but not the original point. Thanks for the examples, however. Lee
Re: About Xen: maybe a reiterative question but ..
At 09:15 PM 10/24/2007 -0700, you wrote: On 10/24/07, L. V. Lammert [EMAIL PROTECTED] wrote: 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. 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? Actually, running quite well, thanks for asking! Lee
Re: About Xen: maybe a reiterative question but ..
At 09:57 PM 10/24/2007 -0400, you wrote: 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? Perfectly clear, and I agree totally! Only problem is that has nothing to do with the original question (which has been summarized in another email). Lee
Re: About Xen: maybe a reiterative question but ..
At 08:06 PM 10/24/2007 -0400, Brian wrote: Hi! I think you are missing the point about x86 hardware being a mess. No, I'm not. The discussion has nothing to do with hardware, but thanks for the info. Lee
Re: About Xen: maybe a reiterative question but ..
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 Yes, indeed! 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?! The fact that #3 is more secure than #1 is the original hypothesis, at least from an 'application domain' standpoint. Others diverted the discussion to #2 which, while I assumed everyone would already accept this as fact, still proved an excellent discussion. The reason that people are going to #2 is that, if you are concerned about security, that is the optimal way of setting things up. One box, one task. That is true separation. In this light, the question of if #3 is more secure than #1 is truely a moot point. BUT To argue that a VM running a service is more secure than a system running that same service is rather weak... if the service can be exploited, it can be exploited. Be it on a (#1) single server also running other stuff or a (#3) VM guest. Give me root access to a box (from an exploit or an account, don't matter) and I can crash the bitch. VM... no VM... No matter. If I can crash one guest, there is a whole lot of code to support that guest that may or may not behave well. If Theo et al say that the separation that you get from virtualization isn't all it's cracked up to be, then quite frankly the brain trust of these people is pretty massive and they don't tend towards just spewing crap for no reason and the fact that you are arguing about it doesn't make you look all that smart. Nothing is perfect, everything fails, everything eventually crumbles. Let me quote you directly: L. V. Lammert: 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. near absolute security? wow... strong words... I think I'll switch today! I don't think anyone would say those words about even OpenBSD. Thats why we watch for patches like demented hawks. That's why we have IDS systems on our networks, and comb through our logs looking for suspicious stuff. You sir are selling virtual snake oil. Or at least marketing it pretty hard. Feel free to buy in to your own delusion, but don't ask me to. (funny, I say the same thing to certian religous types...) s
Re: About Xen: maybe a reiterative question but ..
At 12:01 PM 10/25/2007 +1000, Damien Miller wrote: On Wed, 24 Oct 2007, L. V. Lammert wrote: I still stand by my original statement. Running application 'domains' in VMs instead of on a single server increases security. 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? Never said it was! The other choices were very well discussed. 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. Don't need to, because that was not the original question. I totally agree with VM security issues, but, again, that was not the original question. Please stop pretending that virtualisation is about security, it isn't. The benefits are cost savings and decoupling applications from hardware. Quite true! It is ALSO about application separation, the 'application domains' that were summarized in another email. Lee
Re: About Xen: maybe a reiterative question but ..
At 12:23 PM 10/25/2007 -0400, you wrote: On Oct 25, 2007, at 10:06 AM, L. V. Lammert [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, Jason Dixon wrote: 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? No, because it's wrong. You're full of shit. Period. I may be full of shit, but at least **I** don't post crap like this on a public list. Lee
Re: About Xen: maybe a reiterative question but ..
On 10/25/07, L. V. Lammert [EMAIL PROTECTED] wrote: The 'obvious' security benefits were in two or three other posts, . but, to summarize: Separate UID/PWs for each domain/VM Uh, how else would it work? How is this specific to virtualization? Separate admin configurations tools See above. Separate authentication configurations (UID/PW, LDAP, ...) See above. Separate configs for network services (apache, samba) See above. Separate machine configurations (Ruby, Tomcat, or HTML) See above. Isolation of each OS guest (this has been a major discussion point, the consensus being that with the possiblility of DOMU - DOM0 exploits, running 'insecure' VMs post a higher risk to DOM0 and the entire machine); Separation of guest OS's is a feature of VM's. It does'nt even apply to non-VM situations since it solves a problem that only exists in virtualization. As pointed out previously, the discussion was originally about the benefits of separate application domains within an enterprise. I'm sure there are benefits for certain situations. --- Lars Hansson
Re: About Xen: maybe a reiterative question but ..
I think you forgot to count power savings here? Theo de Raadt wrote: And when physical servers cost less than some vmware licenses Then it is even more dumb to defend such stupid practices.
Re: About Xen: maybe a reiterative question but ..
On Oct 25, 2007, at 10:06 AM, L. V. Lammert [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, Jason Dixon wrote: 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? No, because it's wrong. You're full of shit. Period. --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
At 12:08 PM 10/25/2007 -0400, Stuart VanZee wrote: The reason that people are going to #2 is that, if you are concerned about security, that is the optimal way of setting things up. One box, one task. That is true separation. In this light, the question of if #3 is more secure than #1 is truely a moot point. BUT To argue that a VM running a service is more secure than a system running that same service is rather weak... if the service can be exploited, it can be exploited. No, you need to read the last two discussion replies - they, at least, make sense. Isolating ONE part of the discussion just posts extra traffic on the list. Give me root access to a box (from an exploit or an account, don't matter) and I can crash the bitch. Very true, but is completely offtopic from the OP, but, then, that has been forgotten long ago. I think everybody can agree that issues within a VM configuration can significantly ADD security risks, *especially* if you're running an OS that are not secure by default. The original discussion of VMs providing security for an application domain, however (per the summary posted about an hour ago), has nothing to do with this level of vulnerability. Providing separation of application domains in an enterprise adds an excellent level of security for the application users and admins. The fact that VM systems compound vulnerabilities, though very significant, is not an issue related to the OP. The fact that running those application domain on separate hardware to provide better security is also a option, but, again, not related to the OP. The fact that OBSD does not operate in that enterprise space, choosing, instead, to focus on core services, is again, not related to the OP. All of these tangential discussions have added a lot of good information to the list archives, thanks to all! Lee
Re: About Xen: maybe a reiterative question but ..
At 12:23 PM 10/25/2007 -0400, Jason Dixon wrote: On Oct 25, 2007, at 10:06 AM, L. V. Lammert [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, Jason Dixon wrote: 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? No, because it's wrong. You're full of shit. Period. Now you're REALLY getting intelligent. Sheesh. Lee
Re: About Xen: maybe a reiterative question but ..
On Thu, 25 Oct 2007 11:26:53 -0500, L. V. Lammert [EMAIL PROTECTED] wrote: At 12:23 PM 10/25/2007 -0400, you wrote: On Oct 25, 2007, at 10:06 AM, L. V. Lammert [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, Jason Dixon wrote: 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? No, because it's wrong. You're full of shit. Period. I may be full of shit, but at least **I** don't post crap like this on a public list. Sure you do. You claim that the following statement is wrong, but you don't offer any explanation. That's crap. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Quit dodging like a troll. Explain yourself. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
Quoting Douglas A. Tutty [EMAIL PROTECTED]: 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?
Re: About Xen: maybe a reiterative question but ..
At 02:28 PM 10/25/2007 -0400, Jason Dixon wrote: Sure you do. You claim that the following statement is wrong, but you don't offer any explanation. That's crap. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Quit dodging like a troll. Explain yourself. If you read the other posts, the security I was originally describing was at the 'application domain' level. Notwithstanding issues with VM security itself, using VMs [XEN or VM], Solaris zones, separate machines, or any other technology you choose provides good security for each domain , in that each is separate and cannot see or interact with any other in normal circumstances. The point was made that there ARE specific exploits that can compromise an entire server, but that's not the purpose of the statement; there was no intent to diverge into the details of specific VM implementations nor any issues due to the OS itself. I believe a comment was made that 'application domain secuirty' can also be looked as 'application separation', which could be considered analagous. Lee
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert: At 12:08 PM 10/25/2007 -0400, Stuart VanZee wrote: The reason that people are going to #2 is that, if you are concerned about .security, that is the optimal way of setting things up. One box, one task. That is true separation. In this light, the question of if #3 is more secure than #1 is truely a moot point. BUT To argue that a VM running a service is more secure than a system running that same service is rather weak... if the service can be exploited, it can be exploited. No, you need to read the last two discussion replies - they, at least, make sense. Isolating ONE part of the discussion just posts extra traffic on the list. Give me root access to a box (from an exploit or an account, don't matter) and I can crash the bitch. Very true, but is completely offtopic from the OP, but, then, that has been forgotten long ago. I think everybody can agree that issues within a VM configuration can significantly ADD security risks, *especially* if you're running an OS that are not secure by default. The original discussion of VMs providing security for an application domain, however (per the summary posted about an hour ago), has nothing to do with this level of vulnerability. Providing separation of application domains in an enterprise adds an excellent level of security for the application users and admins. The fact that VM systems compound vulnerabilities, though very significant, is not an issue related to the OP. The fact that running those application domain on separate hardware to provide better security is also a option, but, again, not related to the OP. The fact that OBSD does not operate in that enterprise space, choosing, instead, to focus on core services, is again, not related to the OP. All of these tangential discussions have added a lot of good information to the list archives, thanks to all! Lee Quite frankly, I tire of your dumb-ass attitude. This was VERY ON TOPIC. Security for the applecation domain is a function of the level of vulnerability in the VM. If the VM is vulnerable, the application domain does not have an ice cubes chance in hell of being secure. So security of the VM is VERY on topic. Because you stated: Virtualization provides near absolute security The fact that a guest is running in a virtual environment provides NO extra protection to the users or the applications of THAT INDIVIDUAL GUEST. If it can be broken, it can be broken. PERIOD. I don't give a rats ass if they are running in a VM, not in a VM, or on a system made out of steaming piles of dog shit. What can be broken, can be broken. Add to that, if you have a virtualization server with a number of guests on it and even ONE of those guests get rooted, that ONE guest gives the interloper a much better platform to launch attacks against the other guest systems than if each guest was instead implemented on it's own hardware and secured separately. This is also on topic because make no mistake, that is the proper metric for this argument. Compairing each service being run in it's own guest to all services running on one system is not a proper comparison because it assumes that that is the normal accepted practice when security is of concern (Security is the topic that you are arguing after all). All it takes is some missed bit of bad code in any one of hundreds of virtual hardware services that the VM must provide to the guest operating systems and the rest of the guests are vulnerable. Even if they are systems that aren't usually vulnerable to attack if they are used stand alone, they now have to worry about not only attacks from the outside network, they have to worry about attacks from the VM stack itself because, as we have seen throughout the years, if it exists, some bad guy somewere will try to use it. If it is not perfect (and nothing is) sooner or later, some bad guy somewere will succeed. I have heard many people who are considered experts in the field of security say over and over again... (to the faithful) say it with me... Simplicity is the path to security. Complexity is the path to (security) RUIN. Virtualization adds VERY much to the complexity of a system. Argue with that and you might as well try to argue that Flan is good food (no offence intended to those who actually like flan... ew...).
Re: About Xen: maybe a reiterative question but ..
At 03:09 PM 10/25/2007 -0400, Stuart VanZee wrote: Quite frankly, I tire of your dumb-ass attitude. This was VERY ON TOPIC. Indeed it is! I also tire of the dumb replies that don't have any relationship to the original subject. Security for the applecation domain is a function of the level of vulnerability in the VM. If the VM is vulnerable, the application domain does not have an ice cubes chance in hell of being secure. So security of the VM is VERY on topic. Because you stated: Virtualization provides near absolute security The fact that a guest is running in a virtual environment provides NO extra protection to the users or the applications of THAT INDIVIDUAL GUEST. Certainly! That is not the point, however. The point is that users of OTHER 'application domains' have better security with a VM (or one of the other approaches discussed) because THEIR environment has no ability to interact with the OTHER environments. The digression into VM vs. separate machine vs. compoud vulnerabilities is totally tangent to the original topic, and, while educational, is certainly no longer productive at this time. I strongly suggest that we all retire with a lot of good information on vulnerabilities and an agreement that there are different methods for addressing security problems. Lee
Re: About Xen: maybe a reiterative question but ..
Certainly! That is not the point, however. The point is that users of OTHER 'application domains' have better security with a VM (or one of the other approaches discussed) because THEIR environment has no ability to interact ^ How do you know these 'VM' enviroments provide that gaurantee? You don't. You don't know, and you are not even qualified in the least to judge if they are able to gaurantee that. with the OTHER environments. The digression into VM vs. separate machine vs. compoud vulnerabilities is totally tangent to the original topic, and, while educational, is certainly no longer productive at this time. I strongly suggest that we all retire with a lot of good information on vulnerabilities and an agreement that there are different methods for addressing security problems. You're just a system administrator who sells his services to gullible clients. Can you please stop talking like you know anything about how secure products are built or judged?
Re: About Xen: maybe a reiterative question but ..
At 01:58 PM 10/25/2007 -0600, Theo de Raadt wrote: Certainly! That is not the point, however. The point is that users of OTHER 'application domains' have better security with a VM (or one of the other approaches discussed) because THEIR environment has no ability to interact ^ How do you know these 'VM' enviroments provide that gaurantee? You don't. You don't know, and you are not even qualified in the least to judge if they are able to gaurantee that. There are no guarantees in this world, .. I can just talk about experience. No environment provides a guarantee, even OBSD. Track record and experience are indicators of quality, not statements. All I know is that if I am logged into a VM, I cannot see/view/do anything with another VM (possible hacks aside). That is the security that originally started this thread - I am in no position, nor are you, to speak of guarantees, though you do, obviously, know much more than I do about architectures and possible VM exploits. Can you please stop talking like you know anything about how secure products are built or judged? I never did, .. and this thread has nothing to do with profects, how they are built, nor how they are judged. I leave those tasks to the people like yourself that know the internals, along with the respective histories. The discussion WAS about security merits of VM configurations - the structure itself has a number of security issues related to the guest/host OS AND the VM manager, certainly, but the original point was that by separating applications into separate machines (my suggestion was virtual, however others made the point that physical may be more secure) there is a significant security gain because each 'application domain' cannot interact with another under normal circumstances. Additional benefits are recuded cost, increased availability, increased flexibility and security granularity [by application/server], reduced energy requirements, and flexibility of configuration [of each machine]. Lee
Re: About Xen: maybe a reiterative question but ..
At 01:58 PM 10/25/2007 -0600, Theo de Raadt wrote: Certainly! That is not the point, however. The point is that users of OTHER 'application domains' have better security with a VM (or one of the other approaches discussed) because THEIR environment has no ability to interact ^ How do you know these 'VM' enviroments provide that gaurantee? You don't. You don't know, and you are not even qualified in the least to judge if they are able to gaurantee that. There are no guarantees in this world, .. I can just talk about experience. You're just a sysadm. So stop making stuff up. No environment provides a guarantee, even OBSD. Track record and experience are indicators of quality, not statements. You're also a sysadm who refuses to read a paper written by a google researcher, who's team found massive bugs in every VM. My suspicion is you're an old dog who can't learn new tricks anymore. You sure like to talk about stuff you don't know anything about. Perhaps you'll just leave us alone?
Re: About Xen: maybe a reiterative question but ..
I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. Like it or not, Xen is a very popular VM environment. (Granted, this may change if Citrix makes changes that people can't live with) One of the most interesting services supporting Xen is the Amazon EC2 service, where you can buy time on their cloud to run VMs. I'd like to be able to build/define/buy AMIs that are based on OpenBSD, and run them on the EC2 cloud. If my application ever needs dedicated hardware, I'll move to that, and I'd remove the VM layer, and I'd gain more security, and more performance. http://www.amazon.com/gp/browse.html?node=201590011 Today, one has no choice but to run Linux-based AMIs on EC2. It would be great if people could define and build OpenBSD 'software appliances' that could be deployed both standalone and virtualized. The ability to participate in VM ecosystems like EC2 would benefit the broader OpenBSD initative. So, if the changes to OpenBSD to support running under VM frameworks can be made without reducing the security/stability/performance of OpenBSD when it is NOT running under VM, and if these changes can be made with licensing terms that are consistent with the OpenBSD license (and acceptable to Theo), then I would really like to see this happen. Don
Re: About Xen: maybe a reiterative question but ..
On Thu, Oct 25, 2007 at 01:45:23PM -0500, L. V. Lammert wrote: At 02:28 PM 10/25/2007 -0400, Jason Dixon wrote: Sure you do. You claim that the following statement is wrong, but you don't offer any explanation. That's crap. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Quit dodging like a troll. Explain yourself. If you read the other posts, the security I was originally describing was snip dodging Explain how the previous statement is incorrect, as you claim. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
FW: About Xen: maybe a reiterative question but ..
I finally get it... LEE! YOU ARE A FUCKING GENIUS! Hey everyone... In Mr. Lammert's world, as long as NOBODY is trying to break the system, VMs give a HUGE security plus! Problem is, there are a lot of very bad motherfuckers out there who ARE trying to break the system. So, when someone starts talking about security, excuse the hell out of me for automatically thinking you mean security from those bad guys, apparently you are talking about security from the damn sheep who couldn't break the system if their lives depended on it so they don't even try. dude, if you take security in the context of people trying to break the system (and we always are, fuck the sheep) you have to take a MUCH larger view than what you are taking. Suddenly things like To VM or not to VM become a very serious question. Ntpd, OpenNTPD, or rsync? Intel? AMD? SPARC? The question of having one server or segregating into individual servers is a question that you poke and prod until it's bloody. The permutations are endless and to focus on one idea SO SMALL as the sheep won't be able to crash the VM so it must be more secure is like saying the onions in the soup aren't poison so the rest of the ingredients must be ok. There ISN'T multiple viewpoints on security. There is one. And it encompasses everything, every topic, every idea, even the very essence of the universe. It has to, because if you leave any little part out, you have failed. Oh... and really, you have to take into account the sheep too... you would be surprised at what they can do to a system without even trying. Just once have a UNIX system that a Jr admin setup go down because Thelma the new secretary was trying to figure out how to get AOL installed and working right.
Re: FW: About Xen: maybe a reiterative question but ..
At 05:08 PM 10/25/2007 -0400, Stuart VanZee wrote: I finally get it... LEE! YOU ARE A FUCKING GENIUS! Beautiful! [Taking Bow]
Re: About Xen: maybe a reiterative question but ..
* Don Jackson [EMAIL PROTECTED] [2007-10-25 13:33:29]: I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. I don't mean to put words in peoples' mouthes, but OpenBSD is about _simplicity_, not the latest buzz-word on the market. So, if the changes to OpenBSD to support running under VM frameworks can be made without reducing the security/stability/performance of OpenBSD when it is NOT running under VM, and if these changes can be made with licensing terms that are consistent with the OpenBSD license (and acceptable to Theo), then I would really like to see this happen. Doubtful. Security is going to take a hit. That's obvious from this thread. Stability? Pretty similar to security. Performance? Yes, that will go down too. I'd start a whole new CVS repository. The changes that would have to be made would be drastic, and likely incompatible. IMHO, virtualization is a technology that needs to be built from the ground up, and not brutally hacked ontop of the already horrid x86 architecture. -- Travers Buda
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: Certainly! That is not the point, however. The point is that users of OTHER 'application domains' have better security with a VM (or one of the other approaches discussed) because THEIR environment has no ability to interact with the OTHER environments. The digression into VM vs. separate machine vs. compoud vulnerabilities is totally tangent to the original topic, and, while educational, is certainly no longer productive at this time. May be if you were trying to explain your points in a more 'meat substance' some users may agree with you, or not, but at a minimum that might be productive somewhat and I think I have seen that many times and not be address properly. I strongly suggest that we all retire with a lot of good information on vulnerabilities and an agreement that there are different methods for addressing security problems. May be if put in more practical term it might help to make your point, if I even get that properly. So, here is an example that you may try to use that may actually be somewhat valid. But again, I would have expected you to do so. So, lets make it very simple and may be at the same time take a subject real that come regularly on this lists and that this may help, or not. Please do not take this as a judgment on the merit of it. I only offer it as a way to make peace and may be at clarifying what may have been your intent may be if I even get that right. So, here is the problem I will take to make this example. - May users always asked how they can make their PHP web setup secure. Again, plenty of discussion on the subject, so lets not start this again. - Also lets consider the fast that users at large are cheap and only wants to pay as little as possible. Again real life situation. - Also consider that an ISP needs to make a profit to stay in business and as such can't make miracle. So, what's to do next then. Again, I am not saying it the right solutions as I will raise other problem with it, but anyway, lets just take the idea. 1. One regular setup. Hosting ABC provide virtual hosting at $10/month for a web site. 2. Hosting DEF provide the virtual hosting at $15/month with OpenBSD and JAIL setup, etc. 3. Hosting GHI provide virtual hosting at $20/month with VM. 4. Hosting JKL provide dedicated hosting at $100/month. Now thew users have the choice, but they are cheap... Now these are in the order of security. I think we can all agree to this right. All/most would agree that when PHP is running on a virtual server, unless you run one instance of apache per user, etc. then a php script can access to space of others on the save server and it's not that hard to do right. So, what you explain is that the third setup would be the best, if we consider costs in operations. 4 is the separated servers, witch is much more expensive, because of hardware, space, AC, power, setup, maintenance, etc, etc, etc. 1, 2 and 3 all use same space, most likely in small setup obviously to keep this under control for the discussion, same power, same ac, almost same maintenance, etc. #1 and 2, someone sure could hack someone else web space and destroy it. In case of #1 and 2, most likely is only one of the virtual hosting site is compromise via PHP, witch is not that difficult if the script itself is not well written and I will and do not want to argue this here, let just say Joe Blow can't write properly and anyone can hack it in 5 minutes for the sake of discussions. Then all users on that box are compromise. Now will the bad guy destroy them all, or just Joe Blow. It is not relevant here and we should all agree to that. The bad guy can after compromise Joe Blow, sure can compromise everyone else in no time should (s)he choose to do so. That's the risk or using virtual hosting. Sadly your security is not under your control. We all have to agree to that no matter what. Now #4, well it's all yours and is as good as you choose to do so, but is also the most expensive setup. Just like it was explain many times here on your question. So, we have the use of VM to save cost, witch all agree. Also, it doesn't maximize the utilization of the hardware like VM would, we all agree with that as well. So, I guess so far, unless I didn't follow this properly. I would venture to say that everyone would agree up to this point right? If not, I have to say, that I would need to get educated myself then on each one, but it is fair to say that's the case until now. What's left now is the point #3, witch everyone beat it to death. Why is that. I think because it is just not explain in a light that many could relate to. I don't have an expression in English that would translate as well as in French, but a direct translation would be that You are tripping on the flowers of the carpet. I know it doesn't make sense, but see it as someone that walk on your grandmother old carper that have flower design
Re: About Xen: maybe a reiterative question but ..
On 10/25/07, Daniel Ouellet [EMAIL PROTECTED] wrote: So, if I take your point or 'applications domain' and and translate this in more practical term and stop using words out of the far fetch paper and use more pragmatic day to day example. You argue that in this case, if a setup is using VM for the virtual hosting would be more secure, assuming disk space, IP's, CPU power, rack space, etc is not consider here. That this setup would be more secure? I think in this case, we can all agree yes it would be, more secure. Absolutely secure however, no. I guess many are arguing that point and that needs to be put in perspective. I think the point most people were making is that this is not true. Take any common example, php hosting web server, windows, etc. All these have easily exploitable holes. OK, now one of your guest boxes is exploited. All you need is a guest-host exploit, and you've been crapped upon. In the separate physical box scenario, all the screwed up box would have access to, is the network. In this VM case, it has access to everything that runs in dom0. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: About Xen: maybe a reiterative question but ..
On 10/25/07, Jason Dixon [EMAIL PROTECTED] wrote: On Thu, Oct 25, 2007 at 01:45:23PM -0500, L. V. Lammert wrote: At 02:28 PM 10/25/2007 -0400, Jason Dixon wrote: Sure you do. You claim that the following statement is wrong, but you don't offer any explanation. That's crap. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Explain how the previous statement is incorrect, as you claim. I explained it here [1] in a previous post, which demonstrates a method for detecting rootkits that would be otherwise undetectable without virtualization. Jason Dixon [1] http://cse.ucdavis.edu/~bill/virt/virt.pdf Adam -- Invincibility is in oneself, vulnerability in the opponent. -- Sun Tzu
Re: About Xen: maybe a reiterative question but ..
On 10/25/07, Theo de Raadt [EMAIL PROTECTED] wrote: You're also a sysadm who refuses to read a paper written by a google researcher, who's team found massive bugs in every VM. That's not quite correct. Restating (yet) again: 1. Ormandy [1] 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 [2] in response to Ormandy's bug report [3] Adam [1] http://taviso.decsystem.org/virtsec.pdf [2] https://launchpad.net/ubuntu/+source/xen-3.1/ [3] http://secunia.com/advisories/26986/ -- Invincibility is in oneself, vulnerability in the opponent. -- Sun Tzu
Re: FW: About Xen: maybe a reiterative question but ..
2007/10/25, L. V. Lammert [EMAIL PROTECTED]: At 05:08 PM 10/25/2007 -0400, Stuart VanZee wrote: I finally get it... LEE! YOU ARE A FUCKING GENIUS! [+] you mean security from those bad guys, apparently you are talking about security from the damn sheep who couldn't break the system if their lives depended on it so they don't even try. [+] if you take security in the context of people trying to break the system (and we always are, fuck the sheep) ROTFL Beautiful! I concur ;) You just don't get it, do you ? Maybe you understand the word 'security' in a some different way that others here. Security is like a chain. You wrote about 'viewpoint'. Your 'viewpoint' - 'application domain' is just one link in this chain. People here are thinking about whole chain. Virtualization in theory may strengthen this 'chain'. But, in reality it makes whole 'chain' weaker. That's because you add one link 'application domain separation' (which is OK), but you automatically *have* to add another link 'VM implementation bugs'. The latter make this 'chain' weaker that it is without it. How much worse is it ? That's another question. I use VMware ESX and IBM pSeries virtualization products. The first is unacceptable for mission critical tasks the latter is (for my specific 'chain' ) You clearly are not a security expert, so please, do not make statements as one. Piotr Kapczuk
Re: About Xen: maybe a reiterative question but ..
2007/10/26, Adam Getchell [EMAIL PROTECTED]: On 10/25/07, Theo de Raadt [EMAIL PROTECTED] wrote: You're also a sysadm who refuses to read a paper written by a google researcher, who's team found massive bugs in every VM. That's not quite correct. Restating (yet) again: 1. Ormandy [1] states that Xen's design is congruent with good security [...] And your point is ? Xen is good enough. (?) Well, you may want to read this white paper more carefully. [1] http://taviso.decsystem.org/virtsec.pdf The results obtained demonstrate the need for further research into virtualisation security and prove that virtualisation is no security panacea. Piotr Kapczuk
Re: About Xen: maybe a reiterative question but ..
On Thu, Oct 25, 2007 at 03:27:07PM -0700, Adam Getchell wrote: On 10/25/07, Jason Dixon [EMAIL PROTECTED] wrote: On Thu, Oct 25, 2007 at 01:45:23PM -0500, L. V. Lammert wrote: At 02:28 PM 10/25/2007 -0400, Jason Dixon wrote: Sure you do. You claim that the following statement is wrong, but you don't offer any explanation. That's crap. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Explain how the previous statement is incorrect, as you claim. I explained it here [1] in a previous post, which demonstrates a method for detecting rootkits that would be otherwise undetectable without virtualization. I think you mean undetectable in a running system, don't you? At least, that's the gist I got from those slides. That does not equate to a more secure system, just one that might be more conveniently (although not necessarily more accurately) audited. -J.
Re: About Xen: maybe a reiterative question but ..
Don Jackson wrote: I wanted to add my 2 cents to this thread. Ignoring the debate/flamage on this thread regarding the security merits/risks of virtualization, I beleive there are a number of us who would like the option to run OpenBSD as a guest under various virtual machine frameworks. Even if it is less secure than dedicating a machine to the problem at hand. I would also like to see OpenBSD as an option for both Xen Dom0/DomU installations. After reading this thread, I've learned a lot about VM security issues. Personally, I'd feel more a bit more secure having OpenBSD host a Windows or Linux guest, rather than the reverse. I don't think it would be appropriate to have Xen included with the stock OpenBSD kernel/distribution, due to both the security issues, and license issues (Xen is GPL). It may be better for the project to have Xen available as a port, which would include the hypervisor, kernel images, and the associated tools. The port could also contain useful documentation on the security implications of using VM technology. Whether the OpenBSD developers would bless a Xen port is the next question... -- Sincerely, Kirk Ismay System Administrator -- Net Idea 201-625 Front Street Nelson, BC V1L 4B6 P:250-352-3512 | F:250-352-9780 | TF:1-888-352-3512 Check out our brand new website! www.netidea.com
Non-x86 (was: About Xen: maybe a reiterative question but ..)
Theo de Raadt wrote: x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. He probably meant psychological security, or job security. ... Then running your operating system on the other side of this brand new pile of shit. Seriously, what (affordable) non-x86 hardware options are available, especially those without AMT or AMT-like backdoors? http://softwarecommunity.intel.com/articles/eng/1148.htm http://www.intel.com/pressroom/archive/releases/20050301net.htm http://www.intel.com/cd/ids/developer/asmo-na/eng/320959.htm Or is workstation and server hardware covered by CALEA now, too? -Lars
Re: About Xen: maybe a reiterative question but ..
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2007-10-24 03:03]: Virtualization seems to have a lot of security benefits seems? to whom? to people who never wrote a line of code and don't understand how things work? -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: About Xen: maybe a reiterative question but ..
Dear sirs please: I will return to my original question. I just wondered if xen
will be included into the OpenBSD's kernel to act as a para-virtualized DomU or
not. Nothing more. I will not go into issues of the type is insecure or not.
Theo, or somebody from developer team: Will be para-virtualized domU xen kernel
included on next OpenBSD release (4.3?) or not?? I only want to know this...
Many thanks to all.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, carlopmart [EMAIL PROTECTED] wrote: Dear sirs please: I will return to my original question. I just wondered if xen will be included into the OpenBSD's kernel to act as a para-virtualized DomU or not. Nothing more. I will not go into issues of the type is insecure or not. Theo, or somebody from developer team: Will be para-virtualized domU xen kernel included on next OpenBSD release (4.3?) or not?? I only want to know this... Not unless someone actually writes the code to do it. Notice the extreme number of people with openbsd.org email addresses jumping up and down, volunteering to do it (hint: none). Possibly not even if someone writes the code. Diffs are not always merged. They should be good diffs that improve OpenBSD. Notice the number of people with openbsd.org email addresses who are not convinced that doing this a) will improve OpenBSD and b) won't actually hurt. So I'm going to guess the answer is No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs? CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Re: About Xen: maybe a reiterative question but ..
Chris Kuethe wrote:
On 10/24/07, carlopmart [EMAIL PROTECTED] wrote:
Dear sirs please: I will return to my original question. I just wondered if xen
will be included into the OpenBSD's kernel to act as a para-virtualized DomU or
not. Nothing more. I will not go into issues of the type is insecure or not.
Theo, or somebody from developer team: Will be para-virtualized domU xen kernel
included on next OpenBSD release (4.3?) or not?? I only want to know this...
Not unless someone actually writes the code to do it. Notice the
extreme number of people with openbsd.org email addresses jumping up
and down, volunteering to do it (hint: none). Possibly not even if
someone writes the code. Diffs are not always merged. They should be
good diffs that improve OpenBSD. Notice the number of people with
openbsd.org email addresses who are not convinced that doing this a)
will improve OpenBSD and b) won't actually hurt.
So I'm going to guess the answer is No, integrating xen
paravirtualization is not a project priority at this time. Also, where
are your diffs?
CK
Many thanks Chris. A clear response. I am not a developer but I can offer to
test xen based OpenBSD kernels on my servers ...
--
CL Martinez
carlopmart {at} gmail {d0t} com
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Henning Brauer wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [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. 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 functionality. to people who never wrote a line of code and don't understand how things work? 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
On Tue, Oct 23, 2007 at 08:35:39PM -0700, Ben Goren wrote: On 2007 Oct 23, at 5:57 PM, [EMAIL PROTECTED] wrote: Virtualization seems to have a lot of security benefits. ``Seems'' is the key word, here. On hardware like an IBM mainframe that can acutally support what's necessary for secure virtual machines, sure. On x86? Well, it'll keep your kid sister out Is there any hardware inbetween that would be secure? Or, is there now nothing between the two at all? I thought that Opterons had some type of hardware support on the CPU; perhaps its only enablers not secureors. Doug.
Re: About Xen: maybe a reiterative question but ..
On Wed, Oct 24, 2007 at 08:31:26AM -0500, L. V. Lammert wrote: | On Wed, 24 Oct 2007, Henning Brauer wrote: | | * [EMAIL PROTECTED] [EMAIL PROTECTED] [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/
Re: About Xen: maybe a reiterative question but ..
On Tuesday 23 October 2007 18:22:00 ropers wrote:
Hi Christoph,
Right now, on the OpenBSD misc mailing list, there is this discussion:
http://www.sigmasoft.com/~openbsd/archives/html/openbsd-misc/2007-10/thread
s.html#01149 about OpenBSD/Xen.
We last spoke last year, when I put your BSDtalk interview transcript
online at http://ropersonline.com/openbsd/xen .
It seems to me that most people on the misc mailing list currently are
not very aware of your OpenBSD Xen port. Could I possibly ask you to
participate in the discussion? I feel that you (and Theo) are the only
guys who can provide authoritative answers on the issue.
Some of the questions that I feel are unclear are:
- Was your porting work fully completed? IIRC it was, but please clarify.
DomU support is ready. Dom0 is work in progress.
(apart from use-after-free bugs in MI buffer-cache and filesystem code,
which damages filesystem.)
Dom0 is work in progress, but is stalling on a NULL-pointer bug
in uvm_pglistalloc_simple().
This code piece in the kernel reproduces this crash:
void foo(void)
{
struct pglist mlist;
uvm_pglistalloc(PAGE_SIZE * 64, 0, 0x, 0, 0, mlist, 64, 0);
}
I didn't investigate further into this, because I have put my focus
on the xen-kernel and xen-tools to compile on OpenBSD and NetBSD
out-of-the-box. To finish this task, I need some things in OpenBSD:
- aio(2) support
- POSIX ptsname() (this is used in a python binding module)
- newer gcc version due to a structure padding bug with
an alignment attribute hidden in a typedef (this is fixed in gcc 3.4)
I use gcc 4.2 from the ports FYI.
- I need i386 headers and libc on OpenBSD/amd64 for 64bit builds.
gcc -m32 defines __i386__ so it is possible to distinguish if a
#include stdint.h must provide 32bit or 64bit integer type definitions.
Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers
should be in /usr/include/uvm/, for example.
- Is your port still being maintained? Can it be run with OpenBSD
-current or 4.2?
4.1. It needs an update. Maybe some of the nasty MI bugs are gone.
- It seems to me that your port didn't achieve wide recognition and
acclaim because of a lack of publicity.
I'm not a marketing guy.
- AFAIK your OpenBSD/Xen port code hasn't found its way into the
official OpenBSD distribution. Is this correct?
yes.
- Are there any reasons why your code didn't go into the official
OpenBSD distro? Was it lack of awareness? Have you ever talked to Theo
and/or other central OpenBSD people?
I haven't found someone who is willing to commit the diffs.
- Is there any hope that your port might still become part of the
official OpenBSD distribution?
(Theo: Could you possibly comment as well?)
I don't know.
I'd personally be very interested to see your port become part of the
official distribution, but I sadly can't code myself, so all I can do
is ask and hope. :)
Once again, thanks for your hard work. :)
You're welcome.
Many thanks in advance and kind regards,
Jens Ropers
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 16:14:19 Chris Kuethe wrote: On 10/24/07, carlopmart [EMAIL PROTECTED] wrote: Dear sirs please: I will return to my original question. I just wondered if xen will be included into the OpenBSD's kernel to act as a para-virtualized DomU or not. Nothing more. I will not go into issues of the type is insecure or not. Theo, or somebody from developer team: Will be para-virtualized domU xen kernel included on next OpenBSD release (4.3?) or not?? I only want to know this... Not unless someone actually writes the code to do it. Notice the extreme number of people with openbsd.org email addresses jumping up and down, volunteering to do it (hint: none). Possibly not even if someone writes the code. Diffs are not always merged. They should be good diffs that improve OpenBSD. Notice the number of people with openbsd.org email addresses who are not convinced that doing this a) will improve OpenBSD and b) won't actually hurt. So I'm going to guess the answer is No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs? The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. Christoph
Re: About Xen: maybe a reiterative question but ..
* L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: 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. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: About Xen: maybe a reiterative question but ..
On Wednesday 24 October 2007 17:25:25 Artur Grabowski wrote: Christoph Egger [EMAIL PROTECTED] writes: So I'm going to guess the answer is No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs? The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. I'm willing to stretch as far as saying: This might be interesting for some testing purposes for kernel hackers if Xen could be hosted on OpenBSD. But this doesn't mean that I'm even close to volunteering doing the job. It just would be cool to have if it doesn't break stuff. //art Actually it is good to find NULL-pointer (mostly use-after-free) bugs, that are hard to find on real hardware. Believe me or not: OpenBSD has tons of them. Christoph
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, L. V. Lammert wrote: 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. 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 [EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
Christoph Egger wrote:
On Wednesday 24 October 2007 17:25:25 Artur Grabowski wrote:
Christoph Egger [EMAIL PROTECTED] writes:
So I'm going to guess the answer is No, integrating xen
paravirtualization is not a project priority at this time. Also, where
are your diffs?
The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg
Unfortunately, Anil has troubles with the availability of the server.
I rely on having a willing OpenBSD developer who commits the patches I
send to him. But as long as there is none, it doesn't go in.
I'm willing to stretch as far as saying: This might be interesting for
some testing purposes for kernel hackers if Xen could be hosted on
OpenBSD.
But this doesn't mean that I'm even close to volunteering doing the
job. It just would be cool to have if it doesn't break stuff.
//art
Actually it is good to find NULL-pointer (mostly use-after-free) bugs,
that are hard to find on real hardware.
Believe me or not: OpenBSD has tons of them.
Christoph
Christoph,
One question about your Xen port: is it possible to compile a xen
para-virtualized openbsd kernel to launch a clean OpenBSD 4.1 or 4.2 install??
Thanks for your great job Christoph.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Paul de Weerd [EMAIL PROTECTED] wrote: 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 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: 1. Upstream patches already exist [1] in response to Ormandy's bug report [2] fixed, virtualization is worse than real hardware. And it'll be hard to prove all the bugs are fixed. 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 [3], that virtualization is a very, very good tool. Paul 'WEiRD' de Weerd [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
Re: About Xen: maybe a reiterative question but ..
In the scientific cluster computing and enterprise spaces, it's already well demonstrated, by many, many practitioners in those fields [3], that virtualization is a very, very good tool. 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.
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 10:59 AM, Theo de Raadt wrote: You don't build better security by building another gigantic layer. That is obvious to anyone who actually works in the field. 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. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Paul de Weerd wrote: On Wed, Oct 24, 2007 at 08:31:26AM -0500, L. V. Lammert wrote: | On Wed, 24 Oct 2007, Henning Brauer wrote: | | * [EMAIL PROTECTED] [EMAIL PROTECTED] [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. 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
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.
Re: About Xen: maybe a reiterative question but ..
At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: 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. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. 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
Re: About Xen: maybe a reiterative question but ..
I am just astounded by how some people who love virtualization keep making the same mistakes. Are you even listening? 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 ^^ Who said it actually seperates? 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 ^ You believe it does seperation and isolation? maximizing h/w utilization. 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.
Re: About Xen: maybe a reiterative question but ..
At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: 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. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. 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]. 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.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Christoph Egger [EMAIL PROTECTED] wrote: - aio(2) support creaking along. - POSIX ptsname() (this is used in a python binding module) dunno. - newer gcc version due to a structure padding bug with an alignment attribute hidden in a typedef (this is fixed in gcc 3.4) I use gcc 4.2 from the ports FYI. can you tell me which structure? attribute packed/aligned should never be used on typedefs because of this. it's one of those astounding things that gcc compiles, but then neglects to warn that it completely ignores the attribute. Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers should be in /usr/include/uvm/, for example. so that userland programs can talk to the kernel. what's the problem? they're not in the way are they? (where else would they go?)
Re: About Xen: maybe a reiterative question but ..
At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. This last sentence is such a lie. 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. The security benefits are at the application level, *NOT* at the OS level. 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. 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
Re: About Xen: maybe a reiterative question but ..
L. V. Lammert wrote: At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: 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. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. 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. When all this crap/risky software is running on separate boxes, you only have the network as an attack path to the other crap. This path is well understood, and there are established policies, best practices, tools that you can use to control and monitor your network. Now, when you put all this crap onto the same hardware, you remove the well known and trusted hardware from underneath the already crappy setups, and introduce a (possibly crappy/unknown) software layer that claims to provide isolation. Advantages: 1. buzzword compliance 2. some 'cool features' like snapshots and migration 3. perhaps better utilize the (high performance/ultra expensive) hardware you just bought to gain 1 2. Disadvantages: 1. isolation between the systems is in fact *reduced* 2. whole new attack paths through the VM system are introduced: you get access to the host OS, not necessarily through a guest, you compromise ALL guests. 3. A compromised guest could, at the very least cause stability problems and DoS affecting ALL the guests, at worst compromising the host OS. Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. You do not get security improvements out of using a VM system at all. Look at the list above. This is *not* some kernel hackers' out of the world scenario. This is just common sense and security best practices that every enterprise should be aware of. You do have some benefits in terms of management and flexibility, and perhaps faster recovery. VMs are invaluable for development/testing. But there is absolutely *no* security improvement at all. You may accept the risks in favor of the benefits to your business, but do not claim that you are actually improving the security. Can
Re: About Xen: maybe a reiterative question but ..
At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. This last sentence is such a lie. 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. The ends justify the means, even if the means don't actually perform as you declare? 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. This has NOTHING to do with security. You are just saving pennies. You did zero actual security assessment, so you are just talking out of your ass. 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. 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. 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.
Re: About Xen: maybe a reiterative question but ..
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/
Re: About Xen: maybe a reiterative question but ..
Can Erkin Acar wrote: L. V. Lammert wrote: At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: * L. V. Lammert [EMAIL PROTECTED] [2007-10-24 16:46]: 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. dream on. that is what marketing wants to tell you. in fact the isolation is incredibly poor. 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. When all this crap/risky software is running on separate boxes, you only have the network as an attack path to the other crap. This path is well understood, and there are established policies, best practices, tools that you can use to control and monitor your network. Contrariwise, there is *some* security benefit to running all the services virtualized, compared to running all the services on the same machine but *not* virtualized. In that case, though, you're not getting any improved resource utilization, and you're going with a very complicated and unaudited system (with arbitrary code execution bugs coming to light *this month*) to achieve improved security. You can achieve a lot of the promises of virtualized servers (with fewer moving parts, and more code audits) using chroot and login classes to run many services on a single big machine. -- Matthew Weigel hacker [EMAIL PROTECTED]
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, L. V. Lammert [EMAIL PROTECTED] wrote: At 12:03 PM 10/24/2007 -0600, Theo de Raadt wrote: Anything we can do to increase security, *including* setting up VMs (of any flavor) is an improvement [that also increased hardware utilization]. This last sentence is such a lie. 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. 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
Re: About Xen: maybe a reiterative question but ..
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.
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Jack J. Woehr [EMAIL PROTECTED] wrote: 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. My VM: The World. -- This officer's men seem to follow him merely out of idle curiosity. -- Sandhurst officer cadet evaluation.
Re: About Xen: maybe a reiterative question but ..
* Darren Spruell [EMAIL PROTECTED] [2007-10-24 21:48]: 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? 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 certainly not. That simply segmenting networks with VLANs can't be considering to fully isolate them? 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, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: About Xen: maybe a reiterative question but ..
It's a very simple concept. There is *nothing* in any virtualization software that makes having it *more secure* than not having it at all. Period. --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
On Wed, 24 Oct 2007, Theo de Raadt wrote: 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. Nah, I like steak, I hate enterprise computing. 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: About Xen: maybe a reiterative question but ..
On 10/24/07, Henning Brauer [EMAIL PROTECTED] wrote: 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. 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.
Re: About Xen: maybe a reiterative question but ..
On Oct 24, 2007, at 4:16 PM, Henning Brauer [EMAIL PROTECTED] wrote: * Darren Spruell [EMAIL PROTECTED] [2007-10-24 21:48]: 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? 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 certainly not. That simply segmenting networks with VLANs can't be considering to fully isolate them? 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. Why does this continue to pop up in misc@ every year? --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: About Xen: maybe a reiterative question but ..
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. On 10/24/07, L. V. Lammert [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007, Theo de Raadt wrote: 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. Nah, I like steak, I hate enterprise computing. 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
