[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7)
From: |
Vivek Goyal |
Subject: |
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7) |
Date: |
Fri, 19 Jun 2020 11:57:37 -0400 |
On Fri, Jun 19, 2020 at 05:26:37PM +0200, Miklos Szeredi wrote:
> On Fri, Jun 19, 2020 at 4:25 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Fri, Jun 19, 2020 at 04:16:30PM +0200, Miklos Szeredi wrote:
> > > On Thu, Jun 18, 2020 at 9:08 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> > > >
> > > > On Thu, Apr 16, 2020 at 05:49:05PM +0100, Stefan Hajnoczi wrote:
> > > > > virtiofsd doesn't need of all Linux capabilities(7) available to
> > > > > root. Keep a
> > > > > whitelisted set of capabilities that we require. This improves
> > > > > security in
> > > > > case virtiofsd is compromised by making it hard for an attacker to
> > > > > gain further
> > > > > access to the system.
> > > >
> > > > Hi Stefan,
> > > >
> > > > I just noticed that this patch set breaks overlayfs on top of virtiofs.
> > >
> > > How so? Virtiofs isn't mounting overlayfs, is it? Only the mounter
> > > requires CAP_SYS_ADMIN, not the accessor.
> >
> > virtiofsd needs CAP_SYS_ADMIN, otherwise fsetxattr(trusted.overlay.opaque)
> > fails in lo_setxattr().
> >
> > This is triggered when we mount overlayfs on top of virtiofs and overlayfs
> > tries to set OVL_XATTR_OPAQUE on upper to check if trusted xattrs are
> > supported or not.
>
> Ah, right.
>
> Plan is to use "user.*" xattr for unprivileged overlay. This would be
> a good way to eliminate this attack surface in the overlay on virtiofs
> case as well.
So unpriviliged overlay is one which is mounted from inside a user
namespace. But in this case we might be mounting it from init_user_ns
of guest. So from overlayfs perspective this will still be treated
as priviliged overlay instance and it will use trusted xattrs, IIUC?
Thanks
Vivek
>
> Other ways to minimize risk is to separate operations requiring
> CAP_SYS_ADMIN into a separate process, preferably a separate
> executable, that communicates with virtiofsd using a pipe and contains
> the minimum amount of code.
>
> Thanks,
> Miklos
>
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Miklos Szeredi, 2020/06/19
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/19