Re: LPC 2020 Hackroom Session: summary and next steps for isolated user namespaces

[Andy Lutomirski <luto@kernel.org>]

On Sun, Oct 11, 2020 at 1:53 PM Josh Triplett <josh@joshtriplett.org> wrote:
>
> 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.

Is there any context other than regular UNIX DAC in which groups can
act as negative permissions or is this literally just an issue for
files with a more restrictive group mode than other mode?