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=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 B4A4AC433E0 for ; Fri, 8 Jan 2021 19:35:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2CBCE23AA3 for ; Fri, 8 Jan 2021 19:35:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2CBCE23AA3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F6A78D01A3; Fri, 8 Jan 2021 14:35:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A5098D0156; Fri, 8 Jan 2021 14:35:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46DED8D01A3; Fri, 8 Jan 2021 14:35:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0115.hostedemail.com [216.40.44.115]) by kanga.kvack.org (Postfix) with ESMTP id 2A3AA8D0156 for ; Fri, 8 Jan 2021 14:35:57 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id E29AC364F for ; Fri, 8 Jan 2021 19:35:56 +0000 (UTC) X-FDA: 77683613112.01.part75_1c10d27274f5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id A1EBB100520EA for ; Fri, 8 Jan 2021 19:35:45 +0000 (UTC) X-HE-Tag: part75_1c10d27274f5 X-Filterd-Recvd-Size: 9190 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Jan 2021 19:35:45 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id h205so25619096lfd.5 for ; Fri, 08 Jan 2021 11:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3WxPunzObO7VBBO08P095znmCTwpPws3qFKujB/DeTY=; b=QH3kOVU7aUnQVLBDSE8jtmzLrRomllVB694UQ/nV/I42Dq+Crwrb7qazkPROG4ni+K CG0cvfn/5pVGUA/naferSia8hrt82nhsgR72saQ3sWVNzskbIHrJh5haTHdONdbmjS7B XqdOVWM+o6gzD1B8gRxrrUaFO7eauxky4rQE4U5VaM4dVo0DS8X1BhAszVGrxpbAPYjd EfmY549yM6uKr+LQKOG+q4OYu8tLB2YsbDv0NoxeE9FytJOrRSVmzKWiB2GU3FFP6GAY erG4XYFOd9Tqd+WjDuYQpZQjVplkMF7T+L/IcCPi/+ZZbEb+o2tO+CHh2lgfPNnpftUd EDAQ== 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=3WxPunzObO7VBBO08P095znmCTwpPws3qFKujB/DeTY=; b=UkTgvujKHo7+HMJlD/PmDju1eNCtdbW7VfQHaPeTdITrglcLkts+4SU1QR0gBoR6w5 HyuT4KcwPLwuHg9QjVx/R6qOprhMAp7ex9EvRMw2jbnTN7oVNUuPUO+EMmNtZ764P5L9 ZNlsBkHNEpHS5wwfaXzqsVqFGwyhJOaFW0mCI7uVhsP2Wrjtm0KGyw0u+GnN9Lfg70Hx o6WesinBkGjC9p9fKBPnYuWej7IRuO9wzNfjhtHKfiU2tmf4qDWM4RmnxuKgSMi6VgyH H1SlrgTt+A1F7YTXwg6pf7JGzY1+jtvE01B+lBN40Ju2N5NH+BZfvGIFVrH7X23pTEdI mM2w== X-Gm-Message-State: AOAM533Ea33VSv1tQwglNEE8BbsZION96iPmyJ7IeAlWRdQ56KG5WPQU dBu3Pgz0Ke2RiRUbO0eK6gEVY1BRnh+t+gPp77A= X-Google-Smtp-Source: ABdhPJzxD5CloN42QduDGf0YSiNOZ34DQjuAmMuXasAf2DGf5AZYqpLTLcFTkfGXtKpUES/9E+ntTXJrXzs1KjxjxjY= X-Received: by 2002:ac2:548b:: with SMTP id t11mr2380189lfk.181.1610134543697; Fri, 08 Jan 2021 11:35:43 -0800 (PST) MIME-Version: 1.0 References: <20201112015359.1103333-1-lokeshgidra@google.com> <20201112015359.1103333-4-lokeshgidra@google.com> In-Reply-To: From: Stephen Smalley Date: Fri, 8 Jan 2021 14:35:32 -0500 Message-ID: Subject: Re: [PATCH v13 3/4] selinux: teach SELinux about anonymous inodes To: Paul Moore Cc: Lokesh Gidra , Andrea Arcangeli , Alexander Viro , James Morris , 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 , kaleshsingh@google.com, Calin Juravle , Suren Baghdasaryan , Jeffrey Vander Stoep , kernel-team@android.com, linux-mm@kvack.org, Andrew Morton , Christoph Hellwig , Daniel Colascione 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 10:03 PM Paul Moore wrote: > > On Wed, Nov 11, 2020 at 8:54 PM Lokesh Gidra wrote: > > From: Daniel Colascione > > > > This change uses the anon_inodes and LSM infrastructure introduced in > > the previous patches to give SELinux the ability to control > > anonymous-inode files that are created using the new > > anon_inode_getfd_secure() function. > > > > A SELinux policy author detects and controls these anonymous inodes by > > adding a name-based type_transition rule that assigns a new security > > type to anonymous-inode files created in some domain. The name used > > for the name-based transition is the name associated with the > > anonymous inode for file listings --- e.g., "[userfaultfd]" or > > "[perf_event]". > > > > Example: > > > > type uffd_t; > > type_transition sysadm_t sysadm_t : anon_inode uffd_t "[userfaultfd]"; > > allow sysadm_t uffd_t:anon_inode { create }; > > > > (The next patch in this series is necessary for making userfaultfd > > support this new interface. The example above is just > > for exposition.) > > > > Signed-off-by: Daniel Colascione > > Signed-off-by: Lokesh Gidra > > --- > > security/selinux/hooks.c | 56 +++++++++++++++++++++++++++++ > > security/selinux/include/classmap.h | 2 ++ > > 2 files changed, 58 insertions(+) > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > index 6b1826fc3658..d092aa512868 100644 > > --- a/security/selinux/hooks.c > > +++ b/security/selinux/hooks.c > > @@ -2927,6 +2927,61 @@ static int selinux_inode_init_security(struct inode *inode, struct inode *dir, > > return 0; > > } > > > > +static int selinux_inode_init_security_anon(struct inode *inode, > > + const struct qstr *name, > > + const struct inode *context_inode) > > +{ > > + const struct task_security_struct *tsec = selinux_cred(current_cred()); > > + struct common_audit_data ad; > > + struct inode_security_struct *isec; > > + int rc; > > + > > + if (unlikely(!selinux_initialized(&selinux_state))) > > + return 0; > > + > > + isec = selinux_inode(inode); > > + > > + /* > > + * We only get here once per ephemeral inode. The inode has > > + * been initialized via inode_alloc_security but is otherwise > > + * untouched. > > + */ > > + > > + if (context_inode) { > > + struct inode_security_struct *context_isec = > > + selinux_inode(context_inode); > > + if (context_isec->initialized != LABEL_INITIALIZED) > > + return -EACCES; > > + > > + isec->sclass = context_isec->sclass; > > Taking the object class directly from the context_inode is > interesting, and I suspect problematic. In the case below where no > context_inode is supplied the object class is set to > SECCLASS_ANON_INODE, which is correct, but when a context_inode is > supplied there is no guarantee that the object class will be set to > SECCLASS_ANON_INODE. This could both pose a problem for policy > writers (how do you distinguish the anon inode from other normal file > inodes in this case?) as well as an outright fault later in this > function when we try to check the ANON_INODE__CREATE on an object > other than a SECCLASS_ANON_INODE object. > > It works in the userfaultfd case because the context_inode is > originally created with this function so the object class is correctly > set to SECCLASS_ANON_INODE, but can we always guarantee that to be the > case? Do we ever need or want to support using a context_inode that > is not SECCLASS_ANON_INODE? Sorry, I haven't been following this. IIRC, the original reason for passing a context_inode was to support the /dev/kvm or similar use cases where the driver is creating anonymous inodes to represent specific objects/interfaces derived from the device node and we want to be able to control subsequent ioctl operations on those anonymous inodes in the same manner as for the device node. For example, ioctl operations on /dev/kvm can end up returning file descriptors for anonymous inodes representing a specific VM or VCPU or similar. If we propagate the security class and SID from the /dev/kvm inode (the context inode) to the new anonymous inode, we can write a single policy rule over all ioctl operations related to /dev/kvm. That's also why we used the FILE__CREATE permission here originally; that was also intentional. All the file-related classes including anon_inode inherit a common set of file permissions including create and thus we often use the FILE__ in common code when checking permission against any potentially derived class.