Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3995939pxt; Tue, 10 Aug 2021 17:05:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxB1+sgctmn/gJXfK+kZsTqigSNQVR5lj35zyo/OpGUcVJBPv5OCv8RaHOVDXPwL6vDhiET X-Received: by 2002:a17:906:85cc:: with SMTP id i12mr917632ejy.405.1628640340854; Tue, 10 Aug 2021 17:05:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628640340; cv=none; d=google.com; s=arc-20160816; b=JfUvuLeKZ7FvGaPwk55zBtKSpPQd54tRBj+5tj9LfPhdvNTRjDZ8SYUH/y1aLAo8D/ YOQ4y/6aM8/oluzOeuQ+hTM/c+G0jRJBUaL2oxPdEt8xZRQ03t3RZL61mO8ZuHGCNZwd rhFEDpU2Euj0WrjkU9QqyivIsdiEflhLW9lHG57Zlt0XvUzNI11WW/s3N00E/aikZJ3a zr3/eoXt5sM/9mHYq1E/h8fJnIxSbuNj0uZkL/ru4gJQjpSPRSq7DSNL23OaPAb/tiIj nstWTfctVmgl9SNCGi65pXRjZIhawbMVdzBlFydd4FW76SjEFBCmam6DAS+YmPMIVfzQ U9Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=eEPftVilwKT2lq/qiQJEY4ye30u9qo9RcWOCTMFk+3Y=; b=hYeiMHJ12uzQ7IW8Jj2lQ8LPuEzCtBEgY3jIwAmubdmOHJBTsntDpoNf9y2ahyMnxt lZ7Cap2Lq2/B9MZ7H6ybw4UMjuYhTvZAMBMrb8VjenN1VLpBd79RQQcgTu7mOc/uOTy5 lTOLn37ZJhiAFhLH6+UFdoow7M7ymM6v1TwdrtJgfSBzOQlVdmfDQgmb5dXRGbiwZG2b Lc3D860zz+k8wNziERdyQi7hyvDdBmq0nSxXvdCPtPtEZcoG+leqC0T90iZfVic7NM3q 6TXqAwxl0cL0E6pE4nr+hevcrMmOuyCPBl/+L68t7i6RsG8G40JuA64/lLTp/4/tmmrA IvcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dv20si20477799ejb.20.2021.08.10.17.05.17; Tue, 10 Aug 2021 17:05:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235652AbhHKAEE (ORCPT + 99 others); Tue, 10 Aug 2021 20:04:04 -0400 Received: from mail.hallyn.com ([178.63.66.53]:55162 "EHLO mail.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234289AbhHKAED (ORCPT ); Tue, 10 Aug 2021 20:04:03 -0400 X-Greylist: delayed 300 seconds by postgrey-1.27 at vger.kernel.org; Tue, 10 Aug 2021 20:04:02 EDT Received: by mail.hallyn.com (Postfix, from userid 1001) id 92CAE472; Tue, 10 Aug 2021 18:58:38 -0500 (CDT) Date: Tue, 10 Aug 2021 18:58:38 -0500 From: "Serge E. Hallyn" To: "Michael Kerrisk (man-pages)" Cc: "Serge E. Hallyn" , linux-security-module , lkml , Alejandro Colomar , Kir Kolyshkin , linux-man Subject: Re: Documenting the requirement of CAP_SETFCAP to map UID 0 Message-ID: <20210810235838.GA4561@mail.hallyn.com> References: <14cbab6f-19f6-a28c-05d8-453ecca62180@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <14cbab6f-19f6-a28c-05d8-453ecca62180@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Aug 08, 2021 at 11:09:30AM +0200, Michael Kerrisk (man-pages) wrote: > Hello Serge, > > Your commit: > > [[ > commit db2e718a47984b9d71ed890eb2ea36ecf150de18 > Author: Serge E. Hallyn > Date: Tue Apr 20 08:43:34 2021 -0500 > > capabilities: require CAP_SETFCAP to map uid 0 > ]] > > added a new requirement when updating a UID map a user namespace > with a value of '0 0 *'. > > Kir sent a patch to briefly document this change, but I think much more > should be written. I've attempted to do so. Could you tell me whether the > following text (to be added in user_namespaces(7)) is accurate please: Sorry for the delay - this did not go into my main mailbox. The text looks good. Thanks! > [[ > In order for a process to write to the /proc/[pid]/uid_map > (/proc/[pid]/gid_map) file, all of the following requirements must > be met: > > [...] > > 4. If updating /proc/[pid]/uid_map to create a mapping that maps > UID 0 in the parent namespace, then one of the following must > be true: > > * if writing process is in the parent user namespace, then it > must have the CAP_SETFCAP capability in that user namespace; > or > > * if the writing process is in the child user namespace, then > the process that created the user namespace must have had > the CAP_SETFCAP capability when the namespace was created. > > This rule has been in place since Linux 5.12. It eliminates an > earlier security bug whereby a UID 0 process that lacks the > CAP_SETFCAP capability, which is needed to create a binary with > namespaced file capabilities (as described in capabilities(7)), > could nevertheless create such a binary, by the following > steps: > > * Create a new user namespace with the identity mapping (i.e., > UID 0 in the new user namespace maps to UID 0 in the parent > namespace), so that UID 0 in both namespaces is equivalent > to the same root user ID. > > * Since the child process has the CAP_SETFCAP capability, it > could create a binary with namespaced file capabilities that > would then be effective in the parent user namespace (be‐ > cause the root user IDs are the same in the two namespaces). > > [...] > ]] > > Thanks, > > Michael > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/