Let's say I am hosting several services on my server, for instance, email and a web page. I am concerned that the web server software may have unknown vulnerabilities in it, which will allow an attacker to take over my machine. The attacker will then have access not only to my website, but also my emails!

I could solve the problem by simply having two separate physical machines, each one dedicated to a server. If the attacker breaks into the web server, he can only see the web site. To see emails, he must break into the email server.

I don't want to actually buy a new server for each service I'm running, so as a compromise I thought I could use virtual machines. In this model, the host OS runs a secured SSH server and a VM software. For each service, a new virtual machine is created, and configured to provide that service.

My model can be catastrophically defeated in two ways:

  • Attacker breaks into the SSH server, essentially gaining access to all VMs.
  • Attacker finds a security flaw in the VM software, and manages to tunnel out of the compromised VM into the host OS.

However, if both of these are harder to do than simply exploiting a vulnerability in one of the myriad of services I want to host, it seems like the attacker's life has been made much more difficult. He must first realize that the servers are actually VMs on the same machine, then exploit e.g. the web server, and then defeat the virtualization on top of that - this seems harder to do than just exploiting the web server.

My question is, is this sort of strategy actually reasonable and practical for a non-enterprise set up? Do drawbacks like slower performance from running many OSes, disk space wasted on each OS, justify the realistic security gain (if any)?

My primary security goal is to compartmentalize individual services, so that gaining access to the machine through one service (eg. web server) does not immediately provide access to private data of other services (such as emails of the mail server). Every time I add a service to my server, I feel like I'm just adding yet more potential vulnerabilities and exploits that attackers can use and take everything - it would be preferable if, when a flaw in one service is exploited, only that service itself is compromised.

  • Have you seen Docker? docker.com
    – schroeder
    Commented Apr 27, 2015 at 22:56
  • @schroeder I have and it seems like it might be what I'm asking for, but I'm having a lot of trouble understanding exactly what it does. Also, is Docker virtualization as secure as a full-on virtual machine?
    – Superbest
    Commented Apr 27, 2015 at 23:02
  • Docker rests upon LXC, which is almost entirely secure. LXC uses Linux namespaces to isolate groups of processes, and only the user namespace is not entirely finished / tested (well, it might actually be by now). In practice that means that if you're root inside the container, you're also root outside of it (but still need to find a way to escape it). For most non-critical applications, LXC and Docker are secure enough, and they're much more manageable than VMs. Commented Apr 28, 2015 at 10:50

2 Answers 2


Your assumptions are correct. Security by isolation is indeed a good principle to follow.

There is also a whole Operating System which implements this idea on the Desktop: Qubes OS (Which is running on the laptop I'm using to write this).

To get back to your server model, I think one VM per service is a good idea, but it will become resource intensive.

We have been using FreeBSD Jails system for about 8 years here, to replicate exactly what your are talking about: isolating the web server from the database and the mail server and etc.

What we do is that the Jail hosts runs nothing, except the firewall. All services are isolated into jails, based upon their security domain. We treat the host as you would treat Dom0 under Xen.

Since it is not visualization but instead a very much improved chroot like mechanism, it has not the performances impacts of visualization, while adding separation and security. From the inside of a jailed system, it looks like you are running in a virtualized or real environment. The drawback is that you can only run FreeBSD ( I don't mind, but it might not be suitable for you).

I think Docker is similar in its approach, though I only recently started to use it, and it feels more like a development tool than a replacement for a virtual environment.

Though, I think Xen is worth looking at.

  • The closer approach of FreeBSD Jails in Linux world is Linux Containers (LXC). Commented Apr 28, 2015 at 10:24
  • Docker is based on LinuX Containers, themselves based on namespaces, which I personally find more complete than BSD Jails (you can select which services you want to be decoupled from the host among PIDs, UIDs, /etc and network config, hostnames and time shares, mount points, and native IPC mechanisms). It comes with tools that help manage contained services and share Docker containers with the community, which can be very convenient for sysadmins who don't have the expertise to configure more low-level mechanisms such as SELinux or Jails. Commented Apr 28, 2015 at 10:56
  • Thank you for your clarification on Docker. As I said, I started using it really lately (last week) and it was imposed upon me, in a rush. I'll go ahead and look and LXC, looks interesting indeed. Commented Apr 28, 2015 at 15:38
  • 1
    It's pretty cool. Lwn has a nice set of articles on Linux namespaces (starting at lwn.net/Articles/531114) which I used before learning about Docker. Dan Walsh's DockerCon talk last year will probably interest you too: youtube.com/watch?v=zWGFqMuEHdw Commented Apr 28, 2015 at 19:04

If you're using Linux exclusively, you can completely isolate applications (pretty much like what docker does) using systemd:


Applications inside a container have no access to the outside - just make sure they don't run as root.

If you want something more portable, chroots might work for you, assuming you set them up properly.

  • Chroot has got security limitations aimed to be solved by proper Jail / Container systems. Commented Apr 28, 2015 at 10:28
  • 1
    chroot is NOT a security mechanism, and should NOT be used. Commented Apr 28, 2015 at 10:52
  • @SteveDL: Funny, because OpenBSD (one of the greatest authorities when it comes to security) secures several services by running them inside chroots. I'd like to see something supporting that claim of yours.
    – WhyNotHugo
    Commented Apr 28, 2015 at 13:20
  • @WhiteWinterWolf: I realize that, that's why I suggested it as a second choice (if you need portability). Jails/Containers, AFAIK, are not portable.
    – WhyNotHugo
    Commented Apr 28, 2015 at 13:20
  • 1
    @Hugo you can escape a chroot extremely easily if you manage to run with the root uid. chroot doesn't restrict access to OS services other than the filesystem, and that leaves a surface attack far too large for it to be relied upon for confining untrusted code. If you think the fact that OpenBSD uses chroots for specific applications bestows some sort of blessing upon chroots so that they can be used in other contexts with no understanding of their very serious limitations, I don't know what to tell you. lwn.net/Articles/252794 daemonforums.org/showthread.php?t=4027 Commented Apr 28, 2015 at 13:33

You must log in to answer this question.

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