Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp14064334pxu; Mon, 4 Jan 2021 11:54:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJz92pgpU3g55H6v//L/wEjzUsFpwSBv5Ej6W9ZOSu0QRTf69j0K7ex7FdD1OWB6esCyciGB X-Received: by 2002:aa7:c7d8:: with SMTP id o24mr73207544eds.328.1609790097543; Mon, 04 Jan 2021 11:54:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609790097; cv=none; d=google.com; s=arc-20160816; b=YgS+WP8Y+2M5QRUqR79VoaDdeA+XX4viuHeOpqyUMbubag3T17oiGAukyajMJkDVmc QKSxohRxfr3HIrMK5vo709cqoiQtnCe2a+UH+fih49U10G8r/F3Bnsj8QTeU4vFoALd9 CZhBG62EGboelmHICi13O+EdQ40OFUAcPClfwzPylelVGV2x8/4Q4S6pGkWXsvovHGAK xXb0vE0olUowPWmbNxv4UiGHYDFEKe2G8nZosLbuDTw9Lz1RlEHQXeS2j8of8F6Ttzmc /rKyA/EmsmmRPdnLb2qUeUbzel1p4SQltewORiNx2CcfJEA+Hcvlo4PL//9jdMywn4iG Zg7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=aR5E33ngmM7rA62zOVK1kNDHyQ1ZhIMHNofceRK43oY=; b=arrFAFDlsR0np7JMXNO3SrY7Ko/hRkJBVclVE8q59lu8Zru2eSkyEq9ZUIE8dBiVsN LzEkITALmVlNx2hFel8KnCNO8MUchhlN2OefZ29HjwPd8NUEkvX2MN5XGJoJYO25qS3U /bmZ4vqY85uWfkRIVjoIiCqSe2s7+kf0vZ7B0SJpC+pR/r47HsJPjnMZ7YJcXtkwvOVo OZu1u/0Qrkcp+5aJWHZWOJzde0nYafTpM1D2Nbm69uxJV9VPEOMZ9qKTT5D+Duk65Cx2 Ta1VCXjmyfI8Y7INHV3zqA3nf3DJkMJsTk7MskJ/ZfxGvOZ/h3A/qDSQO2TUpOoUF1zY alHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=tZ6PDIrm; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b11si32285303edz.485.2021.01.04.11.54.34; Mon, 04 Jan 2021 11:54:57 -0800 (PST) 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; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=tZ6PDIrm; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727767AbhADTw0 (ORCPT + 99 others); Mon, 4 Jan 2021 14:52:26 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:43326 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726074AbhADTw0 (ORCPT ); Mon, 4 Jan 2021 14:52:26 -0500 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 104JhsRt035793; Mon, 4 Jan 2021 19:51:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=corp-2020-01-29; bh=aR5E33ngmM7rA62zOVK1kNDHyQ1ZhIMHNofceRK43oY=; b=tZ6PDIrmrYEHFS6MJkkZg39L4P9UbJPfi96nsJzOXI7+dwovQUhsLnxFeQo+B9Uvq+6m dHovtt15YZRSJL1tCLKJOj/FIa0oBOERJDWL+yD6xe7a8cOTbS/YfKi3XouEcMxrsJJO rgd3Ttio6mVEagOCaIcNLq56zQIy2669/WrkV8XgJIy0oGXg+qEgraSGVxASAsByRRvs 7JaYIQ/kzXpZTP+FH1NNk3zHrCcRjAWJn6yWThEk8uuHvaRvFx6NoVcJz26WMdhDUrSe CRgzS+5Vz0kySVly0+wSrJf8vi8gztS5QM4Tg3gnxlUnX+h2qgg39glbKJ27Ki7rShUB 6w== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 35tg8qwyfj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 04 Jan 2021 19:51:22 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 104JihXY093653; Mon, 4 Jan 2021 19:51:21 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 35v1f7rp4p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Jan 2021 19:51:21 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 104Jp8Xv017494; Mon, 4 Jan 2021 19:51:08 GMT Received: from localhost (/10.159.240.116) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 04 Jan 2021 11:51:07 -0800 From: Stephen Brennan To: Stephen Smalley Cc: Alexey Dobriyan , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , SElinux list , Casey Schaufler , Eric Biederman , Alexander Viro , Linux FS Devel , linux-kernel , Matthew Wilcox Subject: Re: [PATCH v3 2/2] proc: ensure security hook is called after exec In-Reply-To: References: <20201219000616.197585-1-stephen.s.brennan@oracle.com> <20201219000616.197585-2-stephen.s.brennan@oracle.com> Date: Mon, 04 Jan 2021 11:51:07 -0800 Message-ID: <87pn2k5vmc.fsf@stepbren-lnx.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9854 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0 suspectscore=0 spamscore=0 bulkscore=0 adultscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040124 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9854 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 phishscore=0 bulkscore=0 spamscore=0 impostorscore=0 suspectscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101040124 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stephen Smalley writes: > On Fri, Dec 18, 2020 at 7:06 PM Stephen Brennan > wrote: >> >> Smack needs its security_task_to_inode() hook to be called when a task >> execs a new executable. Store the self_exec_id of the task and call the >> hook via pid_update_inode() whenever the exec_id changes. >> >> Signed-off-by: Stephen Brennan > > Sorry to be late in responding, but the proc inode security structure > needs to be updated not only upon a context-changing exec but also > upon a setcon(3) aka write to /proc/self/attr/current just like the > uid/gid needs to be updated not only upon a setuid exec but also upon > a setuid(2). I'm also unclear as to why you can't call > security_task_to_inode during RCU lookup; it doesn't block/sleep > AFAICT. > All it does is take a spinlock and update a few fields. The reason I assumed that we need to drop out of RCU mode to update the inode and call the security hooks was simply because that is how the code worked originally. I wanted to be conservative in my changes, by only leaving RCU mode "when necessary", but this assumed that it was necessary to leave RCU mode at all! None of the data in a proc inode (at least, i_mode, i_uid, i_gid) seems to be "RCU protected" in the sense that they could not be modified during an RCU read critical section. If this were the case, then there would have to be some sort of copying and a synchronize_rcu() used somewhere. So it seems that running pid_update_inode() (which does not sleep and simply takes some spinlocks) should be safe during RCU mode. My assumption had originally been that the security_pid_to_inode() calls could be liable to sleep. But during this review we've seen that both the selinux and smack security_pid_to_inode() implementations are also "RCU safe" in that they do not sleep. So rather than trying to guess when this security hook would like to be called, it seems that it would be safe to take the easiest option: just execute pid_revalidate() in RCU mode always, for instance with the example changes below. Is there anything obviously wrong with this approach that I'm missing? diff --git a/fs/proc/base.c b/fs/proc/base.c index ebea9501afb8..105581e51032 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -1830,19 +1830,18 @@ static int pid_revalidate(struct dentry *dentry, unsigned int flags) { struct inode *inode; struct task_struct *task; + int rv = 0; - if (flags & LOOKUP_RCU) - return -ECHILD; - - inode = d_inode(dentry); - task = get_proc_task(inode); + rcu_read_lock(); + inode = d_inode_rcu(dentry); + task = pid_task(proc_pid(inode), PIDTYPE_PID); if (task) { pid_update_inode(task, inode); - put_task_struct(task); - return 1; + rv = 1; } - return 0; + rcu_read_unlock(); + return rv; } static inline bool proc_inode_is_dead(struct inode *inode)