Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1271617pxu; Wed, 6 Jan 2021 18:12:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJwkXYMAhiO+KW4DZ+HKVL9+xO1CMQ9pkc7VTGGELSxpS2h3ndwkCKecY2v/mLvtZPXulgmA X-Received: by 2002:a05:6402:1516:: with SMTP id f22mr5767136edw.382.1609985525193; Wed, 06 Jan 2021 18:12:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609985525; cv=none; d=google.com; s=arc-20160816; b=TbO68/Dlfn8eHL5NyWStkmcdWCm0yIg0k4FAcPxRS9Admpqr1Z3A0+ECgIC12UI5xs OoYqPvPGSYf2J0yueMlq6yqgjkZOrRwsq+Ejw1nkiHhWYUm+WhFfV+1hkON5DSK2uRC+ p1kybFSlyn8RJS4DmZKcg9vuDr31tevl3/Aq0phN0ELN5Du7GFauLN98/m0W6hmoIMXD 4j306EGmQSrqY1JRyD/P+sAc/D5Hswtp3u5SKzx7GJyU8GULEjVwrRvvwoeLrkuGrxxE UAmzMmpsMDnDK/loDQK5KAabJPk3v09wtM0zECu0aChB/RaXkt3Q496P7HIqUaDKdyzq o+dg== 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=oRYS35mQrlbPBmZbRi04L5UchKku0XQLiBg5o+NaYE4=; b=mGXhuzuR5G/RI6ostzArMe703yWjsge9FCJJrncCwA7yR5r7YKhpK6bVYJ3yfmoloL 9J1lZPIHntdCRAWcgwRXZrHUFX+ycaOOhFWoX/mUhV9+gV1OkCEPHz+fmcEeai7mK7Vv shHwjC2KGPvTTS8gjtTmQ2ez6pQ3nh7twNQAoqBlWGpEEEZ5eLIbQ/kJpqLrQsPFsepU JT9QCUr1CChUK42hIOs0n+Jz1KohvV2w9mqDE8r/1LSE2ktmx7o4qnKbqStdhF5ySwrf 6H3DLbfCA9D+VkyBhIr9tndK0StMCwwDNy6oeUS5L9z7aoOxLUVy3nSkIlb8lnggXgdk xiWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=b0gYimu7; 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 q3si22394ejb.395.2021.01.06.18.11.34; Wed, 06 Jan 2021 18:12:05 -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=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=b0gYimu7; 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 S1726681AbhAGCKn (ORCPT + 99 others); Wed, 6 Jan 2021 21:10:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbhAGCKm (ORCPT ); Wed, 6 Jan 2021 21:10:42 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 099C8C0612F0 for ; Wed, 6 Jan 2021 18:10:02 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id cw27so6257538edb.5 for ; Wed, 06 Jan 2021 18:10:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oRYS35mQrlbPBmZbRi04L5UchKku0XQLiBg5o+NaYE4=; b=b0gYimu7iZSKLJTKB+JrcahEkiwt6EX9LvDZjZ91/THGJL0bd07pvRQ13s3H27Vd0l z65nyaHm9nuc0KySpztAxm3keuUPfCF4V0j/mhRd4H8IEZUvaZsPUGP0zLsnZPVM+RAB 3E4nuwfsnWluISWJlamXbK1744ZjbPd69bMq4fcXeAG80M1dVzQiSwydx609mJjxjEk/ PUC27A7G9wgq8MgPoqGUZJoqTQRlLUFW6ZX/CJ47BC/LAHWbZGbh3PYJC22Wh3/z0sWs k6GvQM3KFq9MO+apM7B+VKn9MPrwZNmi1BIBNkkFG4us8Nxsj0644Nlts7PeG68I8Sgw /nSA== 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=oRYS35mQrlbPBmZbRi04L5UchKku0XQLiBg5o+NaYE4=; b=cjjjX21pDa0RPeTcr5Y2E3B1mOBMJZPFgZm/l13V+FzM8n7vc+Lbo9bTYB+ByC9Ptt UapKBsQF/QsEHypJN8/VKZfxHQpltNDROIck7uIgymTFNmdCOCizXqwfzt3TS2hhJTcc GleHtbvoo/v3N1rmcvhnBtLfRYSIP2L8dChreDV8aFyI8LmphbuXUanp/XiTo8PAY6Bz 9p1QX37Pol3DWvdl59Xb8CagWlKX0q+yTjH9wwcb8tHMdZ0hq6jE/aI2gnzLrpNKvnsV /utNF+/ti4nGACOk8P/m//QufSypgrdarZ7HOrBMxfJylqVoZLG4BGCRL1kOKvOm/0dS tR+w== X-Gm-Message-State: AOAM531h1i2SpQ2I300qyyeYUEsHljOv4gihuKgvuBXwN3pXa0OUiC14 A7maKnTfoBPOTJxGpqgGt9bKuwKfA6nRAOFFQe5T X-Received: by 2002:a05:6402:ca1:: with SMTP id cn1mr5956047edb.128.1609985400522; Wed, 06 Jan 2021 18:10:00 -0800 (PST) MIME-Version: 1.0 References: <20201112015359.1103333-1-lokeshgidra@google.com> <20201112015359.1103333-3-lokeshgidra@google.com> In-Reply-To: <20201112015359.1103333-3-lokeshgidra@google.com> From: Paul Moore Date: Wed, 6 Jan 2021 21:09:49 -0500 Message-ID: Subject: Re: [PATCH v13 2/4] fs: add LSM-supporting anon-inode interface To: Lokesh Gidra 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-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, kaleshsingh@google.com, calin@google.com, surenb@google.com, jeffv@google.com, kernel-team@android.com, linux-mm@kvack.org, 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, 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 ...]". > 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? > +{ > + 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