A thread on the OpenBSD -misc mailing list began by discussing whether or not XEN had been ported to OpenBSD, "is it planned at some point to release a paravirtualized xen kernel for OpenBSD 4.3 or 4.4?" Later in the discussion it was suggested that virtualization should be a priority for security reasons, "virtualization seems to have a lot of security benefits." OpenBSD creator Theo de Raadt strongly disagreed with this assertion, "you've been smoking something really mind altering, and I think you should share it." He went on to describe virtualization as "something on the shelf, [which] has all sorts of pretty colours, and you've bought it", explaining:
"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. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes."
Later in the thread, Theo went on to note, "if the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do." He then suggested that companies marketing virtualization should soften their claims to something supportable, such as, "yes, it [increases] hardware utilization, and the nasty security impact might be low".
From: carlopmart <carlopmart@...> Subject: About Xen: maybe a reiterative question but .. Date: Oct 22, 4:05 am 2007 Hi all, I know that time to time somebody do the same question, but I need to know it: is it planned at some point to release a paravirtualized xen kernel for OpenBSD 4.3 or 4.4??? In March'08 I need to virtualize two openbsd servers under xen (host doesn't supports HVM guests). But if it is not possible, I will migrate to NetBSD ... Many thanks. -- CL Martinez carlopmart {at} gmail {d0t} com
From: ropers <ropers@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 22, 2:36 pm 2007 On 22/10/2007, carlopmart <carlopmart@gmail.com> wrote: > Hi all, > > I know that time to time somebody do the same question, but I need to know it: > is it planned at some point to release a paravirtualized xen kernel for OpenBSD > 4.3 or 4.4??? It already exists. You can run OpenBSD DomUs (ie. run OpenBSD as a Xen "guest"**), but AFAIK you still can't run OpenBSD Dom0s (ie. run OpenBSD as a Xen "host"**). See http://www.ropersonline.com/openbsd/xen/ ** This is a flawed metaphor, because Xen is a _hypervisor_, NOT an emulator. The Domain U installs are not really running as guest OSes, and the Domain zero installations are not really running as host OSes. But you need at least one Dom0 (which when I last looked into this still could not be OpenBSD) and you can install OpenBSD as a DomU. I know very little, apart from having been curious once. If you want to know more, you probably really should talk to Christoph Egger, who did the actual porting work. Thanks and regards, --ropers
From: Nick Guenther <kousue@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 22, 3:11 pm 2007 On 10/22/07, ropers <ropers@gmail.com> wrote: > On 22/10/2007, carlopmart <carlopmart@gmail.com> wrote: > > Hi all, > > > > I know that time to time somebody do the same question, but I need to know it: > > is it planned at some point to release a paravirtualized xen kernel for OpenBSD > > 4.3 or 4.4??? > > It already exists. You can run OpenBSD DomUs (ie. run OpenBSD as a Xen > "guest"**), but AFAIK you still can't run OpenBSD Dom0s (ie. run > OpenBSD as a Xen "host"**). > > See http://www.ropersonline.com/openbsd/xen/ > > ** This is a flawed metaphor, because Xen is a _hypervisor_, NOT an > emulator. The Domain U installs are not really running as guest OSes, > and the Domain zero installations are not really running as host OSes. > But you need at least one Dom0 (which when I last looked into this > still could not be OpenBSD) and you can install OpenBSD as a DomU. > So that means that OpenBSD has code in it right now that detects if it's running under Xen and paravirtualizes itself? -Nick
From: Jeff Quast <af.dingo@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 22, 6:07 pm 2007 On 10/22/07, Nick Guenther <kousue@gmail.com> wrote: > On 10/22/07, ropers <ropers@gmail.com> wrote: > > On 22/10/2007, carlopmart <carlopmart@gmail.com> wrote: > > > Hi all, > > > > > > I know that time to time somebody do the same question, but I need to know it: > > > is it planned at some point to release a paravirtualized xen kernel for OpenBSD > > > 4.3 or 4.4??? yum > > It already exists. You can run OpenBSD DomUs (ie. run OpenBSD as a Xen > > "guest"**), but AFAIK you still can't run OpenBSD Dom0s (ie. run > > OpenBSD as a Xen "host"**). > > > > See http://www.ropersonline.com/openbsd/xen/ > > true > > But you need at least one Dom0 (which when I last looked into this > > still could not be OpenBSD) and you can install OpenBSD as a DomU. Only recently using HVM, not paravirtualization > So that means that OpenBSD has code in it right now that detects if > it's running under Xen and paravirtualizes itself? > no I would like to vouch for openbsd working great as a guest, but my guest has crashed a dozen times. However I think this is due to the debian linux dom0 having broken sata code for the controller in use. dom0's dmesg is filled with debug statements from sata related places in the kernel that should never be printed. We're in a messy de-centralized linux development world trying to get a stable dom0 patched together. It sucks. The paravirtualization port appears dead to me. I've tried to keep up on it, but the guy's blog no longer mentions it, his repository is often down, and when it is up the commits do not appear to be very frequent. Also his blog hasn't mentioned it in a year or more. http://hg.recoil.org/openbsd-xen-sys.hg http://anil.recoil.org/blog/
From: ropers <ropers@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 22, 7:11 pm 2007 On 23/10/2007, Jeff Quast <af.dingo@gmail.com> wrote: > I would like to vouch for openbsd working great as a guest, but my > guest has crashed a dozen times. However I think this is due to the > debian linux dom0 having broken sata code for the controller in use. > dom0's dmesg is filled with debug statements from sata related places > in the kernel that should never be printed. We're in a messy > de-centralized linux development world trying to get a stable dom0 > patched together. It sucks. This is what I meant to hint at earlier: Running an OpenBSD DomU in connection with, say, a Linux Xen Dom0 possibly makes that OpenBSD installation subject to bugs in the hypervisor/Dom0, and that may be unavoidable. The question is, is that a worthwhile trade-off? Is this a reason not to support Xen? Or should the user be given that option regardless of the inherent limitations and consequences? --ropers
From: Luca Corti <luca@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 23, 4:03 am 2007 On Tue, 2007-10-23 at 01:11 +0200, ropers wrote: > unavoidable. The question is, is that a worthwhile trade-off? Is this > a reason not to support Xen? Or should the user be given that option > regardless of the inherent limitations and consequences? A proper Dom0 port of XEN to OpenBSD would solve this by removing the linux dependency. However this would probably require a significant effort on OpenBSD side and a XEN Hypervisor code audit. Also from earlier discussion on the list it seems this kind of virtualization may impact on security, which is in direct contrast with OpenBSD goals. Can someone elaborate more on this? ciao Luca
From: <adam.getchell@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 23, 8:57 pm 2007 Virtualization seems to have a lot of security benefits. Rootkits can lie to DomU but not Dom0, and of course snapshotting, migration etc is *really* nice. Dom0 in OpenBSD in a current Xen implementation (with HVM) would be a dream. I'd switch wholesale, and buy a CD for every server (as I do now). But doubtless there are a whole host of issues, kernel, SMP, bootloaders (I found OpenBSDs bootloader to be superior to grub in Ubuntu 7.10, it detects media bay HDs, and the installer is fast, efficient, and doesn't crap out on certain video cards/monitors), an LVM, iSCSI support -- and I have no code to contribute, so I will merely remain hopeful without expectation. I tried NetBSD Xen, but it seemed the worst of both worlds. Pf circa 3.7, hacks for grub, old version of Xen (2.x series IIRC) without support for the most interesting features, not the same level of security focus, etc. So I just picked the best tool for the job. I'm happier our webservers are now on OpenBSD with CARP failover. -- "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -----Original Message----- From: Luca Corti <luca@leenoox.net> Date: Tue, 23 Oct 2007 10:03:42 To:ropers <ropers@gmail.com> Cc:Jeff Quast <af.dingo@gmail.com>, OpenBSD-Misc <misc@openbsd.org>, Nick Guenther <kousue@gmail.com> Subject: Re: About Xen: maybe a reiterative question but .. On Tue, 2007-10-23 at 01:11 +0200, ropers wrote: > unavoidable. The question is, is that a worthwhile trade-off? Is this > a reason not to support Xen? Or should the user be given that option > regardless of the inherent limitations and consequences? A proper Dom0 port of XEN to OpenBSD would solve this by removing the linux dependency. However this would probably require a significant effort on OpenBSD side and a XEN Hypervisor code audit. Also from earlier discussion on the list it seems this kind of virtualization may impact on security, which is in direct contrast with OpenBSD goals. Can someone elaborate more on this? ciao Luca
From: Theo de Raadt <deraadt@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 23, 9:14 pm 2007 > Virtualization seems to have a lot of security benefits. You've been smoking something really mind altering, and I think you should share it. 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. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it. That's all x86 virtualization is.
From: Henning Brauer <lists-openbsd@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 4:18 am 2007 * adam.getchell@gmail.com <adam.getchell@gmail.com> [2007-10-24 03:03]: > Virtualization seems to have a lot of security benefits seems? to whom? to people who never wrote a line of code and don't understand how things work? -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
From: L. V. Lammert <lvl@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 9:31 am 2007 On Wed, 24 Oct 2007, Henning Brauer wrote: > * adam.getchell@gmail.com <adam.getchell@gmail.com> [2007-10-24 03:03]: > > Virtualization seems to have a lot of security benefits > > seems? > to whom? > Virtualization provides near absolute security - DOM0 is not visible to the user at all, only passing network traffic and handling kernel calls. The security comes about in that each DOMU is totally isolated from the the others, while the core DOM0 is isolated from any attacks. 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 lvl@omnitec.net Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net ================================================
From: Henning Brauer <lists-openbsd@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 11:12 am 2007 * L. V. Lammert <lvl@omnitec.net> [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, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
From: L. V. Lammert <lvl@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 1:48 pm 2007 At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: >* L. V. Lammert <lvl@omnitec.net> [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
From: Theo de Raadt <deraadt@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 2:03 pm 2007 > At 05:12 PM 10/24/2007 +0200, Henning Brauer wrote: > >* L. V. Lammert <lvl@omnitec.net> [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.
From: L. V. Lammert <lvl@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 2:41 pm 2007 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
From: Theo de Raadt <deraadt@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 3:46 pm 2007 > 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.
From: L. V. Lammert <lvl@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 4:31 pm 2007 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 lvl@omnitec.net Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net ================================================
From: Kevin Stam <harpalus.como@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 5:04 pm 2007 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 <lvl@omnitec.net> 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 lvl@omnitec.net > Chief Scientist Omnitec Corporation > Network/Internet Consultants www.omnitec.net > ================================================
From: Theo de Raadt <deraadt@...> Subject: Re: About Xen: maybe a reiterative question but .. Date: Oct 24, 5:41 pm 2007 > You have failed to satisfactorily explain why running a specific application > in a VM is more secure then running it in a standard OS. It's nonsense that > you think it's more secure that way. It saves a lot of money, yes -- you > don't necessarily want a separate box just to run an application - but > that's not the debate here. The debate is about security, and I'm amazed > that you think a virtual environment is somehow more secure then a dedicated > non-virtual environment. It's that extra 4MB of poo code, that is what makes it more secure. It's slippery and sticky at the same time, so that the application attackers slip and slide and fall into the page boundaries. If the actual hardware let us do more isolation than we do today, we would actually do it in our operating system. The problem is the hardware DOES NOT actually give us more isolation abilities, therefore the VM does not actually do anything what the say they do. While x86 hardware has the same page-protection hardware that an IBM 390 architecture machine has, modern PC machines are a mess. They are architecturally so dirty, that parts of the video, keyboard, and other IO devices are interfaced with even to do simple things like context switching processes and handling interrupts. Those of us who have experience with the gory bits of the x86 architecture can clearly say that we know what would be involved in virtualizing it, and if it was so simple, we would not still be fixing bugs in the exact same area in our operating system going on 12 years. We know what a VM operating system has to do to deal with the PC architecture. It is too complex to get perfectly right. And now you've entered into the layered approach where *any error* in the PC model exposed to the client operating system is not just a crashing bug -- it is now exploitable. It might be nice, but it is stupid. And anyone who thinks there is any security advantage at any level knows nothing about PC architecture.
| Resetting the bios password for Toshiba Laptop | 1 hour ago | Hardware |
| Lock contention | 14 hours ago | Linux kernel |
| PAGE_ALIGN | 1 day ago | Linux kernel |
| bootsplash patch for kernel 2.6.25.3-zen1 | 2 days ago | Linux kernel |
| sysfs_create_group() | 2 days ago | Linux general |
| temporary mapping | 3 days ago | Linux kernel |
| ATI ES1000 driver | 3 days ago | Linux general |
| Can anyone tell me the Procedure to create an init ramdisk using busybox | 5 days ago | Linux general |
| mapping of High Memory to ZONE_NPRMAL | 1 week ago | Linux kernel |
| Page global directory | 1 week ago | Linux kernel |
OpenBSD still exists? Too
OpenBSD still exists?
Too bad. The world would be better without security
fanboys in general. And exactly these are attacks against the
other security fanboys in general - i see kindergarten fights
happen here. To a bigger extent than on the Linux Kernel
Mailing lists too.
There is more to the world than security.
Yes, luckily it does.
"OpenBSD still exists? Too bad. The world would be better without security fanboys in general."
Yes, much better. For one, we'd still be using telnet rather than ssh. Those bastards!
Anyway, next time you want to troll, try to be a bit more convincing. Thank you.
SSH
Well, a variety of other SSH clients exist, as well as the official SSH distribution. Just because the OpenBSD guys released an as-of-now widely used flavor of the SSH server + SSH client, does not mean that without them, we would not have a freely available SSH server + SSH client.
Regardless, I appreciate the hard work by the OpenBSD folks, and appreciate multiple viewpoints. This world would be far more boring [and possibly less secure] without the likes of Theo de Raadt :)
code auditing
I sat on the cvs-commit mailing list for a short while a few years back.
I remember one was a routine fix for time synchronization in the IP stack. It wasn't listed as a security flaw, I suspect other subsystems protected that bug from being exploitable. Just a routine code-walk fix.
Three weeks later, Redhat, Freebsd and Debian had announced updated kernel packages for fixing network time synchronization features.
Six months later, equivalent patches had been released for on of the major Unix's.
18 months later, Microsoft had released a security update to their Operating system for I suspect the related fix (being derived from BSD IP stack).
SSH is only _one_ of the many gifts the OpenBSD group has given to the world.
Sure, but...
Sure, but then we'd be paying for it commercially as we would the average commercial Linux distro (or pirating it like a Linux distro) and then wishing they weren't a monopoly and begging for a Free, Open Source implementation of it.
Thank you OpenBSD for this and all other goodies, also thank you that it's portable to Linux and other OS's too. I've started slowly upgrading and migrating some Linux boxes to OpenBSD with much greater success than Linux has had thus far - great work! I've never seen an OS so clean and well done as OpenBSD so far either.
That may be true, but he was
That may be true, but he was talking about "security fanboys", not "the OpenBSD project", and all of those other SSH implementations (at least, the ones that actually work) have one thing in common:
They were written by security fanboys. So yes, without security fanboys, we'd all be using telnet, or something equally stupid.
I thought this comment was a
I thought this comment was a joke at first. I'm still not convinced. As far as operating systems are concerned, the two most important goals are security (see OpenBSD) and stability (see NetBSD). Speed is third (see Windows). Correctness is the most important thing, and correct code is stable and secure. If it is not correct, it is worthless.
*cry*
Speed is third (see Windows).
I'm at a loss of words to describe the ignorance of this particular fellow. I'll just go back to crying.
I am just hoping he meant
I am just hoping he meant speed of development, probably not the same "speed" you were thinking of.
speed of development... as
speed of development... as shown with vista's development time.... ;)
porl
I was trying to be succinct,
I was trying to be succinct, and apparently, people dislike that. For the record, stability is one of the main goals of NetBSD developers. And by speed, I do not mean speed of development. I mean that it's designed to run fast. Windows does run faster than Linux in many ways. For example, programs start up way faster, and I run Gentoo, so everything should be pretty much optimal. And I would have said that Linux's main priority was speed, but I thought it wouldn't fly well on a mainly Linux website.
While I'm at it, another Linux priority is to get as many options into the kernel as fast as possible.
Sorry for digressing, but
Sorry for digressing, but here's a rant:
In my opinion, the main reason why Windows is still faster on the desktop is that most of their current GUI framework was built back in the days of Windows 95, and the framework is so fragile that it has stopped them from adding too many new features to bloat it further. Back in 1995, Microsoft was way more performance-conscious than the open source world in 2007, simply because the hardware was orders of magnitude slower.
For comparison, in the Unix land you can see GTK+, Qt, window managers, breaking world records for bloat with each new release. Fast and lightweight code can still be written, but it's simply not a focus anymore. Want to see performance in the Unix land? Run a FLTK application; it will blow your mind.
So the metric you are looking for is not "how fast", it's "how lightweight". Another obvious example of "lightweightness" vs. speed is Java: you have all seen the benchmarks suggesting that various Java JITs are on par with C compilers. But regardless, Java is still sluggish and annoying in comparison, simply because it is (in most cases) not as lightweight as C code.
OpenBSD focuses on correct code
Having followed linux kernel development, I would say it was mostly focused on speed than anything else.
Speed?
speed? I thought they were focused on poorly done code/code bloat.
Stability, see NetBSD? I
Stability, see NetBSD? I really can't agree with this. NetBSD more for compatibility on a wide variety of hardware (not too sure what the number is now).
With OpenBSD, they don't just review the code on a regular basis for 'security holes', but it allows them to audit the code for other BUGS that cause instability issues.. But yes, compared with Windows and say, Linux, NetBSD is still much better for stability.
It does
Security "fanboys" are what keep you safe behind the scenes.
There is a lot involved in the world, security is a big part of it. I sure hope you don't handle IT network security for my bank, I like being able to go out for a nice steak dinner and not have a problem when it comes time to pay because someone just emptied all my bank accounts.
I currently do IT for a company, we're researching vmware, we currently have a lot of applications on their own servers, big waste of resources, and time is coming to replace servers and I don't want it to turn into a big waste of money either. I have to carefully choose which systems we can run in a virtualized environment, the potential for a security breach between virtualized OSes is definitely there, but like anything in this industry, its never 100% secure, you have to choose what you do carefully or you'll be opening the doors for huge data mining to take place and then you're F'd in the A my friend. You get what you pay for.
Those tinfoil-hat security fanboys do have their uses, you know.
I use OpenSSH on a daily basis and have enjoyed OpenBSD's reference IpSec suite to test new hardware for compatibility. I have to admit, though, that I have not yet gone back to running OpenBSD after my (486) firewall burnt out. I'm simply not that deep 'into the scene' anymore
Whilst there are good arguments to virtualization (along the lines of LVM and Quota for your hardware),
it should not be regarded as a security tool (for arguments stated above)
What Virtualization -does- allow you to do, is set up a fully featured Development-, Test- and Acceptance- server on the same piece of hardware. With a bit of trickery it even allows on-the-fly hybernation-type full backups and restores os a machine, without even stopping the machine itself. Like an Ignite tape on steroids.
I think the original question was a reasonable one, if only for the wrong reasons.
Virtualization allows for fully-controlled testing environments.
Copying the full DomU currently running on the firewall and restoring it to a testing/development server gives you an environment to test a new firewall design or to examine a hacked machine in a sandbox environment, without the hacker's scripts/tools finding out about it, allowing for forensic examination.
It's a tool, not a security measure.
Apples and Oranges?
Saying "more secure" or "less secure" is meaningless without context. I'm sure that they're right and that setting up multiple virtual guest OS instances on a single piece of hardware is less secure than setting up multiple boxes.
If you only have budget for a single server then setting up multiple VM instances may be more secure than setting up a single box for the various required services.
beat me to the punch
It's useful to talk about security in the abstract--however security is never truly decoupled from the real world.
it *will not* be any more
it *will not* be any more secure, but it *might* not be less secure
Weakest Link
Unless you put up one OS or set of services in one instance, which then becomes the weakest link in the chain. Such as, running OpenBSD and Windows as guest instances. OpenBSD now becomes susceptible to all the Windows exploits... or vice-versa.
Different perspectives
TdR: "You've already made the decision to decrease security by
de-compartmentalizing onto one physical box, so you are just thrilled
with the ability to decrease security more by de-compartmentalizing
the software further."
I look at virtualization from the opposite angle: I have money to spend on software, hardware, end-user support, and administrator time. Security is one of the axes on which such a system (or systems) are measured. End-user productivity, maintenance costs, failure tolerence, etc. are other things which might (or might not) matter to me.
Which is more secure:
. 3 applications, each running in a hypervisor supervised system
. 3 applications, running on a single system
. 3 applications, each running on a different system
I claim that the answer is not clear, and depends on all of the above factors. Saying that virtualization always decreases security is just hyperbole.
Note that I'm not claiming that Xen is the greatest example of a virtualization system; I do claim that a paravirtualized hypervisor can provide a narrower, more well-defined, and possibly more secure interface between 2 Unix-like operating systems compared to the interface between user-space and a Unix-like operating system.
Shush, you!
Damn your pragmatism. If we wanted to hear about you and your reasonable ways, we'd pound it out of you!
Though if you're talking about security in absolute terms, TdR is right; Option 3 is really the most secure assuming you have sufficient resources to dedicate to running and maintaining those machines and the software upon them. The thing I've noticed about the free/open software community is that the cost of labor does tend to be overlooked because we're all so used to spending a great deal of time hacking on, improving, and maintaining our own software. That's part of the price you pay for not purchasing a shrinkwrapped box.
It seems you didn't
It seems you didn't understood Theo's points: using virtualized environment does AUGMENT security holes BY DESIGN because the hardware architecture of the PC platform has flaws that when shared by multiple virtual machines are exploitable to escape the VM.
So an OS running in a virutalized environment is less secure that the same OS running directly on the hardware.
Also, every new layer of complexity in a system increases the risk of security holes, especially when the failures of the different layers can be combined.
no
1) Did I say anything about PCs?
2) I assert that a paravirtualized VM is an easier interface to {audit/understand/secure} than a Unix-alike kernel<->userspace (or kernel<->hardware for that matter) interface.
To support 2, I offer the following proposition:
I would like to (for some reason) run an operating system which I, myself, have never audited, in whole or part. I assert that running this operating system under a VM is more secure than running it on a physical hardware.
You might say that this is twisting the definition of security (security from vs security of). I claim that both are security, and anyone who argues that running on the bare metal is more secure than running against a paravirtualized interface is silly. In the case of the PC, you can even use Theo's dislike of PC hardware to make this argument.
HTH.
"and anyone who argues that
"and anyone who argues that running on the bare metal is more secure than running against a paravirtualized interface is silly."
*sigh*
http://taviso.decsystem.org/virtsec.pdf
Anyone who argues and does not understand the principals involved will be made to look silly.
@Oliver http://en.wikipedia.o
@Oliver
http://en.wikipedia.org/wiki/Netiquette
@Theo
Thank you for stating what many SA's already know. Hopefully, we can get the remaining 10% to come around or leave the industry. Virtualization does nothing more for security than chroot does, which is "nothing at all". Know that by stating it in such a rude and inflamitory way serves only to enlighten people about security, and drive them to choose an alternative kernel (alternative bieng one that you have nothing to do with).
Please get help,
Frank
No response to logical debate
Hello,
I'm the OP that Theo first flamed, having started and extensively consulted on OpenBSD deployments at the University of California, Davis.
In the thread, I've made references to research and presentations done by my colleagues in the UC system discussing Xen security advantages, particularly work done by Bill Broadley at the Computational Science & Engineering group at UC Davis.
I've yet to see logical responses to points posted in this message:
http://marc.info/?l=openbsd-misc&m=119332410721337&w=2
Also, Christoph Egger has done extensive work porting DomU code to OpenBSD (as part of a Google Summer of Code project), and is working on Dom0.
Unfortunately, the OpenBSD developers haven't looked at his patches.
http://marc.info/?l=openbsd-misc&m=119323951310432&w=2
http://marc.info/?l=openbsd-misc&m=119323900009484&w=2
http://marc.info/?l=openbsd-misc&m=119324065212680&w=2
Except possibly Ted Unangst:
http://marc.info/?l=openbsd-misc&m=119324997127856&w=2
looking at my responses (in this thread)
It's too easy to slide into advocacy and silly flaming.
/me bows out
You're ignoring the point,
You're ignoring the point, putting an insecure system over top of a secure system is making the system less secure.
Security is all about compartmentalization
Over decades of evidence that operating system kernels are not secure, you still dare to make the assumption that they are?
You simply cannot solve security on a single level alone. If you have a single level of security, and this level is compromised, your entire system is compromised. In fact, Unixes have never supported just a single level of security; there have always been two levels: normal user and root user. Or a bit more abstractly, user level and kernel level (equivalent to root because root can inject code into the kernel). In many situations there is another layer of security provided by the application — e.g. a web browser has less privileges on the server than the HTTP server process; this is enforced by the HTTP daemon.
Given these three levels of security, if an attacker wishes to gain control over the whole system, they first have to compromise an unprivileged account on the system, then compromise the root account. Yes, privilege escalation bugs exist, and nevertheless we don't call this "putting an insecure system over top of a secure system", because this is simply untrue.
What virtualization does is that it adds yet another layer of security: To compromise the whole system from bottom up, the attacker has to break all layers: application, user, kernel and hypervisor.
And sometimes there are shortcuts you can take. A flaw in the kernel's TCP stack may compromise the whole kernel; the same of course applies to hypervisors. But this is the only downside.
In fact, the kernel<->hypervisor interface is in many ways simpler than the user<->kernel interface; it is conceivable that it could also have less bugs. Just consider that OS kernels have existed for decades, hypervisors/virtualizers have had a much shorter lifetime — no doubt they will have more bugs in their current stage. Just give them some more time to settle down and sort out the issues.
"a web browser has less
"a web browser has less privileges on the server than the HTTP server process; this is enforced by the HTTP daemon."
eh ?
How does that work then ?
This is somewhat irrelevant,
This is somewhat irrelevant, but I'll clarify anyway: A web browser (or any HTTP client) cannot just access any file on the server, which would technically be readable for the HTTP daemon; the daemon sanitizes all user-specified paths and checks whether they are within the /var/www/htdocs directory.
Similarly, the HTTP daemon could launch any process under its privileges, but it does not permit the HTTP client to do so without checking that the script lies in cgi-bin.
This means that to get the HTTP server to disclose/execute arbitrary files, you have to break the first layer of security — the application.
> I've yet to see logical
> I've yet to see logical responses to points posted in this message:
>
> http://marc.info/?l=openbsd-misc&m=119332410721337&w=2
point one has been refuted several times in the thread.
point two is irrelevant. does it matter that one person did not demonstrate an attack? What matters is one person who does.
Ditto with point three.
my primary concern with virtualization actually isn't security. it would have to be stable enough for my systems to stay up for me to worry about that.
Logical debate
Really? Where?
Proof by assertion doesn't count.
And again, where is the demonstration of a successful DomU->Dom0 attack against current Xen? Certainly, that's the standard that OpenBSD uses in its security.
And how does detecting rootkits not count for security?
No one's claiming the primary focus of virtualization is security. But there are some nice side-effects there, too.
On the flip side, there's a lot of malware research going on to virtualize attacked systems as the means to construct better rootkits.
Just ingore the OBSD
Just ingore the OBSD fanboys. Most of them don't know anything about what Theo is talking about they just assume that he is right and knows everything. Their proof that your wrong is that Theo disagrees with you.
Also bashing x86 is popular. (Everybody should be using PPC, ya know!) That way through their computer tastes they can yet again show their superiority over the wintel crowd.
If you want proof that they don't realy understand what is going on just ask them:
"Can FreeBSD's Jail mechanism be used to increase security? "
If they say 'yes' and still tell you that virtualization is worthless for security you can know for a fact that they are clueless. (you can almost hear their brains clicking away trying to figure out how to explain to me that a weaker form of isolation (bsdjail) is better then a stronger form of isolation (xen). It's going to be tough for them to stay on the BSD side of things with that arguement. That is unless they think that Freentil is as worthless as Lintel)
You and I both know that implimenting security costs a lot. It costs a lot in term of time, hardware, and effort.
For example:
Sure if your running a web server and you have three servers with one being the front end (caching reverse proxy/firewall) and one being the webapp server and another being the database server.
That's the ideal situation and is the one that Theo would be advocating.
But what if you can't afford to have 2-3 seperate machines? What if you can't afford the extra space on the rack at the colocation? Are you doomed to running your firewall on the same machine that your running your database and web apps?
Nooo... because you can use virtualization to divide up the machines and isolate it.
You can provide a locked down base system that simply acts as host.. no network access no nothing. It runs no services, runs no gui, runs nothing except to help abstract the drive space and network interface.
On top of that you can run your seperate machines in virtualization. In order to break out of the VM sandboxes any attacker would have to find a flaw in your servers, exploit that. After they get access to the user account that the service is running in they have to find a local exploit in that OS to get root. Then after that they need to find a exploit in Xen or whatever VM technology you have in order to get root on the base system and then access the other servers.
Certainly it's better to run seperate machines, but you can't always run seperate machines.
Then in addition to that it provides a cheaper way to impliment IDS like AIDE and snort. That's not possible to do with a single OS machine. It's mostly pointless from a security standpoint.
Obviously it would be ideal to have a way to remove drives from your server or boot up from read-only media in order to correctly impliment Tripwire or AIDE. And it would be superior to have a switch with a tap port or a passive tap on your ethernet backbone somewere so that you can impliment a undetectable dedicated SNORT box... but you obviously can't do that in the (very common) situation I described and most companies (which are small to medium sized businesses) can't afford to do that even if they have a dedicated room for networking and server equipment.
All this shit is like _duh_.
w00t, UCD CS&E ftw!
w00t, UCD CS&E ftw!
Response to logical debate
Just read the slides you mentioned in the post. Nice research. It basically states that DomU -> Dom0 access is "difficult" and then proceeds to describe a system for checking the file integrity of DomU from Dom0.
However, presenting a "Possible, even nice, security related use" of VM's does not show that is a "secure" solution for replacing multiple boxes.
When you wrote "Virtualization seems to have a lot of security benefits", you were probably thinking about the above research.
However, most people think about VM and security in terms of isolation.
Quoting http://marc.info/?l=openbsd-misc&m=119323710806321&w=2
> 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.
The above was the post that really fanned the flames, and the research about 'security related use' was not relevant anymore.
It is obvious that there are many cool things that you can do with a VM setup. Snapshots, recovery, migration all have obvious and sometimes not so obvious security/recovery/forensics related _uses_.
I would not trust a VM layer to provide isolation between my critical applications. I would use a VM, on an isolated box, for investigating an unknown, possibly malicious program for the snapshot and rootkit detection benefits (Though some recent malware try to detect a VM and change their behaviour. Now, what if the malware author happened to have a 0 day exploit for the particular VM system I am using. Hmm ...)
As long as you know and understand the risks, you can use any system, any way you like. But making blanket statements like "Virtual Machines are absolutely secure" is very dangerous. Not only to the one making the statement, who probably deserves to get burned, but to others who believe these statements and fall into a false sense of security.
Can
Virtualization and security.
Hi!
Joanna Rutkowska from invisiblethings.org has some interesting things to say about this topic. Let's just say that security is an issue....
Check: http://bluepillproject.org/
and
http://www.invisiblethings.org/
-Tryggve Knutsson
This whole thread is pretty
This whole thread is pretty ridiculous, people are spouting hyperbole left and right on both sides.
Virtualization in and of itself does not magically give you better security, that should be pretty obvious. If implemented poorly, it surely could open up a lot of holes, and I don't doubt that there are some in existing systems.
However, a hypervisor's interface is much much smaller and simpler than the interface for an operating system. So that weakens the "operating systems are insecure, therefore hypervisors must be just as bad" argument.
People have mentioned the x86 architecture being messy and making isolation difficult. This is true, it has definitely made virtualization tough, especially on systems before Intel and AMD released their HV systems allowing for full virtualization. However, I haven't seen any sort of proof or even specific evidence that would indicate that the x86 architecture makes it impossible to properly isolate a VM, or that current offerings from Xen or VMware or what have you don't properly isolate VMs.
That said, this is my main point: the possible security benefits of virtualization are not inherent in virtualization itself, but are made possible by it. Specifically, the knowledge of what a VM is doing can allow you to do a lot of things that would otherwise not be possible, at least without making specific modifications to the guest operating system, something which is usually either impossible (see: Windows, unless you are MS), or impractical (if you need to run a wide variety of guest operating systems).
In short, the idea is that virtualization has both wins and losses in the area of security.
To stoop to the level of our friend Theo here:
"And anyone who thinks there is any security advantage at any level knows nothing about PC architecture."
I would respond:
"Anyone who thinks that there are no potential security advantages to a virtualized environment knows nothing about PC architecture OR virtualization."
If I were an asshole.
PC arch is a mess
True, PC arch is a mess. But most attacks today are focused on userland applications and thus the virtualization practically increases security.
If you want a *real* virtualization you have to use architectures which were designed for it from the beginning. E.g. IBM POWER. Linux runs on those pretty well.
BTW: The Xen hypervisor control is written on OCaml. I would definitely trust more to OCaml code than to something written in a "buffer overflow please" C code (even if it's made Theo himself).
What about AMD64? x86-64?
What about AMD64? x86-64? Are they a mess too in this regard? If not, I wonder why Apple's servers ditched POWER...
de-railed...
This discussion has been derailed into a discourse on the theory of secure. Secure is a relative term. It is not absolute. The practice of security has more toppings than your average ice cream joint. Theo has made a very solid argument in that the foundation of the "security model" in the architecture he is referring to isn't up to his standard of "secure". Theo (and the BSD community in general) has made immeasurable contributions to the tools us IT folks use every day. I do believe the most secure server I ever ran in production was openbsd on sparc. (remember, secure is relative...) I have also supported some pretty firm NT servers in my time. I have dedicated 12 years of practice to information security and I still learn something new every day.
Successful security practitioners understand that there is no such thing as secure. There is no such thing as secure. The instant you say that (we are secure) to your management is the day you bet your farm. ...and you will lose that bet if you, some half-wit coder, or some other person who happens to pick up the phone on the wrong day, actually puts it on the table (on behalf of you) in front of criminals with intent, time and nothing to lose.
Get out of your box people.
Thank you Theo, I proudly wear the tag of "fanboy". I'll stick it right beside my CISO title.