From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 25F96C4332B for ; Sat, 21 Mar 2020 02:47:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C76932072D for ; Sat, 21 Mar 2020 02:47:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C76932072D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 733026B0007; Fri, 20 Mar 2020 22:47:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 709C96B0008; Fri, 20 Mar 2020 22:47:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6202A6B000A; Fri, 20 Mar 2020 22:47:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 4974B6B0007 for ; Fri, 20 Mar 2020 22:47:09 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E8848824556B for ; Sat, 21 Mar 2020 02:47:08 +0000 (UTC) X-FDA: 76617832536.17.arm55_788a419a58550 X-HE-Tag: arm55_788a419a58550 X-Filterd-Recvd-Size: 10243 Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05olkn2023.outbound.protection.outlook.com [40.92.89.23]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Sat, 21 Mar 2020 02:47:08 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dNTjLty013s8Td+o6PdoUKlWu8Y33c2a0O6Rlc2GxuLtf9xX3tlfinv5UtzENmJ+ik60a9TNWhBnfx4ZCsmUGlFql5gB5BmyCeqE7tHPIE8maHGpbhNtSdTUx1Czozdnk+9KKjmQwB+VRP5E/NpDiivRUJpzmQ2erD5TDfGf71tUVq3VeUez8izBFlOZFeHnmcnoWOKrUEIUsgQOFd8SXL2p9PThLxTXxLqAqGog23ayLXQewffKB+PhRVGsdzC1h9+SbEXwGMcLQy5FWgG8/5J38oJuAat4j9s2tnJOSKMLMngFX4JRwWkxzmE/bmyA8WXO4aBh7jBbOXCYnAdGLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fMxz+RuV9RQMUxgG0UAnwQ7e+XVLgekPkpYVpUFheXA=; b=BTUOB/kDKAuGJgnIGBVF/H88+AgdugmdNO2fjW3R997zrCNyqocoDrhU8b7nn2e0lCEYU7stApDojpPJuIhyl46CXOQ7IovrS5EI1wuti+M+DTbdHo7I+PT/IyUVtEqPM7Pt5oNUDVwDY46cyLJq3y/PoSD1agVJ8YVN2j0kG53oTX5vb5iZc9bnCa/anTu6TeMOwmowrBPBJ7cE2805jMxZKX1UfHV4FM4mTv2HXa57KFxuEu3fmUF5+V9Iu/h7Oc0eoXyY55YtT3gKxMLP6+mK1wYi/jk1avjf47R099dVeCTRo1bPv0KwmFCV/RzAFi0ikX9DrTfBuGK/IW7L3w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VI1EUR05FT062.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::33) by VI1EUR05HT022.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13; Sat, 21 Mar 2020 02:47:04 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com (10.233.242.53) by VI1EUR05FT062.mail.protection.outlook.com (10.233.243.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Sat, 21 Mar 2020 02:47:04 +0000 Received: from AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd]) by AM6PR03MB5170.eurprd03.prod.outlook.com ([fe80::1956:d274:cab3:b4dd%6]) with mapi id 15.20.2835.017; Sat, 21 Mar 2020 02:47:04 +0000 From: Bernd Edlinger To: "gregkh@linuxfoundation.org" , Kirill Tkhai , "Eric W. Biederman" , Christian Brauner , Kees Cook , "jannh@google.com" , Jonathan Corbet , Alexander Viro , Andrew Morton , "adobriyan@gmail.com" , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , "avagin@gmail.com" , Ingo Molnar , "Peter Zijlstra (Intel)" , "duyuyang@gmail.com" , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Shakeel Butt , Jason Gunthorpe , "christian@kellner.me" , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" , "linux-api@vger.kernel.org" Subject: [PATCH v6 16/16] doc: Update documentation of ->exec_*_mutex Thread-Topic: [PATCH v6 16/16] doc: Update documentation of ->exec_*_mutex Thread-Index: AQHV/vVmRRuSYR3ND0imHjEGSGoE8w== Date: Sat, 21 Mar 2020 02:47:04 +0000 Message-ID: <3ce46b88-7ed3-2f21-c0ed-8f6055d38ebb@hotmail.de> References: <077b63b7-6f5e-aa8e-bf96-a586b481cc46@hotmail.de> In-Reply-To: <077b63b7-6f5e-aa8e-bf96-a586b481cc46@hotmail.de> Accept-Language: en-US, en-GB, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-imapappendstamp: AM6PR03MB5170.eurprd03.prod.outlook.com (15.20.2835.016) x-incomingtopheadermarker: OriginalChecksum:D59A7125C1ECEE8EC38414552399C105A4F8B87DB3BC2846933447E6B527A079;UpperCasedChecksum:E01611456461A8E7B89DB78136D189B18EE3BAEFD2C60D65FA6942FBE887FA2F;SizeAsReceived:8475;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [FSjQ7o0dBOcWLZIQbDVvCPMI4Lsxt0vu] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 366a69d2-1471-4b70-ba6d-08d7cd4223d8 x-ms-traffictypediagnostic: VI1EUR05HT022: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q34OtT4FVmQK6n7e6GU4FNGkL06IEggWsiG7zRTqKZmX/Baf/5sXo3UPD5hyeKYXdHGV/Pmmfs7u1R/VyKmieckq5Jwgh2brCqmxWvamD7/EcAi9A3HZKbXGO9YKZME83zIji5FZufAEneTII4UvSeqTA7Zio4Fkz06ZDyJl9OG69/MN1kTy07pZrxLj/TLT x-ms-exchange-antispam-messagedata: mDB3dAqm/a2K6L0KmfdLOaVkB8BPHaNYy4wU0us/yCkizMj3ebSqd7DXb2TCopp+zepvraJQwCtJonNOQIuJjry/qaA105bGyLTKYZqN/4Ak/p2mh0WXx6solgw5jaRgooiijgaH4nXgmqGnTu/U8g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4175CD035CA92C46A2291553CAB5F9B9@sct-15-20-2387-20-msonline-outlook-45755.templateTenant> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 366a69d2-1471-4b70-ba6d-08d7cd4223d8 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2020 02:47:04.8066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR05HT022 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This brings the outdated Documentation/security/credentials.rst=0A= back in line with the current implementation, and describes the=0A= purpose of current->signal->exec_update_mutex,=0A= current->signal->exec_guard_mutex and=0A= current->signal->unsafe_execve_in_progress.=0A= =0A= Signed-off-by: Bernd Edlinger =0A= ---=0A= Documentation/security/credentials.rst | 29 +++++++++++++++++++++--------= =0A= 1 file changed, 21 insertions(+), 8 deletions(-)=0A= =0A= diff --git a/Documentation/security/credentials.rst b/Documentation/securit= y/credentials.rst=0A= index 282e79f..fe4cd76 100644=0A= --- a/Documentation/security/credentials.rst=0A= +++ b/Documentation/security/credentials.rst=0A= @@ -437,15 +437,30 @@ new set of credentials by calling::=0A= =0A= struct cred *prepare_creds(void);=0A= =0A= -this locks current->cred_replace_mutex and then allocates and constructs a= =0A= -duplicate of the current process's credentials, returning with the mutex s= till=0A= -held if successful. It returns NULL if not successful (out of memory).=0A= +this allocates and constructs a duplicate of the current process's credent= ials.=0A= +It returns NULL if not successful (out of memory).=0A= +=0A= +If called from __do_execve_file, the mutex current->signal->exec_guard_mut= ex=0A= +is acquired before this function gets called, and usually released after= =0A= +the new process mmap and credentials are installed. However if one of the= =0A= +sibling threads are being traced when the execve is invoked, there is no= =0A= +guarantee how long it takes to terminate all sibling threads, and therefor= e=0A= +the variable current->signal->unsafe_execve_in_progress is set, and the=0A= +exec_guard_mutex is released immediately. Functions that may have effect= =0A= +on the credentials of a different thread need to lock the exec_guard_mutex= =0A= +and additionally check the unsafe_execve_in_progress status, and fail with= =0A= +-EAGAIN if that variable is set.=0A= =0A= The mutex prevents ``ptrace()`` from altering the ptrace state of a proces= s=0A= while security checks on credentials construction and changing is taking p= lace=0A= as the ptrace state may alter the outcome, particularly in the case of=0A= ``execve()``.=0A= =0A= +The mutex current->signal->exec_update_mutex is acquired when only a singl= e=0A= +thread is remaining, and the credentials and the process mmap are actually= =0A= +changed. Functions that only need to access to a consistent state of the= =0A= +credentials and the process mmap do only need to aquire this mutex.=0A= +=0A= The new credentials set should be altered appropriately, and any security= =0A= checks and hooks done. Both the current and the proposed sets of credenti= als=0A= are available for this purpose as current_cred() will return the current s= et=0A= @@ -466,9 +481,8 @@ by calling::=0A= =0A= This will alter various aspects of the credentials and the process, giving= the=0A= LSM a chance to do likewise, then it will use ``rcu_assign_pointer()`` to= =0A= -actually commit the new credentials to ``current->cred``, it will release= =0A= -``current->cred_replace_mutex`` to allow ``ptrace()`` to take place, and i= t=0A= -will notify the scheduler and others of the changes.=0A= +actually commit the new credentials to ``current->cred``, and it will noti= fy=0A= +the scheduler and others of the changes.=0A= =0A= This function is guaranteed to return 0, so that it can be tail-called at = the=0A= end of such functions as ``sys_setresuid()``.=0A= @@ -486,8 +500,7 @@ invoked::=0A= =0A= void abort_creds(struct cred *new);=0A= =0A= -This releases the lock on ``current->cred_replace_mutex`` that=0A= -``prepare_creds()`` got and then releases the new credentials.=0A= +This releases the new credentials.=0A= =0A= =0A= A typical credentials alteration function would look something like this::= =0A= -- =0A= 1.9.1=0A=