0

Potentially naive question that I'm hoping some cgroups experts can answer quickly:

Assuming the following docker workflow was run by Linux user joe, how can the system root user determine that a VM is indeed running?

IMAGE_NAME="ubuntu:20.10"
DOCKER_ARGS="--rm -i --privileged"

cat <<"EOF" | docker run ${DOCKER_ARGS} ${IMAGE_NAME}
set -ex
apt-get update
apt-get install -y libvirt0 virt-manager

libvirtd --daemon
virtlogd --daemon

virsh net-list --name | fgrep default || virsh net-start default

virt-install \
  --name MyFedora \
  --memory 1024 \
  --disk path=/tmp/myFedora.img,size=10 \
  --network network=default \
  --os-variant fedora28 \
  --cdrom /opt/joe/Fedora-Server-dvd-x86_64-34-1.2.iso \
  --noautoconsole \
  --debug

virsh list --all

sleep infinity

EOF

Given that the libvirtd socket that joe is running against only exists inside the docker container, how does root find joe's VM?

BrianTheLion
  • 165
  • 2
  • 8
  • i am unsure, but it should be possible to deny sub virtualisation, as in the beginning they used lxc and there is it possible to deny that – djdomi Oct 05 '21 at 19:55
  • root will see the qemu-system-x86 process running. (Btw, the ability to run docker allows to become root on the host, unless SELinux or AppArmor prevents some of it. so joe <=> root means joe is expected to do responsible things). – A.B Oct 06 '21 at 20:05
  • @A.B How can the pid of the `qemu-system-x86` process be used to track down and apply policy to the VM? – BrianTheLion Oct 08 '21 at 16:30
  • You should explain in the question what's the problem you are intending to solve. Else this can become an XY problem: https://xyproblem.info . – A.B Oct 08 '21 at 16:33
  • @A.B My comment was rhetorical in nature. The point being that -- unless `qemu-system-x86` is special; and it may be, idk -- having pid doesn't generally tell us very much about what might hiding behind the pid unless there is a viable mechanism for reverse-lookup into the application space. – BrianTheLion Oct 08 '21 at 16:50

0 Answers0