qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	"P. Berrange, Daniel" <berrange@redhat.com>,
	qemu-devel@nongnu.org, vgoyal@redhat.com
Subject: Re: libcap vs libcap-ng mess
Date: Mon, 2 Dec 2019 10:07:31 +0000	[thread overview]
Message-ID: <20191202100731.GB2904@work-vm> (raw)
In-Reply-To: <CABgObfZjz=5vWs+-DHTaxfOEu+9Vw1+SuZLSpzxZpRNFRzNKEQ@mail.gmail.com>

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il ven 29 nov 2019, 19:54 Dr. David Alan Gilbert <dgilbert@redhat.com> ha
> scritto:
> 
> > > Yes, it's per thread.  The state can be built from
> > > capng_clear/capng_get_caps_process + capng_update, and left in there
> > > forever.  There is also capng_save_state/capng_restore_state which, as
> > > far as I can see from the sources, can be used across threads.
> >
> > So, I think what you're saying is I need to:
> >   a) Before we sandbox do the capng_get_caps_process
> >
> 
> Why not after sandboxing?

Because in our sandbox we don't have /proc and capng_get_caps_process
tries to read /proc/.../status and fails. The old libcap code doesn't
use /proc, it just uses capget (which the new one also uses).

> If the code is in any way similar to the 9p
> proxy, you have two states, "sandboxed with capabilities" and "sandboxed
> without capabilities". The former (permitted=effective) is what you get
> after setresuid/setresgid, the other can be computed after sandboxing and
> saved using capng_save_state. The FSETID capability can be updated
> explicitly before/after capng_apply.
> 
>   b) Before we start a new thread do a capng_save_state and restore it
> > in the thread
> >
> 
> Or just save after (a), and restore always before capng_apply.

Hmm yes, that's easier.

>   a) This code is very local - it does a drop FSETID, a write, restore
> > FSETID
> >   b) I'm not sure but I suspect it's used only in the non-uid=0 case;
> > the whole thing is just a hack to cause setuid/setgid to be dropped
> > in the case where it's written by a process that doesn't have FSETID
> > (hmm I guess if the guest was root but didn't have fsetid then it would
> > be 0?)
> >
> 
> Yes it would. For uid!=0 the kernel clears the effective capabilities so it
> shouldn't need to do anything, unless virtiodsd restores capabilities after
> setresuid/setresgid.
> 
> But are you suggesting I need to change something other than the
> > effective caps in that case?
> >
> 
> No, only the effective caps.

OK, thanks.

Dave

> Paolo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



  reply	other threads:[~2019-12-02 10:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-28 19:04 libcap vs libcap-ng mess Dr. David Alan Gilbert
2019-11-29  9:34 ` Daniel P. Berrangé
2019-11-29 10:46   ` Paolo Bonzini
2019-11-29 10:51     ` Dr. David Alan Gilbert
2019-11-29 18:01     ` Dr. David Alan Gilbert
2019-11-29 18:12       ` Paolo Bonzini
2019-11-29 18:20         ` Dr. David Alan Gilbert
2019-11-29 18:27           ` Paolo Bonzini
2019-11-29 18:54             ` Dr. David Alan Gilbert
2019-11-29 23:19               ` Paolo Bonzini
2019-12-02 10:07                 ` Dr. David Alan Gilbert [this message]
2019-12-02 10:33                   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191202100731.GB2904@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).