Message-ID: <CAKgNAkhmwK02DJQV84S+dEdrUDjzRuR32j+2gcKkgeDq8jTkuQ@mail.gmail.com>
Date:	Wed, 11 Feb 2015 09:02:30 +0100
From:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Michael Kerrisk <mtk.manpages@...il.com>,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Josh Triplett <josh@...htriplett.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Kees Cook <keescook@...omium.org>,
	Linux API <linux-api@...r.kernel.org>,
	linux-man <linux-man@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LSM <linux-security-module@...r.kernel.org>,
	Casey Schaufler <casey@...aufler-ca.com>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Richard Weinberger <richard@....at>,
	Kenton Varda <kenton@...dstorm.io>,
	stable <stable@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH 2/2] user_namespaces.7: Update the documention to reflect
 the fixes for negative groups

Hi Eric,

Ping!

Cheers,

Michael


On 2 February 2015 at 16:37, Michael Kerrisk (man-pages)
<mtk.manpages@...il.com> wrote:
> Hi Eric,
>
> Thanks for writing this up!
>
> On 12/12/2014 10:54 PM, Eric W. Biederman wrote:
>>
>> Files with access permissions such as ---rwx---rwx give fewer
>> permissions to their group then they do to everyone else.  Which means
>> dropping groups with setgroups(0, NULL) actually grants a process
>> privileges.
>>
>> The uprivileged setting of gid_map turned out not to be safe after
>> this change.  Privilege setting of gid_map can be interpreted as
>> meaning yes it is ok to drop groups.
>
> I had trouble to parse that sentence (and I'd like to make sure that
> the right sentence ends up in the commit message). Did you mean:
>
>     "*Unprivileged* setting of gid_map can be interpreted as meaning
>      yes it is ok to drop groups"
>
> ?
>
> Or something else?
>
>> To prevent this problem and future problems user namespaces were
>> changed in such a way as to guarantee a user can not obtain
>> credentials without privilege they could not obtain without the
>> help of user namespaces.
>>
>> This meant testing the effective user ID and not the filesystem user
>> ID as setresuid and setregid allow setting any process uid or gid
>> (except the supplemental groups) to the effective ID.
>>
>> Furthermore to preserve in some form the useful applications that have
>> been setting gid_map without privilege the file /proc/[pid]/setgroups
>> was added to allow disabling setgroups.  With the setgroups system
>> call permanently disabled in a user namespace it again becomes safe to
>> allow writes to gid_map without privilege.
>>
>> Here is my meager attempt to update user_namespaces.7 to reflect these
>> issues.
>
> It looked pretty serviceable as patch, IMO. So, thanks again. I've applied,
> tweaking some wordings afterward, but changing nothing essential. See below
> for a question.
>
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> ---
>>  man7/user_namespaces.7 | 52 +++++++++++++++++++++++++++++++++++++++++++++++---
>>  1 file changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/man7/user_namespaces.7 b/man7/user_namespaces.7
>> index d76721d9a0a1..f8333a762308 100644
>> --- a/man7/user_namespaces.7
>> +++ b/man7/user_namespaces.7
>> @@ -533,11 +533,16 @@ One of the following is true:
>>  The data written to
>>  .I uid_map
>>  .RI ( gid_map )
>> -consists of a single line that maps the writing process's filesystem user ID
>> +consists of a single line that maps the writing process's effective user ID
>>  (group ID) in the parent user namespace to a user ID (group ID)
>>  in the user namespace.
>> -The usual case here is that this single line provides a mapping for user ID
>> -of the process that created the namespace.
>> +The writing process must have the same effective user ID as the process
>> +that created the user namespace.
>> +In the case of
>> +.I gid_map
>> +the
>> +.I setgroups
>> +file must have been written to earlier and disabled the setgroups system call.
>>  .IP * 3
>>  The opening process has the
>>  .BR CAP_SETUID
>> @@ -552,6 +557,47 @@ Writes that violate the above rules fail with the error
>>  .\"
>>  .\" ============================================================
>>  .\"
>> +.SS Interaction with system calls that change the uid or gid values
>> +When in a user namespace where the
>> +.I uid_map
>> +or
>> +.I gid_map
>> +file has not been written the system calls that change user IDs
>> +or group IDs respectively will fail.  After the
>> +.I uid_map
>> +and
>> +.I gid_map
>> +file have been written only the mapped values may be used in
>> +system calls that change user IDs and group IDs.
>> +
>> +For user IDs these system calls include
>> +.BR setuid ,
>> +.BR setfsuid ,
>> +.BR setreuid ,
>> +and
>> +.BR setresuid .
>> +
>> +For group IDs these system calls include
>> +.BR setgid ,
>> +.BR setfsgid ,
>> +.BR setregid ,
>> +.BR setresgid ,
>> +and
>> +.BR setgroups.
>> +
>> +Writing
>> +.BR deny
>> +to the
>> +.I /proc/[pid]/setgroups
>> +file before writing to
>> +.I /proc/[pid]/gid_map
>> +will permanently disable the setgroups system call in a user namespace
>> +and allow writing to
>> +.I /proc/[pid]/gid_map
>> +without
>> +.BR CAP_SETGID
>> +in the parent user namespace.
>
> I just want to double check: you really did mean to write "*parent* namespace"
> above, right?
>
> Thanks,
>
> Michael
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists