From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: Linux Containers <containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>
Subject: Re: [PATCH 1/1] RFC: taking a crack at targeted capabilities
Date: Wed, 6 Jan 2010 14:17:25 -0600 [thread overview]
Message-ID: <20100106201725.GA24242@us.ibm.com> (raw)
In-Reply-To: <m17hrv18ad.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
>
> > So i was thinking about how to safely but incrementally introduce
> > targeted capabilities - which we decided was a prereq to making VFS
> > handle user namespaces - and the following seemed doable. My main
> > motivations were (in order):
> >
> > 1. don't make any unconverted capable() checks unsafe
> > 2. minimize performance impact on non-container case
> > 3. minimize performance impact on containers
>
> My motivation is a bit different. I would like to get to the
> unprivileged creation of new namespaces. It looks like this gets us
> 90% of the way there, with only potential uid confusion issues left.
>
> I still need to handle getting all caps after creation but otherwise I
> think I have a good starter patch that achieves all of your goals.
>
> Of course kill_permission needs the checks you have suggested as well.
>
> Eric
>
>
> >From db104af741b5f0a2f128688905498cae68fbbde2 Mon Sep 17 00:00:00 2001
> From: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Date: Wed, 6 Jan 2010 08:26:21 -0800
> Subject: [PATCH] security: Make capabilities relative to the user namespace.
>
> - Introduce ns_capable to test for a capability in a non-default
> user namespace.
> - Teach cap_capable to handle capabilities in a non-default
> user namespace.
So yeah, I didn't address the whole has_capability junk. Feh.
So do you intend to tag all namespaces with the userns which
created it? So sys_hostname() can check utsname->uts_ns->creator,
and net ioctl SIOCSIFNAME checks struct net->creator?
-serge
next prev parent reply other threads:[~2010-01-06 20:17 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-06 6:28 [PATCH 1/1] RFC: taking a crack at targeted capabilities Serge E. Hallyn
[not found] ` <20100106062809.GA17064-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-01-06 15:44 ` Eric W. Biederman
[not found] ` <m13a2j2q7c.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-01-06 17:30 ` Serge E. Hallyn
[not found] ` <20100106173056.GC15784-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-01-06 20:43 ` Eric W. Biederman
2010-01-06 16:56 ` Eric W. Biederman
[not found] ` <m17hrv18ad.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-01-06 17:35 ` Serge E. Hallyn
[not found] ` <20100106173536.GD15784-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-01-06 20:57 ` Eric W. Biederman
2010-01-06 20:17 ` Serge E. Hallyn [this message]
[not found] ` <20100106201725.GA24242-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-01-06 21:11 ` Eric W. Biederman
[not found] ` <m1skajszuw.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-01-06 21:57 ` Serge E. Hallyn
[not found] ` <20100106215721.GA5823-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-01-07 0:16 ` Eric W. Biederman
2010-02-15 14:27 ` Matt Helsley
[not found] ` <20100215142746.GD3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-02-15 16:16 ` Eric W. Biederman
[not found] ` <m13a12bhjq.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-15 16:37 ` Matt Helsley
[not found] ` <20100215163708.GG3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-02-15 16:48 ` Eric W. Biederman
2010-02-15 4:05 ` Serge E. Hallyn
[not found] ` <20100215040529.GA20519-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-02-15 11:06 ` Eric W. Biederman
[not found] ` <m1ocjqep25.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-02-16 22:07 ` Serge E. Hallyn
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=20100106201725.GA24242@us.ibm.com \
--to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
--cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.