On Fri, Feb 17, 2017 at 12:53 PM, Aleksa Sarai wrote:
> >>>> One thing overlooked by commit 9cc46516ddf4 ("userns: Add a knob to
> >>>> disable setgroups on a per user namespace basis") is that because
> >>>> setgroups(2) no longer works in user namespaces it doesn't make any
> >>>> sense to be returning weird group IDs that the process cannot do
> >>>> anything with.
> >>>
> >>>
> >
> >> bool DropPrivileges()
> >> {
> >> /* ... */
> >> // Verify that the user isn't still in any supplementary groups
> >
> > But the user *is* still in a supplementary group. Your proposed
> > change would break the intent of this code.
>
> I was about to say that "being in an unmapped supplementary group does
> not count as privileges", but decided to test it first and realised that
> this is not true? How is this not a blatant security vulnerability?
whether they're mapped is irrelevant. if you make modifications to
the FS, the permission check counts against the meaning of the ids in
the parent namespaces. otherwise your argument is like saying "i
mapped my UID to 0 in this new usernamespace, so how is that not a
blatant security vuln".
if you started out with access to the group, then keeping that access
doesn't grant you any new privs you didn't already have.
> % touch somefile
> % chmod 660 somefile
> % sudo chown root:wheel somefile
> % unshare -r
> % cat somefile
> % # no EACCES...
you didn't show `id` before the `unshare`. if you're already in the
wheel group, what you've shown here is not a bug.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
