There are a couple completely different issues in play here, so I'll try to detangle this a bit and offer some helpful information.
1) VM (I assume you mean full virtual machine such as VirtualBox, KVM/QEMU, or VMWare).
For these, the vendor of the Hypervisor has a lot of control over what kinds of memory access are or are not possible.
Typically, at least in Linux (Windows HyperV is VERY different), a fully virtualized guest is quite isolated from the host running the Hypervisor.
Any properly written Hypervisor will implement measures to prevent access to guest memory from the Host or other VM's on the same Host, but there is only so much possible in this regard without severe performance impacts.
That doesn't prevent the Host from accessing the guest memory, anyone/anything with access to the hardware (including virtual hardware) can break the security with enough time and effort, but it is definitely not easy.
BTW, in this situation it doesn't matter who runs the VM; the Hypervisor initiates the guest process as a subprocess of its own privileged process, not a subprocess owned by the initiating user. The user-owned process is merely a cgroup peer (for resource limits) and VM state control process, not the parent.
I should also note that some Hypervisors may be configured to take fairly extreme measures to prevent host access to guest memory, whether these efforts will survive a truly dedicated adversary is not currently known.
2) Container (e.g. LXC, Docker, etc...)
This is much more nuanced. You control the level of access to container memory when you setup the container namespaces and cgroup, and your setup for that process can range from wide-open down to nobody-not-even-me levels (although a "real" privileged process at the host level can bypass your setup).
Default setups are typically reduced to complete isolation, so neither root nor the launching user can access the memory (although a privileged process at the host level can deliberately violate kernel namespace and process isolation to get around that).
Keep in mind that memory space isolation from process to process is the default in Linux, processes *may* have access to child process memory, but not always, and processes you run are not necessarily child processes of any particular parent (c.f. nohup).
The rub here is that the kernel controls all of this. Because the kernel mediates and enforces the isolation, anything with privilege enough to run the requisite syscalls will be able to breach the inter-process isolation in the kernel and inspect memory (or other resources) within the container.
Generally, containers are best when used to prevent the process within the container from accessing the host; not the other way around.
The setup of the namespaces (which create isolation) and cgroups (which limit resource availability) for a container are primarily designed to present a restricted "view" of the system to the container, rather than hiding the container from the host.
On 2018-05-21 10:32 PM, der.hans wrote:
> moin moin,
>
> I presume that if you run a container or VM as you on your system you can
> make a copy of its memory from the host system.
>
> If you run it as root, is root the only user ( outside of escalation
> exploits ) that has access to the memory?
>
> If you run it as a 3rd party, e.g. myvmuser, then only that user and root
> can inspect the memory from the host side?
>
> I'm contemplating the security implications of running a security or
> privacy process ( password manager, keyserver, etc. ) in a containerized
> or VM environment rather than just running it as an application on the
> host.
>
> Security and privacy processes try to lock down the memory on the host
> system, but when the OS is in a sub-process you can dump the entire
> memory.
>
> In this particular case, I'm not worried about something escaping the
> hosted system, rather I'm concerned about what can spy on the hosted
> system.
>
> ciao,
>
> der.hans
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)
