Hi Christian and Jamie, On Wed, 2020-08-26 at 09:26 -0500, Jamie Strandboge wrote:
[...]
Considering all of the above, IME a PUx rule is the right choice. A security audit of virtiofsd IMO is warranted to ensure a non-root user who doesn't have access to libvirtd's socket can't start a VM with session:/// (etc) to expose a privileged file like /etc/shadow from the host to the guest (and thus circumventing host protections on /etc/shadow). Considering this last point, there is arguably value in dynamically updating the virtiofsd child profile. This development cost should be weighed that against future improvements to AppArmor to address the post-pivot_root limitation.
I don't have enough AppArmor or virtiofsd expertise to weigh in on the cost/benefit trade-offs or implementation details, but just wanted to commend both your effort on the RFC and depth of this response. I think the motivations are sound and I agree on all counts. I'd be happy to help where I can with any approach. As a fairly unsophisticated user, I'd also warn against further complicating virtio-fs setup. I found the current process (which requires configuring vNUMA with shared memory backing in addition to hand-editing <filesystem>) difficult and error-prone. If editing AppArmor configuration files for each shared directory, and keeping them in sync with the domain XML will be required, I worry that it will add significant burden and risk of error for other unsophisticated users. If the AppArmor child policy can be dynamically updated as Jamie suggested (IIUC) I wouldn't expect this to be an issue. Thanks for considering, Kevin