Re: [libvirt] [PATCH 03/18] security: Include security_util
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