Re: [PATCH v2] apparmor: allow libvirtd to call virtiofsd
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