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 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 55690C433DB for ; Thu, 7 Jan 2021 03:03:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF803221E9 for ; Thu, 7 Jan 2021 03:03:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF803221E9 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 EEF648D0119; Wed, 6 Jan 2021 22:03:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E77FF8D0090; Wed, 6 Jan 2021 22:03:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D680B8D0119; Wed, 6 Jan 2021 22:03:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id C0F868D0090 for ; Wed, 6 Jan 2021 22:03:54 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8ADAF363D for ; Thu, 7 Jan 2021 03:03:54 +0000 (UTC) X-FDA: 77677484388.10.sun88_2b09881274e6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 639D016A0D1 for ; Thu, 7 Jan 2021 03:03:54 +0000 (UTC) X-HE-Tag: sun88_2b09881274e6 X-Filterd-Recvd-Size: 8664 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 03:03:53 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id d17so7775121ejy.9 for ; Wed, 06 Jan 2021 19:03:53 -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=6kwvfWjFnH4Pc0zsg+cAo49RaImmwcqEmlwY0Dyffcs=; b=M11mc+jiW0OYQkc9/dR28NTijrEoOw94j/VOx8Dg07F4MK1+HH6XznVqn9brS7Tmwn VZm/q6ON2mOW031Dx5roB5u0XEecDdQ2Alw/urDCe2ZqbsJoKEAJb/XOsX2cjhJpn+tj 6Cvc74oeTvrjgZ0SBGJvMJOShhHnp01lTaSKxIqJpaSXGUMp2xFnBIBh4ZBvL9VOlQFc AL5v3K9JuY4NKBbhAko+8UuCxMJHDBldsqPzgGwiJfGWhVmHo5EvIvvosgAvJtBJz2Rz g8RoSYbnLb5SG2lykH7nZ+qGq6TexpA5lxLk+RXeQMoSbpNbYGkh1dufOfQRPUy1NpQ2 zitw== 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=6kwvfWjFnH4Pc0zsg+cAo49RaImmwcqEmlwY0Dyffcs=; b=gTOEzBi5Wazo3c/TRrPtKyXHPSXayItp+Nu+5HbAK2eUSZVrpbcANwax51mi9hBU/R Hh0Oms8Kbs4ik10DP8HF0zlYVeZmwzGsVgbJrFlbM0RWdeM/BWIqWC81OncZDcj/vkcR yj1OoV996UOHpbtYTBQF4UG3PmEYcAIR/lniE4Fcw3+/MWPfl4bVViO2GEuwaUeiNAXq 4uX37p0DNT2PYbNbHe7UHHX4pNcDPozIiydoxpmkgsVteNPbCQYv/lI17u2dswHVDfBx sEp5HNZgON05OEGh+bEF9aonzK0H4fkadbjq+rK6RWhAQ8jS5gK1f3U1jo59olBgMv1M p9jA== X-Gm-Message-State: AOAM532wvwLKQIPtLU5zUkQ8SFfvO+3YB6tF+UdRYQnuzaz9z0vChRXu rqLKYHO42/VQR2NZls3gI8+q5+vt3JtXAAOecM56 X-Google-Smtp-Source: ABdhPJxIp98KdT+UjIT3+fzknjc5WNT9ayzrPwNK/r34lZvPzfuCHqHbVQNUYHSOPAYOY3LHLdNuze3frO0LGlwZTbk= X-Received: by 2002:a17:906:aec6:: with SMTP id me6mr4825292ejb.542.1609988632573; Wed, 06 Jan 2021 19:03:52 -0800 (PST) MIME-Version: 1.0 References: <20201112015359.1103333-1-lokeshgidra@google.com> <20201112015359.1103333-4-lokeshgidra@google.com> In-Reply-To: <20201112015359.1103333-4-lokeshgidra@google.com> From: Paul Moore Date: Wed, 6 Jan 2021 22:03:41 -0500 Message-ID: Subject: Re: [PATCH v13 3/4] selinux: teach SELinux about anonymous inodes 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 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, 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? > + isec->sid = context_isec->sid; > + } else { > + isec->sclass = SECCLASS_ANON_INODE; > + rc = security_transition_sid( > + &selinux_state, tsec->sid, tsec->sid, > + isec->sclass, name, &isec->sid); > + if (rc) > + return rc; > + } > + > + isec->initialized = LABEL_INITIALIZED; > + > + /* > + * Now that we've initialized security, check whether we're > + * allowed to actually create this type of anonymous inode. > + */ > + > + ad.type = LSM_AUDIT_DATA_INODE; > + ad.u.inode = inode; > + > + return avc_has_perm(&selinux_state, > + tsec->sid, > + isec->sid, > + isec->sclass, > + ANON_INODE__CREATE, > + &ad); > +} -- paul moore www.paul-moore.com