On 11/27/18 4:20 PM, Daniel P. Berrangé wrote: > On Fri, Nov 23, 2018 at 09:43:21AM +0100, Michal Privoznik wrote: > >> +/* There are four namespaces available (xattr(7)): > > s/available/available on Linux/ > > FreeBSD only supports 'user' and 'system' namespaces D'oh! > >> + * >> + * user - can be modified by anybody, >> + * system - used by ACLs >> + * security - used by SELinux >> + * trusted - accessibly by CAP_SYS_ADMIN processes only >> + * >> + * Looks like the last one is way to go. > > That prevents the QEMU driver using this functionality on any > non-Linux host. > > The key problem we obviously face is that of the QEMU process > being able to modify the xattrs maliciously. 'trusted' namespace > solves this for Linux but unsolved for BSD/macOS. > > I can only think of two alternative ways to deal with this > > - Use a sidecar file. eg $FILEPATH.libvirt.json > Works ok for plain files. Troublesome for device nodes. > Would have to use a file in /var/run/libvirt/devs/$DEVNODE > perhaps ? I rather not create files. If there is a bug and libvirt doesn't remove the file on the last restore (or it gets refcounting wrong or something) then it requires user intervention. Not only that, but the file would need to be owned by root:root (in order to avoid malicious users mangling its contents) which might not be possible at all times (e.g. root squashed NFS). On the other hand, NFS itself doesn't support XATTRs currently so these patches do not with that filesystem. > > - Use 'user' label but add a cryptographic signature > as a further attribute. Doesn't prevent tampering > but lets us throw away the data when tempering is > detected. I'm not sure how this would work with multiple daemons. They would have to have the key shared among them. I mean, if one daemon sets the attribute and signs it with its own key and then comes another daemon and updates the attribute it needs to sign it with the very same key otherwise the signature would be invalidated from the first daemon POV. > > Did you consider either of these, or any other possible > options ? I'm still loathe to bake in a solution that will > only work on Linux, despite 99% of our userbase being Linux. Not really. I focused on Linux and haven't realized BSD doesn't support trusted. Now that I am playing with this it looks like 'system' while being available on both Linux and BSD can't really be set on Linux. But it can be set on BSD (for privileged user only of course). I'm wondering if using 'trusted' on Linux and 'system' on BSD is the way to go. This could work except for cases where BSD and Linux meet, which can be only on NFS (right?) which doesn't support XATTRs anyway. Therefore I think we are safe, aren't we? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
