Re: xattr names for unprivileged stacking?

[Greg Kurz <groug@kaod.org>]

On Tue, 28 Jul 2020 11:55:03 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:

> Hi,
>   Are there any standards for mapping xattr names/classes when
> a restricted view of the filesystem needs to think it's root?
> 
> e.g. VMs that mount host filesystems, remote filesystems etc and the
> client kernel tries to set a trusted. or security. xattr and you want
> to store that on an underlying normal filesystem, but your
> VM system doesn't want to have CAP_SYS_ADMIN and/or doesn't want to
> interfere with the real hosts security.
> 
> I can see some existing examples:
> 
>   9p in qemu
>      maps system.posix_acl_* to user.virtfs.system.posix_acl_*
>           stops the guest accessing any user.virtfs.*
> 
>    overlayfs
>       uses trusted.overlay.* on upper layer and blocks that from 
>            clients
> 
>    fuse-overlayfs
>       uses trusted.overlay.* for compatibiltiy if it has perms,
>       otherwise falls back to user.fuseoverlayfs.*
> 
>    crosvm's virtiofs
>       maps "security.sehash" to "user.virtiofs.security.sehash"
>       and blocks the guest from accessing user.virtiofs.*
> 
> Does anyone know of any others?
> 

Hi Dave,

Sorry, I'm not aware of any other example.

Cc'ing Christian Schoenebeck, the new 9p maintainer in QEMU in case
he has some information to share in this area.

Cheers,

--
Greg

> It all seems quite adhoc;  these all fall to bits when you
> stack them or when you write a filesystem using one of these
> schemes and then mount it with another.
> 
> (I'm about to do a similar mapping for virtiofs's C daemon)
> 
> Thanks in advance,
> 
> Dave 
> 
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>