Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1286218pxu; Wed, 6 Jan 2021 18:47:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJwA8yWkZfuHWE1DKIdEVTMRI/pt3Wfqag/LN86nk3EJgYDSoslV6Rok+34HvU3EfDT/3XFb X-Received: by 2002:a50:a684:: with SMTP id e4mr49937edc.148.1609987622657; Wed, 06 Jan 2021 18:47:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609987622; cv=none; d=google.com; s=arc-20160816; b=GgsMG98eMw/w7pmH7AGhrYWnf8y0A+DzorzuFgGxZ6nuvRhGKTm2Zs2bDfbxJMACCT ldNhiJZupZNkXpYlEwW5aBSVnXQEqED9eXmU4+PT0OR0js33QUJSHGobPS2FMlQhMPDm 38fhForPq/MtJo5n+IOUDE4HXcz3p/M8oWEeJTEkwj4Z/+GxZzpRUu/vm5n29Bc2no6x Ka5dohFNpKOUs8i7Ik5fVweVmnugn786jVQVZT2iGJ3TPyyYJkHH15PsHOOAls7gktD6 OWRwL2gb6wNGrGn9z8jK0g3lxNGgSnYKMgxe7G/3Xjv39Ku1fzyqn3D3awzRs4YzLxid A/fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=OMOKHTGqmc8H/goueItvedsRqkw1V7cr/6m0zsCokxw=; b=boK4ngxx57E4kmit0m7x8zQkiI3BjeRTNzl4RZkefEebM493Mx6C2UIVXIPBbFLUqu hCBUKjOGFVRdGKPBTA9LPegd+T7xIGmhnsE/Kn3y0vR9PGY21uB1qmDpakOve2u9m6E/ cYrjjRE4++vD1r60Ul3sWj//RYgQGlNQuBcApaMy0NI3TEu97U6Wr4X98za76MR/LDzw x0yzCmCqK/c1UojOmoQw0wLQehQ41NuomPs3rSXnM+EwpEiLvZd2z4iKKRLSQYJ6dIM2 TWdTQfryJ0RR9kBm00qSwDwDeruGEiC0v/+fpELJlag0QcrOq9s/EGHvsYb+AJC+rn1A CQ1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=gyKgWQMw; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lr26si1717924ejb.312.2021.01.06.18.46.36; Wed, 06 Jan 2021 18:47:02 -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=@google.com header.s=20161025 header.b=gyKgWQMw; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726794AbhAGCoq (ORCPT + 99 others); Wed, 6 Jan 2021 21:44:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726776AbhAGCop (ORCPT ); Wed, 6 Jan 2021 21:44:45 -0500 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A62D9C0612F1 for ; Wed, 6 Jan 2021 18:44:04 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id dk8so6366090edb.1 for ; Wed, 06 Jan 2021 18:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OMOKHTGqmc8H/goueItvedsRqkw1V7cr/6m0zsCokxw=; b=gyKgWQMwx/fTejAGvT1hbN4rzR75Q1DifGuW0ra4ZEh5ftPL8zEY4t7NeUB5EqUJIP V0blI2KlAUL8JdQVW1/c+YtmoKvSecARmdppSAdJYwjqwe/NAn3+4wgklIhNTeyRgS2R w05YjLwZpGCyHcKUIJ/Q9oRznw0AcM1r6qF2WK8yj2Gz4MdsT0ZzuGaOFI76AfGJc2vB fRfb9WoD4qo932KS+okUkD744Ux7YW9MuYc+QPYgL2COSkrIEsAppNS2ztQqRuSfYtsG h2dl0xVbrXhvaYsJ5Q0MN+c2J+kcXRHWrwA8MSZaUbxeWccd8go9LR8zrFLnrFjcMQZ6 aBhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OMOKHTGqmc8H/goueItvedsRqkw1V7cr/6m0zsCokxw=; b=LSnXkHinunZbgqwPmxX2nWb8dm/N9BfF9Dd5pr1k9AtsB+5idUTmdoWFGRGdbhHDU4 TZ6HVjR6xww4wop5wl72+U4zoW05GyAlwnUbSki0q56+h2/u3l9Z0fK3WMouYl+FufE7 Ln2Q4IAUojq/CJQ+JjZboPW5HsMdrU8roMCj9gm2FTpwA/we+o9dz8Z7xK5GFN/tA5l5 QMML3qf3QOR+rHOD+8nzBdVWPW7jRwIEYIi+6gMrTyLMFCEQ4ZeGuT1lgNnIoagyiAXk K7Sr0hE3QwPV+JF7MMr5h66FWaJL7EotPeAIZNpcBN/NKDZLOKBYo52SLJUWcDiTYGtL 7b3g== X-Gm-Message-State: AOAM531ukWNhRpdKHwrlUyqY7W5D7IqtxdW7DgWt+Sn+PeJPrQEFyxfQ voNT/OIKQ5iGV2bmWSb6VPDgp+TDRNdaDj16shlIxQ== X-Received: by 2002:a05:6402:1ad1:: with SMTP id ba17mr29013edb.51.1609987443025; Wed, 06 Jan 2021 18:44:03 -0800 (PST) MIME-Version: 1.0 References: <20201112015359.1103333-1-lokeshgidra@google.com> <20201112015359.1103333-3-lokeshgidra@google.com> In-Reply-To: From: Lokesh Gidra Date: Wed, 6 Jan 2021 18:43:52 -0800 Message-ID: Subject: Re: [PATCH v13 2/4] fs: add LSM-supporting anon-inode interface To: Paul Moore Cc: Andrea Arcangeli , Alexander Viro , James Morris , Stephen Smalley , Casey Schaufler , Eric Biggers , "Serge E. Hallyn" , Eric Paris , Daniel Colascione , Kees Cook , "Eric W. Biederman" , KP Singh , David Howells , Anders Roxell , Sami Tolvanen , Matthew Garrett , Aaron Goidel , Randy Dunlap , "Joel Fernandes (Google)" , YueHaibing , Christian Brauner , Alexei Starovoitov , Alexey Budankov , Adrian Reber , Aleksa Sarai , Linux FS Devel , linux-kernel , LSM List , SElinux list , Kalesh Singh , Calin Juravle , Suren Baghdasaryan , Jeffrey Vander Stoep , "Cc: Android Kernel" , "open list:MEMORY MANAGEMENT" , Andrew Morton , hch@infradead.org, Daniel Colascione , Eric Biggers Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 6, 2021 at 6:10 PM Paul Moore wrote: > > On Wed, Nov 11, 2020 at 8:54 PM Lokesh Gidra wrote: > > From: Daniel Colascione > > > > This change adds a new function, anon_inode_getfd_secure, that creates > > anonymous-node file with individual non-S_PRIVATE inode to which security > > modules can apply policy. Existing callers continue using the original > > singleton-inode kind of anonymous-inode file. We can transition anonymous > > inode users to the new kind of anonymous inode in individual patches for > > the sake of bisection and review. > > > > The new function accepts an optional context_inode parameter that callers > > can use to provide additional contextual information to security modules. > > For example, in case of userfaultfd, the created inode is a 'logical child' > > of the context_inode (userfaultfd inode of the parent process) in the sense > > that it provides the security context required during creation of the child > > process' userfaultfd inode. > > > > Signed-off-by: Daniel Colascione > > > > [Delete obsolete comments to alloc_anon_inode()] > > [Add context_inode description in comments to anon_inode_getfd_secure()] > > [Remove definition of anon_inode_getfile_secure() as there are no callers] > > [Make __anon_inode_getfile() static] > > [Use correct error cast in __anon_inode_getfile()] > > [Fix error handling in __anon_inode_getfile()] > > Lokesh, I'm assuming you made the changes in the brackets above? If > so they should include your initials or some other means of > attributing them to you, e.g. "[LG: Fix error ...]". Thanks for reviewing the patch. Sorry for missing this. If it's critical then I can upload another version of the patches to fix this. Kindly let me know. > > > Signed-off-by: Lokesh Gidra > > Reviewed-by: Eric Biggers > > --- > > fs/anon_inodes.c | 150 ++++++++++++++++++++++++++---------- > > fs/libfs.c | 5 -- > > include/linux/anon_inodes.h | 5 ++ > > 3 files changed, 115 insertions(+), 45 deletions(-) > > > > diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c > > index 89714308c25b..023337d65a03 100644 > > --- a/fs/anon_inodes.c > > +++ b/fs/anon_inodes.c > > @@ -55,61 +55,79 @@ static struct file_system_type anon_inode_fs_type = { > > .kill_sb = kill_anon_super, > > }; > > > > -/** > > - * anon_inode_getfile - creates a new file instance by hooking it up to an > > - * anonymous inode, and a dentry that describe the "class" > > - * of the file > > - * > > - * @name: [in] name of the "class" of the new file > > - * @fops: [in] file operations for the new file > > - * @priv: [in] private data for the new file (will be file's private_data) > > - * @flags: [in] flags > > - * > > - * Creates a new file by hooking it on a single inode. This is useful for files > > - * that do not need to have a full-fledged inode in order to operate correctly. > > - * All the files created with anon_inode_getfile() will share a single inode, > > - * hence saving memory and avoiding code duplication for the file/inode/dentry > > - * setup. Returns the newly created file* or an error pointer. > > - */ > > -struct file *anon_inode_getfile(const char *name, > > - const struct file_operations *fops, > > - void *priv, int flags) > > +static struct inode *anon_inode_make_secure_inode( > > + const char *name, > > + const struct inode *context_inode) > > { > > - struct file *file; > > + struct inode *inode; > > + const struct qstr qname = QSTR_INIT(name, strlen(name)); > > + int error; > > + > > + inode = alloc_anon_inode(anon_inode_mnt->mnt_sb); > > + if (IS_ERR(inode)) > > + return inode; > > + inode->i_flags &= ~S_PRIVATE; > > + error = security_inode_init_security_anon(inode, &qname, context_inode); > > + if (error) { > > + iput(inode); > > + return ERR_PTR(error); > > + } > > + return inode; > > +} > > > > - if (IS_ERR(anon_inode_inode)) > > - return ERR_PTR(-ENODEV); > > +static struct file *__anon_inode_getfile(const char *name, > > + const struct file_operations *fops, > > + void *priv, int flags, > > + const struct inode *context_inode, > > + bool secure) > > Is it necessary to pass both the context_inode pointer and the secure > boolean? It seems like if context_inode is non-NULL then one could > assume that a secure anonymous inode was requested; is there ever > going to be a case where this is not true? Yes, it is necessary as there are scenarios where a secure anon-inode is to be created but there is no context_inode available. For instance, in patch 4/4 of this series you'll see that when a secure anon-inode is created in the userfaultfd syscall, context_inode isn't available. > > > +{ > > + struct inode *inode; > > + struct file *file; > > > > if (fops->owner && !try_module_get(fops->owner)) > > return ERR_PTR(-ENOENT); > > > > - /* > > - * We know the anon_inode inode count is always greater than zero, > > - * so ihold() is safe. > > - */ > > - ihold(anon_inode_inode); > > - file = alloc_file_pseudo(anon_inode_inode, anon_inode_mnt, name, > > + if (secure) { > > + inode = anon_inode_make_secure_inode(name, context_inode); > > + if (IS_ERR(inode)) { > > + file = ERR_CAST(inode); > > + goto err; > > + } > > + } else { > > + inode = anon_inode_inode; > > + if (IS_ERR(inode)) { > > + file = ERR_PTR(-ENODEV); > > + goto err; > > + } > > + /* > > + * We know the anon_inode inode count is always > > + * greater than zero, so ihold() is safe. > > + */ > > + ihold(inode); > > + } > > + > > + file = alloc_file_pseudo(inode, anon_inode_mnt, name, > > flags & (O_ACCMODE | O_NONBLOCK), fops); > > if (IS_ERR(file)) > > - goto err; > > + goto err_iput; > > > > - file->f_mapping = anon_inode_inode->i_mapping; > > + file->f_mapping = inode->i_mapping; > > > > file->private_data = priv; > > > > return file; > > > > +err_iput: > > + iput(inode); > > err: > > - iput(anon_inode_inode); > > module_put(fops->owner); > > return file; > > } > > -EXPORT_SYMBOL_GPL(anon_inode_getfile); > > -- > paul moore > www.paul-moore.com