nvx-rs: enforce read-only mappings nested in read-write mappings on the host #552

Summary

The design of the blockless managed root says that the host enforces each host mapping's access itself, and that guest mount flags are never security boundaries (sections 1.4.3 and 4.1.3 of the architecture guide in doc/design/). The export plan in nvx-rs does not meet that for a read-only mapping that lies inside a read-write mapping.

plan in nvx-rs/src/host/filesystem.rs exports the outermost mapped directories, and the mapped files outside them, as children of OpenVMM's aggregate virtio-fs export. It limits a child's writes to its read-write mappings only when the child's root is itself mapped read-only. When the root is a read-write mapping, the child carries no writable paths, so HostFs accepts writes anywhere in it, including inside a read-only mapping nested there. Only the guest agent's read-only bind mount keeps that mapping read-only, as the module documentation states:

so the host enforces each mapping's access, except that of a read-only path inside a read-write mapping, which only the guest's bind mount keeps read-only.

Guest root, for example after a guest kernel compromise, can therefore modify a host path that the caller mapped read-only, such as through the raw export at /run/nvx/hostfs/root.

On Windows hosts, plan already refuses a read-only file inside a read-write directory, because the guest can reach the file under another spelling of its name, which the bind mount does not cover.

Intended behavior

Guest mount flags are never security boundaries. The host enforces every mapping's access, including that of a read-only mapping nested in a read-write one, whichever guest mount, link, or name reaches it.

Options

• Let the microVM virtio-fs access policy mark read-only subtrees inside a read-write export, the way allowed paths expose subtrees of denied paths again, and have plan set them for nested read-only mappings.
• Until the host can enforce it, refuse a read-only mapping nested in a read-write one on every host, as plan already does for files on Windows.

Tasks

• Choose an option and implement it in OpenVMM's microVM virtio-fs policy, in nvx-rs, or in both.
• Test that writes to a nested read-only mapping fail with EROFS even from guest root through the raw export, or that plan refuses the policy.
• Update the module documentation in nvx-rs/src/host/filesystem.rs, and 4.1.3 of the architecture guide if the chosen option changes the rule.

Related: #539 requires non-bypassable nested read-only mappings for a guest root caller in the future guest core.