1

When reading about docker, I found a part of the documentation describing the attack surface of the docker daemon. From what I was able to understand, part of the argument is that it is possible to share (basically arbitrary) parts of the host filesystem with the container, which can then be manipulated by a privileged user in the container. This seems to be used as an argument against granting unprivileged users direct access to the docker daemon (see also this Security SE answer).

Would the same be possible from a virtual machine, e.g. in VirtualBox, which on the host is run as an unprivileged user?

A quick test where I was trying to read /etc/sudoers on a Linux Host from a Linux guest running in VirtualBox did produce a permission error (using sudo cat /path/to/shared/etc/sudoers as well as with sudo su, followed by cat /path/to/shared/etc/sudoers), but I would not consider myself an expert in that regard in any way nor was the testing very exhaustive.

  • I think most of the exploits would be memory/buffer overflows... but in VirtualBox you can turn on options to map to host directories, clipboard, etc... ultimately it's always best to run an application with the least amount of privileges possible... in case something gets outside the "sandbox". – pcalkins Aug 12 '20 at 22:20
  • @pcalkins I was not necessarily thinking about exploits, but more about a regular user trying to circumvent host system restrictions (such as file permissions) using an (intentionally?) misconfigured container or virtual machine environment. – AlexV Aug 13 '20 at 8:33
2

It's perfectly possible, with virtualization systems, to expose the underlying host OS filesystem (assuming here we're talking about Hypervisors running on a general purpose OS and not a "bare metal" setup), how that's done depends on the hypervisor in question.

That said container systems, like Docker, are more likely to have issues with this as, whilst most VMs can operate perfectly happily with just the resources available in the guest, containers will often mount host directories in to provide persistent storage.

Where that gets somewhat more dangerous, in many container setups, is that contained processes often run as the root user, which is the same UID as root on the host (assuming user namespacing isn't enabled).

In that configuration, if a sensitive host path is mapped inside the container, it would be easy for an attacker who has gained access to the container to modify the files on the host.

  • "In that configuration, if a sensitive host path is mapped inside the container, it would be easy for an attacker who has gained access to the container to modify the files on the host." Yeah, that's true. The example given in the question works perfectly fine from a Docker container. – AlexV Aug 13 '20 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.