linux-kernel - Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 28 Jun 2021 13:22:40 -0400
From:   Vivek Goyal <vgoyal@...hat.com>
To:     Casey Schaufler <casey@...aufler-ca.com>
Cc:     dwalsh@...hat.com, "Schaufler, Casey" <casey.schaufler@...el.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "virtio-fs@...hat.com" <virtio-fs@...hat.com>,
        "dgilbert@...hat.com" <dgilbert@...hat.com>,
        "berrange@...hat.com" <berrange@...hat.com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        "selinux@...r.kernel.org" <selinux@...r.kernel.org>
Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special
 files if caller has CAP_SYS_RESOURCE

On Mon, Jun 28, 2021 at 09:04:40AM -0700, Casey Schaufler wrote:

[..]
> > on a host without SELinux support but the VM has SELinux enabled, then virtiofsd needs CAP_SYS_ADMIN.  It would be much more secure if it only needed CAP_SYS_RESOURCE.
> 
> I don't know, so I'm asking. Does virtiofsd really get run with limited capabilities,
> or does it get run as root like most system daemons? If it runs as root the argument
> has no legs.

It runs as root but we give it a set of minimum required capabilities by
default and want to avoid giving it CAP_SYS_ADMIN.

> 
> >   If the host has SELinux enabled then it can run without CAP_SYS_ADMIN or CAP_SYS_RESOURCE, but it will only be allowed to write labels that the host system understands, any label not understood will be blocked. Not only this, but the label that is running virtiofsd pretty much has to run as unconfined, since it could be writing any SELinux label.
> 
> You could fix that easily enough by teaching SELinux about the proper
> use of CAP_MAC_ADMIN. Alas, I understand that there's no way that's
> going to happen, and why it would be considered philosophically repugnant
> in the SELinux community. 
> 
> >
> > If virtiofsd is writing Userxattrs with CAP_SYS_RESOURCE, then we can run with a confined SELinux label only allowing it to sexattr on the content in the designated directory, make the container/vm much more secure.
> >
> User xattrs are less protected than security xattrs. You are exposing the
> security xattrs on the guest to the possible whims of a malicious, unprivileged
> actor on the host. All it needs is the right UID.

One of the security tenets of virtiofs is that this shared directory should
be hidden from unprivliged users. Otherwise guest can drop setuid root
binaries in shared directory and unprivliged user on host executes it and
gets control of the host.

So unpriviliged actor on host having access to these shared directory
contents is wrong configuration.

> 
> We have unused xattr namespaces. Would using the "trusted" namespace
> work for your purposes?

That requires giving CAP_SYS_ADMIN to daemon and one of the goals is
to give as little capabilities as possible to virtiofsd. In fact people
have been asking for the capablities to run virtiofsd unpriviliged
as well as run inside a user namespace etc.

Anyway, remapping LSM xattrs to "trusted.*" space should work as long
as virtiofsd has CAP_SYS_ADMIN.

Thanks
Vivek