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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 816FDC83F10 for ; Thu, 31 Aug 2023 15:13:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9609E8D0011; Thu, 31 Aug 2023 11:13:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 910618D0001; Thu, 31 Aug 2023 11:13:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B10D8D0011; Thu, 31 Aug 2023 11:13:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 698DC8D0001 for ; Thu, 31 Aug 2023 11:13:26 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2D99B4022D for ; Thu, 31 Aug 2023 15:13:26 +0000 (UTC) X-FDA: 81184743612.03.365BEC0 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by imf14.hostedemail.com (Postfix) with ESMTP id 6349510003B for ; Thu, 31 Aug 2023 15:13:23 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=sUKzuSaL; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf14.hostedemail.com: domain of zohar@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=zohar@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693494803; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9RvTIMXhjg+qCqq55rO5Im9gWOH18IqnefVeYQcqlpw=; b=gD4M9g7/g/DHS1MrlDF3KnQW72LRh8QZxWccyIBCwxDNR/n/GmUux6X5jO4zIddmTW4Dfs h1rdELNVOCdCPPpdEARKK7teKVkA+S513XtSu9oe0IxD6xtW2yvM/2Glb2lATQo1+z3+iS lDEe9/GVhky0P+my/P7yMUzXMlw36lo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=sUKzuSaL; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf14.hostedemail.com: domain of zohar@linux.ibm.com designates 148.163.158.5 as permitted sender) smtp.mailfrom=zohar@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693494803; a=rsa-sha256; cv=none; b=8Pxlq5FQA/uJjBp0XjXMlIAqTghnkI7BFdfCdfM/WNj1xCSLgUemDKtK5iu8uoUCBF/IE7 9surudvnDHHJMxEWd8m7u0dNM4yruoYfpPn9TA7D09ISqktc5Nxxqcwh71meq0ZbJDXah7 EC0yjXGh6cipuE1b2I7H5SHhfCkFsHw= Received: from pps.filterd (m0353723.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 37VFApXQ025576; Thu, 31 Aug 2023 15:13:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=9RvTIMXhjg+qCqq55rO5Im9gWOH18IqnefVeYQcqlpw=; b=sUKzuSaLWqVaK7xzlZZKc/neNRUMtC96rpENhfE9ftLEChfAO8G1/jGU5Xlo/HAb+Eb1 S1pIInrtkMOt9rm2u5G4quxpgoMbf2H8G4RIv9joUHgvXnaIIMzfY2nJf03PURlf3NkW mehkbsI4WLaD2Q2CrJAC1c3FYxD/2iQUdg/oHlt4YNqdTVBe+ZTAESt5NcNrC3oUJsOv GQyHluIPNgvePTlXbG9b6tMRU3O+7dkYCTq+IRzj60conEFv6u5JUohaIsASNSk1cpKj rqUByt7uGkdz3/mfKHEiSteQNaT/uo2SeBwlPURrmCpNPkoXWaHeo0l7PyUD/LnMF4aa wg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3stvcu9prc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2023 15:13:19 +0000 Received: from m0353723.ppops.net (m0353723.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 37VFCre6004922; Thu, 31 Aug 2023 15:13:18 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3stvcu9pr0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2023 15:13:18 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 37VDeZm0020344; Thu, 31 Aug 2023 15:13:17 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([172.16.1.69]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3sqv3ywm34-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Aug 2023 15:13:17 +0000 Received: from smtpav04.wdc07v.mail.ibm.com (smtpav04.wdc07v.mail.ibm.com [10.39.53.231]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 37VFDHU665863978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2023 15:13:17 GMT Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 388E0582B8; Thu, 31 Aug 2023 15:13:17 +0000 (GMT) Received: from smtpav04.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2E4FA582B7; Thu, 31 Aug 2023 15:13:16 +0000 (GMT) Received: from li-f45666cc-3089-11b2-a85c-c57d1a57929f.ibm.com (unknown [9.61.58.247]) by smtpav04.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 31 Aug 2023 15:13:16 +0000 (GMT) Message-ID: Subject: Re: LSM hook ordering in shmem_mknod() and shmem_tmpfile()? From: Mimi Zohar To: Christian Brauner , Hugh Dickins Cc: Paul Moore , Al Viro , Andrew Morton , linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org, linux-mm@kvack.org, linux-integrity@vger.kernel.org Date: Thu, 31 Aug 2023 11:13:15 -0400 In-Reply-To: <20230831-nachverfolgen-meditation-dcde56b10df7@brauner> References: <20230831-nachverfolgen-meditation-dcde56b10df7@brauner> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.28.5 (3.28.5-22.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: usbwRtpZUpkBHG1yUJFauP0_n1EYK3rs X-Proofpoint-GUID: X0Ta0lRbupOh8WdDS0J7wA2c2Tdi1No1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-31_13,2023-08-31_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1011 malwarescore=0 mlxlogscore=999 impostorscore=0 spamscore=0 mlxscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000 definitions=main-2308310135 X-Rspamd-Queue-Id: 6349510003B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: wan53hzhjzghbr6z8dw5s9g4wxf5x6oe X-HE-Tag: 1693494803-837798 X-HE-Meta: U2FsdGVkX19WICSIhCdrf0D2qoC+Q5Fa0sIaSWuoQQE/s9G4c3TwaPxF5e221Si/6KKWNmha8TR6lXLyOGkUAEGoarcivIQkpl0Axmw93oJuqS/0RiZNn8CbAjqT9zsG5VO0XAQgnCxWVeYJAX2V9IEC0bF+PuH/Pv8d/hFHFmKPcU+5D+CNd30MgQopAtUMLutle9QThq68sOzdd/Me+MQw4CSTIjHRrW8PE+wDCPn9oF4GvOfHHvuRlhboNlj2n5Ks15jdbf+qL09tvp24g2qpdh+hJmd0WD4sArjre+DzrU9n5N2MptogTFd/BMCXmmRvsQoHqSU4D3kUEiLot27q15FNvotGCuaPexJI5kXVeN01zhjaq2maMfSWY+Gl4fUa7FvgIzNbTc/0w2uWM/repyQ/LLTAEtKFPbydvc5lJs3QHToGlRmF8nXaM5qy0nI2ti2i+l5AhEfcT6cBD323R+8/07/cT/MJvsAq/pLE1iJmNTP/TDBGIU+lOoJaBw9iQmG7BhOzzFU0n4Z00/4wvWJ/g0n4Vv8ccNb1EKntgjytia8pUcDyJNy2+7GnWLujsqLWYpvMaNsrK28px1ieiBMaab3EUqAcB6fGlDgJZxHwEeJz6RSsDkEc9ItAu/pbRofhKxLUHD0HTstfqc/6miQmk1i4JBoZLvRLSCLnuRocsa/W1IU2DkclP2XLN9zEo3NWkftJwaQ+5Ye8pJVzbrBXD6TWX7VuP8g+O9868uOK5swBGItYm36/m56b2/Urk0G9TK9TP+GZAVI9h/9SDeUZ0peji1GtWHghqVuyYNIk7X9FGyVQix7Hj2khud1NsAhB0jQ+CiDRmtvJAREOg99NRQTaTjXAT461hDzX9X8SOBGWjwTpVulHFoJ4gbBwKSS6yzQeSjU4Mi4OZ4NdKkyAEh6GhChwek+Czzg5jBtFPC3eN+I3yQ/yR7R9iSLuGAEoYoWdvw4QNK3 aT+BEyCj wQQFMnU0f+EYOn+PFuFDnK7afjFraOQTgbL9p5I4Hy6ZsmKThcPXj0v+i/FNsZDjIB0rw05M4GIL/Uf4CxIf2QxZ3RpwNdEMAVP1p/aag7YLnNt/F4tjfpWBy7VZtenpO+i1BPEj8OPGgt/aSsCwJv5q5jcymtC86ObeRjeVvYNAodgD2yV/0U8KnHvpqiw8LYvPms9RlUjDB8hG7C4pcK7MRQWYXey9fPPANt3kcgDizSbKO+JCk6vARgOuuniYHVxdS 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: On Thu, 2023-08-31 at 14:36 +0200, Christian Brauner wrote: > On Thu, Aug 31, 2023 at 02:19:20AM -0700, Hugh Dickins wrote: > > On Wed, 30 Aug 2023, Paul Moore wrote: > > > > > Hello all, > > > > > > While looking at some recent changes in mm/shmem.c I noticed that the > > > ordering between simple_acl_create() and > > > security_inode_init_security() is different between shmem_mknod() and > > > shmem_tmpfile(). In shmem_mknod() the ACL call comes before the LSM > > > hook, and in shmem_tmpfile() the LSM call comes before the ACL call. > > > > > > Perhaps this is correct, but it seemed a little odd to me so I wanted > > > to check with all of you to make sure there is a good reason for the > > > difference between the two functions. Looking back to when > > > shmem_tmpfile() was created ~2013 I don't see any explicit mention as > > > to why the ordering is different so I'm looking for a bit of a sanity > > > check to see if I'm missing something obvious. > > > > > > My initial thinking this morning is that the > > > security_inode_init_security() call should come before > > > simple_acl_create() in both cases, but I'm open to different opinions > > > on this. > > > > Good eye. The crucial commit here appears to be Mimi's 3.11 commit > > 37ec43cdc4c7 "evm: calculate HMAC after initializing posix acl on tmpfs" > > which intentionally moved shmem_mknod()'s generic_acl_init() up before > > the security_inode_init_security(), around the same time as Al was > > copying shmem_mknod() to introduce shmem_tmpfile(). > > > > I'd have agreed with you, Paul, until reading Mimi's commit: > > now it looks more like shmem_tmpfile() is the one to be changed, > > except (I'm out of my depth) maybe it's irrelevant on tmpfiles. > > POSIX ACLs generally need to be set first as they are may change inode > properties that security_inode_init_security() may rely on to be stable. > That specifically incudes inode->i_mode: > > * If the filesystem doesn't support POSIX ACLs then the umask is > stripped in the VFS before it ever gets to the filesystems. For such > cases the order of *_init_security() and setting POSIX ACLs doesn't > matter. > * If the filesystem does support POSIX ACLs and the directory of the > resulting file does have default POSIX ACLs with mode settings then > the inode->i_mode will be updated. > * If the filesystem does support POSIX ACLs but the directory doesn't > have default POSIX ACLs the umask will be stripped. > > (roughly from memory) > > If tmpfs is compiled with POSIX ACL support the mode might change and if > anything in *_init_security() relies on inode->i_mode being stable it > needs to be called after they have been set. > > EVM hashes do use the mode and the hash gets updated when POSIX ACLs are > changed - which caused me immense pain when I redid these codepaths last > year. > > IMHO, the easiest fix really is to lump all this together for all > creation paths. This is what most filesystems do. For examples, see > > xfs_generic_create() > -> posix_acl_create(&mode) > -> xfs_create{_tmpfile}(mode) > -> xfs_inode_init_security() > > or > > __ext4_new_inode() > -> ext4_init_acl() > -> ext4_init_security() Agreed. Thanks, Hugh, Christian for the clear explanation.