[PATCH v2] apparmor: allow libvirtd to call virtiofsd

[Kevin Locke]

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