Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932292AbbBBPho (ORCPT ); Mon, 2 Feb 2015 10:37:44 -0500 Received: from mail-we0-f172.google.com ([74.125.82.172]:39661 "EHLO mail-we0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbbBBPhk (ORCPT ); Mon, 2 Feb 2015 10:37:40 -0500 Message-ID: <54CF99BF.8050401@gmail.com> Date: Mon, 02 Feb 2015 16:37:35 +0100 From: "Michael Kerrisk (man-pages)" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Eric W. Biederman" CC: mtk.manpages@gmail.com, Linux Containers , Josh Triplett , Andrew Morton , Kees Cook , Linux API , linux-man , "linux-kernel@vger.kernel.org" , LSM , Casey Schaufler , "Serge E. Hallyn" , Richard Weinberger , Kenton Varda , stable , Andy Lutomirski Subject: Re: [PATCH 2/2] user_namespaces.7: Update the documention to reflect the fixes for negative groups References: <52e0643bd47b1e5c65921d6e00aea1f724bb510a.1417281801.git.luto@amacapital.net> <87h9x5re41.fsf_-_@x220.int.ebiederm.org> <87mw6xpzb0.fsf_-_@x220.int.ebiederm.org> <87ppbtn4mv.fsf@x220.int.ebiederm.org> <87a92xn2io.fsf@x220.int.ebiederm.org> <87r3w8liw4.fsf@x220.int.ebiederm.org> <87iohklfvj.fsf_-_@x220.int.ebiederm.org> <87fvcok11h.fsf_-_@x220.int.ebiederm.org> <971ad3f6-90fd-4e3f-916c-8988af3c826d@email.android.com> <87wq5zf83t.fsf@x220.int.ebiederm.org> <87iohh3c9c.fsf@x220.int.ebiederm.org> <8761dh3b7k.fsf_-_@x220.int.ebiederm.org> <878uicy1r9.fsf_-_@x220.int.ebiederm.org> <87ppbo1ql4.fsf_-_@x220.int.ebiederm.org> In-Reply-To: <87ppbo1ql4.fsf_-_@x220.int.ebiederm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4584 Lines: 138 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" > --- > 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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/