From: "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: Richard Weinberger <richard-/L3Ra7n9ekc@public.gmane.org>,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Serge Hallyn
<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
Subject: Re: Interaction user namespace, /proc/1 ownership & cap_set
Date: Fri, 12 Jul 2013 11:04:20 +0100 [thread overview]
Message-ID: <20130712100420.GD25475@redhat.com> (raw)
In-Reply-To: <87k3l8sx6l.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Tue, Jul 02, 2013 at 10:12:34AM -0700, Eric W. Biederman wrote:
> "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
>
> > Ah, yes, that would explain it. My demo is removing the SYS_MODULE
> > capability, and then exec'ing the shell binary. Since we are uid==0,
> > and prctl(PR_CAPBSET_DROP) is not available inside the user namespace,
> > the rules for capabilities vs execve() call will cause the shell
> > binary to regain SYS_MODULE capability bit.
> >
> > So the problem I'm seeing in libvirt is all a result of the fact
> > that we can't use PR_CAPBSET_DROP inside the user namespace. Given
> > that there's no point trying to drop any capabilities inside the
> > user namespace.
> >
> > The only slight problem here is that we want to drop CAP_MKNOD so
> > that systemd can detect that it shouldn't attempt to run any units
> > which would rely on mknod.
>
> I just looked at that and I don't see a justification for the
> restriciton.
>
> Could you try the patch below and see if it fixes things for you?
>
> Eric
>
>
> From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Date: Tue, 2 Jul 2013 10:04:54 -0700
> Subject: [PATCH] userns: Allow PR_CAPBSET_DROP in a user namespace.
>
> As the capabilites and capability bounding set are per user namespace
> properties it is safe to allow changing them with just CAP_SETPCAP
> permission in the user namespace.
>
> Signed-off-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> ---
> security/commoncap.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 4d787e6..fd9b08f 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -843,7 +843,7 @@ int cap_task_setnice(struct task_struct *p, int nice)
> */
> static long cap_prctl_drop(struct cred *new, unsigned long cap)
> {
> - if (!capable(CAP_SETPCAP))
> + if (!ns_capable(current_user_ns(), CAP_SETPCAP))
> return -EPERM;
> if (!cap_valid(cap))
> return -EINVAL;
Yes, that works in my testing with libvirt. Feel free to add
Tested-by: Daniel P. Berrange <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
prev parent reply other threads:[~2013-07-12 10:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 16:16 Interaction user namespace, /proc/1 ownership & cap_set Daniel P. Berrange
[not found] ` <20130701161625.GQ15954-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-01 16:19 ` Daniel P. Berrange
[not found] ` <20130701161946.GR15954-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-01 16:24 ` Richard Weinberger
2013-07-02 5:14 ` Gao feng
[not found] ` <51D261D3.3030002-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-07-02 8:44 ` Eric W. Biederman
[not found] ` <87wqp9uz9a.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-07-02 8:56 ` Richard Weinberger
[not found] ` <51D295C5.1080003-/L3Ra7n9ekc@public.gmane.org>
2013-07-02 9:25 ` Daniel P. Berrange
[not found] ` <20130702092554.GD2524-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-02 9:45 ` Richard Weinberger
2013-07-02 9:57 ` Eric W. Biederman
[not found] ` <87ehbhthbl.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-07-02 10:07 ` Gao feng
[not found] ` <51D2A649.9030102-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2013-07-02 16:35 ` Eric W. Biederman
[not found] ` <8761wsudgk.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-07-02 16:45 ` Daniel P. Berrange
[not found] ` <20130702164514.GB2524-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-07-02 17:12 ` Eric W. Biederman
[not found] ` <87k3l8sx6l.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2013-07-02 20:24 ` Richard Weinberger
2013-07-09 10:35 ` Richard Weinberger
2013-07-12 10:04 ` Daniel P. Berrange [this message]
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=20130712100420.GD25475@redhat.com \
--to=berrange-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=richard-/L3Ra7n9ekc@public.gmane.org \
--cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
/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