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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 7F574C433DB for ; Thu, 7 Jan 2021 03:08:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 030872158C for ; Thu, 7 Jan 2021 03:08:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 030872158C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=paul-moore.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 60A198D011B; Wed, 6 Jan 2021 22:08:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B79D8D0090; Wed, 6 Jan 2021 22:08:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 457AC8D011B; Wed, 6 Jan 2021 22:08:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 290598D0090 for ; Wed, 6 Jan 2021 22:08:27 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id ECF90180AD811 for ; Thu, 7 Jan 2021 03:08:26 +0000 (UTC) X-FDA: 77677495812.28.bag06_3e113df274e6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id B38BB6C2D for ; Thu, 7 Jan 2021 03:08:26 +0000 (UTC) X-HE-Tag: bag06_3e113df274e6 X-Filterd-Recvd-Size: 7950 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 03:08:26 +0000 (UTC) Received: by mail-ed1-f51.google.com with SMTP id b73so6259787edf.13 for ; Wed, 06 Jan 2021 19:08:26 -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=wszMA77g4rkAzda5NnDRLoVKFBxWJonjIWdOwjgn+kc=; b=FMdvxIT9BIQB3ceg24vI0A6nt9XWJUbDt4ADfKbXNXlIc8+rpsppokAQtPldxOXBhL TqH7HKRBeqZoxftlvBgBck+/wClLVb61JUjXvJ/BnecoBfjhdr3U+ePYKkiV91wVMNt1 FAAxEO9zdwGGYtiMCAiqr4FHhk1T2i7/cxovVBEEjzgSVag5zXO2IJSJ/r2T+CQEyWTW 7HrFaV5n+PBazmh/BRr0byz9nw30qvWCJePz0OG8lx/KoDeoiJic94IN0SegvDQVIkUH KrFKgIvuFBxENpTUzGp8t3BlDn6DRLHfZ8Ym2nOF9uFvnbgheqbrIavAOUo69SZp8ASM la7Q== 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=wszMA77g4rkAzda5NnDRLoVKFBxWJonjIWdOwjgn+kc=; b=edu0MJJ8whKOfbRyRCKNWLcqAd3VXZnYLQKa3EbLF2c/++LOjn2y7RUMxwptSHc3oa 5/m4bEmQdIO5RBDNCKS8WH72Xx9MGn64na3QVv6Eh0X3oHJL2zxem9NDzoQVGDqFYk/n xYUIhZleUhm4PP7GYI0wR8XIL3ZejmUL/Wl+gOeVZEA+TiVTAB9AKwB4EoQBPA4gB03k bAiVkInk28x5gWLI7l0zeawHnclLcT3pPzHhU1qKTP38OQb7oCstQ3etkQyENIbeZjtz cQGpK9ueHMFE8V4qBtEeJcTIit8TVRwAdl422fLfXwKxqOfPBZd6h1v4+0/NqHyN6/FV hujQ== X-Gm-Message-State: AOAM532DXzWiL+8o3KtBR7SbRvR1KqpmLqSVpdCQ1RDg+JydJnkpVb6F kie5wQ1g/9ev3HxThdFldGPrW+zfiRbuYeABb/vN X-Google-Smtp-Source: ABdhPJwbPcMUXvCDqoq1//tWbym4M7BDR4jwDkslBeDZnJaZiKtcepOwWJPg2O/6NWanRIPEd4xbTQWT+K8aluV5/oA= X-Received: by 2002:aa7:c0d6:: with SMTP id j22mr80950edp.31.1609988905108; Wed, 06 Jan 2021 19:08:25 -0800 (PST) MIME-Version: 1.0 References: <20201112015359.1103333-1-lokeshgidra@google.com> <20201112015359.1103333-3-lokeshgidra@google.com> In-Reply-To: From: Paul Moore Date: Wed, 6 Jan 2021 22:08:13 -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 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" 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 Wed, Jan 6, 2021 at 9:44 PM Lokesh Gidra wrote: > 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. Normally that is something I could fix during a merge with your approval, but see my comments to patch 3/4; I think this patchset still needs some work. > > > 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(-) ... > > > +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. My mistake, I didn't realize this until I got further in the patchset. -- paul moore www.paul-moore.com