I have been working with DigitalOcean for a while now and while I do like that they make it easy to start up with a fully functioning virtual machine ready to go. It makes me cringe a little though that I have to trust that nothing was tampered to work with their systems. If they did an install with you in the beginning that was mirroring an authenticated iso from the open source community, I wouldn't mind as much but this grey area leaves me unsettled.

I know they have their incentives to do well and that's fine in the terms of a base system. I'll even give them the credit they deserve for writing some of the best security guides I've ever read.

But, as I take steps down the computer security rabbit hole I find myself understanding more and more that the only way to truly have good security, is to trust no one.

While I can and always will follow best practices to harden the systems they are handing me to work with to make them as restrictive as possible, I am tempted to put the actual services in internal VMs that I know are running on operating systems that have been hardened to the best of my abilities in order to create an isolated sandbox where the processing can actually happen.

My question is, will using a textbook hardened and verified operating system in a VM inside an OS that cannot be defined as a "trust no one" system provide additional levels of security to make it possible to be a "trust no one" system again? Or is a VM not able to be any more secure than its host?

With the security concerns that still come with services like docker I am definitely still going to use VMs for instant rebuilds and isolation of mishaps but I would love to hear what everyone has to say about this now that VPS's are so cheap and easy to use.

  • 3
    if the hardware the VM lives on is compromised, every VM is compromised. Commented Oct 19, 2015 at 18:36
  • As long as they have access to the underlying hardware, they can compromise any software (hypervisor and guest OSes included) running on it. Nested VMs will make it harder to access your data (any tools they may use to read VM's disks or take memory images may not expect multiple nested VMs) but they only need to rewrite them. Commented Oct 19, 2015 at 18:47
  • Are there any preventive measures for that? I'm referring to the whole "when designing software, it's safest to assume that the environment your code is living in is already hostile". Commented Oct 19, 2015 at 20:38

1 Answer 1


Whether using a VM is more secure or not depends what you are protecting yourself against. If you fear that DigitalOcean may be trying to spy on you, illegally gives access to your system to hackers, or many other malicious activities, there's little you can do to protect against it. No matter how secure your VM is, they control the hardware and OS that it is hosted on. So they can install keyboard loggers, steal private keys and passwords from memory, etc...

On the other hand, if you're concerned that DigitalOcean monkeyed with the OS and somehow made it less secure, then running on a VM might help. It will depend whether whatever they did is still vulnerable when a VM is being used. For example, if they made some mistake that includes malware that allows a remote root shell on your VPS, then there's little that you can do to protect against that. But if they're mistake is only exploitable if you are running a web server on the VPS, then perhaps the VM will help.

  • That pretty much covers it all. Mostly the monkeying around aspect. I get a little weirded out whenever I find a new chunk of code or more repos from digitalocean in the core system directories. I mean we're still trying to perfect the original systems that these are built on and then there's them changing stuff. I get that it might be to guarantee that the correct code runs in order to protect their systems but its nice to know I can isolate and do the same on my side as well. Thanks! Commented Oct 19, 2015 at 23:22

You must log in to answer this question.

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