Security Question regarding host directory passthrough vs default vm storage

Hi. I have a question regarding the security implications of host directory pass-through. My question probably applies to both lxd and incus, but I decided to ask my question here as I plan on migrating my live systems to incus soon and thus that’s my primary interest going forward.

TL;DR - is it “less secure” for the host server to pass through a regular host directory to a vm using ‘lxc config device add…’ vs using the default lxd/incus storage?

Details:

I created a directory (‘/home/andrew/vmdir’) on the host. I then created a test file (‘host-creation’) in the host under vmdir (as a normal user). And then I created a virtual machine (‘vm’) on the same host using:

lxc init ubuntu:22.04 vm --vm

I then passed through the directory as a disk (‘demo’) to the vm to mount it under /root/vmdir:

lxc config device add vm demo disk source=/home/andrew/vmdir path=root/vmdir.

I started the vm, exec into it and I can see the directory, and create/delete files in it. Including any created by the host. I can, as a non-root user in the host create/delete files created in the vm in that passed through directory as normal (albeit it asks me if I want to remove the write-protection.

My question is: are there any specific security weaknesses/issues/vulnerabilities to the host for passing a directory through to the vm vs say using the default storage and creating native directories inside the vm without passing through a disk device? How different is this (or not) to passing a directory through to a vm using e.g. virt-manager?

A screenshot showing my actual experience is shown below for completeness. I was surprised (pleasantly) that this worked as easily as it did. I am just wondering if I am creating security issues for the bare-metal server if I use this to pass through some storage?

Thank you!

Andrew

There’s the obvious denial of service risk, the VM could completely saturate that shared storage and cause the host to look up due to running out of space.

Other than that, the main security concern would be that the VM can create files as any user and can set the setuid bit, so root in the VM could say put a static copy of bash in that shared file, make it setuid root and your unprivileged user on your host will then be able to execute that binary and become root on the host.

That’s why for unprivileged projects such as those generated by incus-user, we set the restricted.idmap.uid and restricted.idmap.gid properties on the project to limit what uid/gid may be used on the host for such shared paths.

1 Like

Thank you. Very clear. As convenient as this looks for some of my requirements, I think I’ll leave it alone and continue using my zfs backed incus-created storage/volumes. :+1: :slightly_smiling_face: