On Fri, Jun 19, 2020 at 05:26:37PM +0200, Miklos Szeredi wrote: > On Fri, Jun 19, 2020 at 4:25 PM Vivek Goyal <vgo...@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 <vgo...@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 >
