All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Alexander Mihalicyn" <alexander@mihalicyn.com>,
	"Giuseppe Scrivano" <gscrivan@redhat.com>,
	"Joseph Christopher Sible" <jcsible@cert.org>,
	"Kees Cook" <keescook@chromium.org>,
	containers@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, "Vivek Goyal" <vgoyal@redhat.com>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Mickaël Salaün" <mic@digikod.net>, "Wat Lim" <watl@google.com>,
	"Mrunal Patel" <mpatel@redhat.com>,
	"Pavel Tikhomirov" <ptikhomirov@virtuozzo.com>,
	"Geoffrey Thomas" <geofft@ldpreload.com>
Subject: Re: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces
Date: Sun, 11 Oct 2020 13:53:06 -0700	[thread overview]
Message-ID: <20201011205306.GC17441@localhost> (raw)
In-Reply-To: <20201010042606.GA30062@mail.hallyn.com>

On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote:
> > 3. Find a way to allow setgroups() in a user namespace while keeping
> >    in mind the case of groups used for negative access control.
> >    This was suggested by Josh Triplett and Geoffrey Thomas. Their idea was to
> >    investigate adding a prctl() to allow setgroups() to be called in a user
> >    namespace at the cost of restricting paths to the most restrictive
> >    permission. So if something is 0707 it needs to be treated as if it's 0000
> >    even though the caller is not in its owning group which is used for negative
> >    access control (how these new semantics will interact with ACLs will also
> >    need to be looked into).
> 
> I should probably think this through more, but for this problem, would it
> not suffice to add a new prevgroups grouplist to the struct cred, maybe
> struct group_info *locked_groups, and every time an unprivileged task creates
> a new user namespace, add all its current groups to this list?

So, effectively, you would be allowed to drop permissions, but
locked_groups would still be checked for restrictions?

That seems like it'd introduce a new level of complexity (a new facet of
permission) to manage. Not opposed, but it does seem more complex than
just opting out of using groups for negative permissions.
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

WARNING: multiple messages have this Message-ID (diff)
From: Josh Triplett <josh@joshtriplett.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Christian Brauner" <christian.brauner@ubuntu.com>,
	containers@lists.linux-foundation.org,
	"Alexander Mihalicyn" <alexander@mihalicyn.com>,
	"Mrunal Patel" <mpatel@redhat.com>, "Wat Lim" <watl@google.com>,
	"Aleksa Sarai" <cyphar@cyphar.com>,
	"Pavel Tikhomirov" <ptikhomirov@virtuozzo.com>,
	"Geoffrey Thomas" <geofft@ldpreload.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Joseph Christopher Sible" <jcsible@cert.org>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Vivek Goyal" <vgoyal@redhat.com>,
	"Giuseppe Scrivano" <gscrivan@redhat.com>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Stephane Graber" <stgraber@ubuntu.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Sargun Dhillon" <sargun@sargun.me>,
	linux-kernel@vger.kernel.org
Subject: Re: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces
Date: Sun, 11 Oct 2020 13:53:06 -0700	[thread overview]
Message-ID: <20201011205306.GC17441@localhost> (raw)
In-Reply-To: <20201010042606.GA30062@mail.hallyn.com>

On Fri, Oct 09, 2020 at 11:26:06PM -0500, Serge E. Hallyn wrote:
> > 3. Find a way to allow setgroups() in a user namespace while keeping
> >    in mind the case of groups used for negative access control.
> >    This was suggested by Josh Triplett and Geoffrey Thomas. Their idea was to
> >    investigate adding a prctl() to allow setgroups() to be called in a user
> >    namespace at the cost of restricting paths to the most restrictive
> >    permission. So if something is 0707 it needs to be treated as if it's 0000
> >    even though the caller is not in its owning group which is used for negative
> >    access control (how these new semantics will interact with ACLs will also
> >    need to be looked into).
> 
> I should probably think this through more, but for this problem, would it
> not suffice to add a new prevgroups grouplist to the struct cred, maybe
> struct group_info *locked_groups, and every time an unprivileged task creates
> a new user namespace, add all its current groups to this list?

