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
