Is running an OpenBSD** using QEMU on an OpenBSD safer then running just natively an OpenBSD?

** = only used for apache + scp + ssh

I'm thinking about running the OS/webserver in QEMU because then I could be "more flexible" to use the securelevel configured to 2:


Are there any other solutions ["jail/chroot" the full OS?]? The bad thing that QEMU is from ports, so it's "less secure"? Performance doesn't matters, only security from OS/webserver side.

  • 1
    If you read the OpenBSD mailing lists at all, you'll learn very quickly that nearly all of the developers frown very heavily on emulation. So, that said, don't expect support from the developers if you find a bug when running under qemu
    – Earlz
    Dec 21, 2011 at 17:52

3 Answers 3


My understanding of the question is that you want to run a webserver and an ssh server only.

First, I'm not sure why you wouldn't be able to able to do this with securelevel set to 2.

Second, if you run qemu as a package/port and you use the kernel module you are adding a device, giving some superuser permissions and generally increasing the attack surface. The time setting this up would be better spent on securing your webserver, perhaps in a chroot (not with the entire OS!).

The idea behind's OpenBSD's security is that you don't have to fuss with it very much and you can spend your time securing applications that run on top with it. Almost always simplicity is the friend of security. Unless you fall into some clearly defined need like tdammers suggested, it's best to hew as closely as possible to the default install with any needed configuration.

  • simpler could be better.. :D so without QEMU Dec 21, 2011 at 3:06

An important point about virtual machines is that they do not make any system more secure. The VM is all about protection between the host and the guest. A server with a security hole, running in a VM, still has a security hole; the only difference is that when the hole is exploited, the attacker gains control of the VM, not of the host. This "increases" security only insofar as the host system can do some things that the VM cannot (e.g. the host system is on some LAN but forces all network activity to and from the VM to go through a tunnel which exits elsewhere; in that scenario, the host system, but not the VM, has access to the LAN, and then it makes sense to use a VM as an extra containment feature).


If you set up your system so that only the guest listens on public network ports (those that are open on the firewall), then you win security in the sense that if someone manages to get into the guest and do some damage, it can be repaired more easily.

Another advantage is that you may be able to limit the guest's resource usage, maybe even kill it off and restart it entirely if it misbehaves; while this cannot completely prevent a resource-based DOS attack, it can at least minimize data loss and downtime.

Yet another situation where this may be useful is if you're running a shared hosting service: by running several virtual servers on the same physical machine, an attacker can only compromise one VM at a time (even if they gain root access), unless they manage to break out of the VM and compromise the guest as well. By comparison, if you have root access on a traditional shared host, you can access all the websites it serves.

Other than that, though, the guest is just as secure as a physical server: if someone breaks into it, your data is exposed just like it would be on a physical server.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .