* Vivek Goyal (vgo...@redhat.com) wrote: > On Fri, Jun 19, 2020 at 12:39:14PM +0100, Daniel P. Berrangé wrote: > [..] > > The CAP_SYS_ADMIN requirement for 'trusted.' xattrs is simply a useful > > mechanism for applications to control access. The host kernel doesn' > > tuse this namespace itself. Linux has four namespaces for xattrs: > > > > - user - for userspace apps. accessible based on read/write permissions > > - trusted - for userspace apps. accessible by CAP_SYS_ADMIN processes only > > - system - for kernel only. used by ACLs > > - security - for kernel only. used by SELinux > > > > The use case for "trusted" xattrs is thus where a privileged management > > application or service wants to store metadata against the file, but > > also needs to grant an unprivileged process access to write to this file > > while not allowing that unprivileged process the ability to change the > > metadata. This is mentioned in the man page: > > > > [man xattr(7)] > > Trusted extended attributes > > Trusted extended attributes are visible and accessible only to pro‐ > > cesses that have the CAP_SYS_ADMIN capability. Attributes in this > > class are used to implement mechanisms in user space (i.e., outside > > the kernel) which keep information in extended attributes to which > > ordinary processes should not have access. > > > > User extended attributes > > User extended attributes may be assigned to files and directories > > for storing arbitrary additional information such as the mime type, > > character set or encoding of a file. The access permissions for > > user attributes are defined by the file permission bits: read per‐ > > mission is required to retrieve the attribute value, and writer per‐ > > mission is required to change it. > > [/man] > > > > Libvirtd uses the "trusted." xattr namespace to record information against > > disk images for QEMU, because we need to grant QEMU access to read/write > > the disk iamges, but don't want QEMU to be able to alter our xattrs. > > > > It is unfortunate that this namespace is tied to the CAP_SYS_ADMIN cap. > > It really ought to have had its own dedicated capability :-( Such is > > life with anything that uses CAP_SYS_ADMIN... > > > > With this in mind we really should have both trusted. & user. xattrs > > allowed to the guest by default. > > > > Conversely, we'll need to block usage of the security. and system. > > namespaces. > > I am wondering can we block usage of "system" and "security"? What > about guest setting acls over virtiofs files. These will have to > go through and that means we need to allow system xattrs. > > Similarly setting file capabilities inside should trigger > setxattr(security.capability) and that means we need to allow security > xattr as well.
Yep, we see that when people install Fedora packages, when rpm unpackgs /usr/bin/newgidmap which has: $ getfattr -d '--match=.*' /usr/bin/newgidmap getfattr: Removing leading '/' from absolute path names # file: usr/bin/newgidmap security.capability=0sAQAAAkAAAAAAAAAAAAAAAAAAAAA= security.selinux="system_u:object_r:bin_t:s0" Dave > Thanks > Vivek -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
