[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7)
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7) |
Date: |
Fri, 19 Jun 2020 12:12:44 +0100 |
User-agent: |
Mutt/1.14.0 (2020-05-02) |
* Chirantan Ekbote (chirantan@chromium.org) wrote:
> On Fri, Jun 19, 2020 at 5:40 PM Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> >
> > * Chirantan Ekbote (chirantan@chromium.org) wrote:
> >
> > > We ended up working around it by prefixing "user.virtiofs." to the
> > > xattr name[2], which has its own problems but there was pretty much no
> > > chance that we would be able to give the fs device CAP_SYS_ADMIN in
> > > the init namespace.
> >
> >
> > What problems did you hit with that? We should standardise the renaming
> > so we make an on-disc format that's compatible.
> >
>
> I guess what I meant by problems is that it made what was previously a
> simple and straightforward implementation into something more complex
> and added some limitations.
Yeh.
> For example, we now need to parse the
> result of the listxattr system call and strip out the prefix from any
> name in the list. It also means that we cannot allow the guest to
> directly set or remove any "user.virtiofs." xattr as this would allow
> an unprivileged process in the vm to modify an xattr that it wouldn't
> otherwise be allowed to modify. On top of being a somewhat arbitrary
> restriction this also means that you can't have stacked virtiofs
> instances as the lower instance would reject attempts by the upper one
> to set those xattrs. These limitations aren't really a problem for us
> but I can see how they might be a problem for others.
Isn't this a classic escaping problem?
Would it work if you prepended 'user.virtiofs.' onto any xattr
that started with 'trusted' or 'user.virtiofs.' ?
> The change was also merged just yesterday so there may be other
> problems with it that haven't surfaced yet.
>
> I didn't mention it before because I figured this was something that
> we brought upon ourselves as chrome os is a bit extreme about
> sandboxing.
I think we're trying to be as extreme in virtiofsd, but it is causing us
similar problems.
> If we can come up with a standardized way to handle this
> I think we'll gladly switch the chrome os implementation to use it.
Great!
Dave
>
> Chirantan
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), (continued)
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Dr. David Alan Gilbert, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Dr. David Alan Gilbert, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Chirantan Ekbote, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Dr. David Alan Gilbert, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Chirantan Ekbote, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7),
Dr. David Alan Gilbert <=
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/19
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Chirantan Ekbote, 2020/06/24
- Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7), Vivek Goyal, 2020/06/25
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