So, effectively, you would be allowed to drop permissions, but
locked_groups would still be checked for restrictions?

That seems like it'd introduce a new level of complexity (a new facet of
permission) to manage. Not opposed, but it does seem more complex than
just opting out of using groups for negative permissions.

  reply	other threads:[~2020-10-11 20:53 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-30 14:39 LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces Christian Brauner
2020-08-30 14:39 ` Christian Brauner
2020-10-10  4:26 ` Serge E. Hallyn
2020-10-10  4:26   ` Serge E. Hallyn
2020-10-11 20:53   ` Josh Triplett [this message]
2020-10-11 20:53     ` Josh Triplett
2020-10-12  0:38     ` Andy Lutomirski
2020-10-12  0:38       ` Andy Lutomirski
2020-10-12  5:01       ` Eric W. Biederman
2020-10-12  5:01         ` Eric W. Biederman
2020-10-12 15:00         ` Serge E. Hallyn
2020-10-12 15:00           ` Serge E. Hallyn
2020-10-14 19:46           ` Eric W. Biederman
2020-10-14 19:46             ` Eric W. Biederman
2020-10-15 14:27             ` Serge E. Hallyn
2020-10-15 14:27               ` Serge E. Hallyn
2020-10-17 15:04               ` Eric W. Biederman
2020-10-17 15:04                 ` Eric W. Biederman
2020-10-12 17:05     ` Giuseppe Scrivano
2020-10-12 17:05       ` Giuseppe Scrivano
2020-10-13 12:46       ` Serge E. Hallyn
2020-10-13 12:46         ` Serge E. Hallyn
2020-10-13 15:17         ` Giuseppe Scrivano
2020-10-13 15:17           ` Giuseppe Scrivano
2020-10-15 14:32           ` Serge E. Hallyn
2020-10-15 14:32             ` Serge E. Hallyn
2020-10-19 12:12             ` Giuseppe Scrivano
2020-10-19 12:12               ` Giuseppe Scrivano
2021-04-21 17:27               ` Snaipe via Containers
2021-04-21 17:27                 ` Snaipe
2021-04-22  9:18                 ` Giuseppe Scrivano
2021-04-22  9:18                   ` Giuseppe Scrivano
2021-04-23 14:36                   ` Franklin “Snaipe” Mathieu via Containers
2021-04-23 14:36                     ` Franklin “Snaipe” Mathieu
2021-05-07 13:37                   ` Serge E. Hallyn
2021-05-10 13:02                     ` Giuseppe Scrivano
2021-05-10 13:02                       ` Giuseppe Scrivano
2021-05-10 13:57                       ` Giuseppe Scrivano
2021-05-10 13:57                         ` Giuseppe Scrivano
2020-10-15 15:31 ` Enrico Weigelt, metux IT consult
2020-10-15 15:31   ` Enrico Weigelt, metux IT consult
2020-10-17 16:51   ` Eric W. Biederman
2020-10-17 16:51     ` Eric W. Biederman
2020-10-18 10:20     ` Christian Brauner
2020-10-18 10:20       ` Christian Brauner
2020-10-18 13:05       ` The problem of setgroups and containers Eric W. Biederman
2020-10-19  0:15         ` Eric W. Biederman
2020-10-19  0:15           ` Eric W. Biederman
2020-10-19 20:07           ` [RFC][PATCH] userns: Limit process in a user namespace to what the creator is allowed Eric W. Biederman
2020-10-19 20:07             ` Eric W. Biederman
2020-10-20 14:11             ` Christian Brauner
2020-10-20 14:11               ` Christian Brauner
2020-10-29 13:42     ` LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces Enrico Weigelt, metux IT consult

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=20201011205306.GC17441@localhost \
    --to=josh@joshtriplett.org \
    --cc=alexander@mihalicyn.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=geofft@ldpreload.com \
    --cc=gscrivan@redhat.com \
    --cc=jcsible@cert.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mic@digikod.net \
    --cc=mpatel@redhat.com \
    --cc=ptikhomirov@virtuozzo.com \
    --cc=serge@hallyn.com \
    --cc=vgoyal@redhat.com \
    --cc=watl@google.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 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.