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=-14.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_IN_DEF_DKIM_WL autolearn=unavailable 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 8C64FC2D0E5 for ; Thu, 26 Mar 2020 18:00:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 664DD20714 for ; Thu, 26 Mar 2020 18:00:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="etIa99nr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727889AbgCZSAY (ORCPT ); Thu, 26 Mar 2020 14:00:24 -0400 Received: from mail-lf1-f67.google.com ([209.85.167.67]:38220 "EHLO mail-lf1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbgCZSAX (ORCPT ); Thu, 26 Mar 2020 14:00:23 -0400 Received: by mail-lf1-f67.google.com with SMTP id c5so5664783lfp.5 for ; Thu, 26 Mar 2020 11:00:22 -0700 (PDT) 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=rceHKfjao+uDGRra9UF3uhK0a0AeUDhxMcu5Qcf+otU=; b=etIa99nr6bm25NrBlkHQnJRTiwL1U3f2GGcUc2zPfdQZuyHnxg0asGUYsNXKwcuPxr LDSdnr68HVigzzCnfUiC2OaPSQS1RTGiSXpK977g9GagrBMdVytSjK30lD1rYgsogG0w REyIwh4CbLCtz+u+EsDZ1KJNDIaTXi5elhRnnuAcuiiBkzK8ixk2nS7o38LjrK/u8gc+ q0tzYOVf1cY2LIkvba0iMsaj3q18RiwjqVt4hvl1FC2IdZEB/uAw4dPpkK74Z9egxT/l H/cOEa1BkQMIlbvofPof5CiupQXjZVOJIRBCsShsouMd079XhFFq90Pyovj8lyRA8H7Y 4QqA== 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=rceHKfjao+uDGRra9UF3uhK0a0AeUDhxMcu5Qcf+otU=; b=bX35QopSSTGjRC9djZNpqKvs4mP1AhHKQUM2OSzlxriadFJOBNb1uvh7sKuJ/vmEQ5 K1I+JHUD5H/r/6JDOPx412SFLSJBMi2RA1xl8gIfpZI0c4VpT34pp25aRLVoXJD7d4ZZ FDJnsKIiQ3qbDCtBlkO+RRuo8SgBhLEwkYx02LhoGk8//cG4f7ZFdhaCr4vWokCdKNyS S5XdQEEJzsJ8ZNHshJsQoHC/JP/kyLPARt/JXRd5squwFiXxSwrKiA2OGQ6PmmOa2pCI /ZIloZuSNfaf+JD7zK6j9pdYVgbvIDGAW3xipjeaY+EHpq9IGW4DYbTDZfeFosQ7AyFb B/5Q== X-Gm-Message-State: ANhLgQ3GGg1igbtO1R5ck37IFQusGYEZpHV7flgY91keRNDo+3tepT5b +MfJ4ZGB74q7QqJw6ucO02pwGp2BnJvAaU5AysoADQ== X-Google-Smtp-Source: ADFU+vtNiW6JWvS32/vnFzBQwNxILQURl2WF5g4cDVQE/3AuIvJTayB02deDSwzX0n3ZE86pi6UbGe7fvkOGgd8pNqM= X-Received: by 2002:a05:6512:31d3:: with SMTP id j19mr6562434lfe.178.1585245620066; Thu, 26 Mar 2020 11:00:20 -0700 (PDT) MIME-Version: 1.0 References: <20200214032635.75434-1-dancol@google.com> <20200325230245.184786-3-dancol@google.com> In-Reply-To: From: Daniel Colascione Date: Thu, 26 Mar 2020 10:59:41 -0700 Message-ID: Subject: Re: [PATCH v2 2/3] Teach SELinux about anonymous inodes To: Stephen Smalley Cc: Tim Murray , SElinux list , LSM List , Linux FS Devel , linux-kernel , kvm@vger.kernel.org, Al Viro , Paul Moore , Nick Kralevich , Lokesh Gidra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for taking a look! On Thu, Mar 26, 2020 at 6:57 AM Stephen Smalley wrote: > > On 3/25/20 7:02 PM, Daniel Colascione wrote: > > This change uses the anon_inodes and LSM infrastructure introduced in > > the previous patch to give SELinux the ability to control > > anonymous-inode files that are created using the new _secure() > > anon_inodes functions. > > > > 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 : file uffd_t "[userfaultfd]"; > > allow sysadm_t uffd_t:file { create }; Oops. Will fix. > > (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 > > --- > > security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++ > > security/selinux/include/classmap.h | 2 ++ > > 2 files changed, 56 insertions(+) > > > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > index 1659b59fb5d7..b9eb45c2e4e5 100644 > > --- a/security/selinux/hooks.c > > +++ b/security/selinux/hooks.c > > @@ -2915,6 +2915,59 @@ 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 file_operations *fops, > > + 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_state.initialized)) > > + return 0; > > This leaves secure anon inodes created before first policy load with the > unlabeled SID rather than defaulting to the SID of the creating task > (kernel SID in that situation). Is that what you want? Alternatively > you can just remove this test and let it proceed; nothing should be > break and the anon inodes will get the kernel SID. We talked about this decision on the last thread [1], and I think you mentioned that either the unlabeled or the kernel SID approach would be defensible. Using the unlabeled SID seems more "honest" to me than using the kernel SID: the unlabeled SID says "we don't know", while using kernel SID would be making an affirmative claim that the anonymous inode belongs to the kernel, and claim wouldn't be true. That's why I'm leaning toward the unlabeled approach right now. [1] https://lore.kernel.org/lkml/9ca03838-8686-0007-0971-ee63bf5031da@tycho.nsa.gov/