From: Daniel Colascione <dancol@google.com> To: Stephen Smalley <sds@tycho.nsa.gov> Cc: Tim Murray <timmurray@google.com>, Nosh Minwalla <nosh@google.com>, Nick Kralevich <nnk@google.com>, Lokesh Gidra <lokeshgidra@google.com>, linux-kernel <linux-kernel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, selinux@vger.kernel.org Subject: Re: [PATCH v2 3/6] Teach SELinux about a new userfaultfd class Date: Wed, 12 Feb 2020 09:19:16 -0800 Message-ID: <CAKOZuesUVSYJ6EjHFL3QyiWKVmyhm1fLp5Bm_SHjB3_s1gn08A@mail.gmail.com> (raw) In-Reply-To: <ef13d728-9f1e-5e38-28a1-7ed7134840e4@tycho.nsa.gov> Thanks for taking a look. On Wed, Feb 12, 2020 at 9:04 AM Stephen Smalley <sds@tycho.nsa.gov> wrote: > > On 2/11/20 5:55 PM, Daniel Colascione wrote: > > Use the secure anonymous inode LSM hook we just added to let SELinux > > policy place restrictions on userfaultfd use. The create operation > > applies to processes creating new instances of these file objects; > > transfer between processes is covered by restrictions on read, write, > > and ioctl access already checked inside selinux_file_receive. > > > > Signed-off-by: Daniel Colascione <dancol@google.com> > > (please add linux-fsdevel and viro to the cc for future versions of this > patch since it changes the VFS) > > > --- > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > > index 1659b59fb5d7..e178f6f40e93 100644 > > --- a/security/selinux/hooks.c > > +++ b/security/selinux/hooks.c > > @@ -2915,6 +2919,69 @@ 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 char *name, > > + const struct file_operations *fops) > > +{ > > + const struct task_security_struct *tsec = selinux_cred(current_cred()); > > + struct common_audit_data ad; > > + struct inode_security_struct *isec; > > + > > + if (unlikely(IS_PRIVATE(inode))) > > + return 0; > > Seems like this is precluded by the caller and would be a bug? If > needed at all, take it to the security_inode_init_security_anon() so it > doesn't have to be repeated in each security module. > > > + > > + /* > > + * We shouldn't be creating secure anonymous inodes before LSM > > + * initialization completes. > > + */ > > + if (unlikely(!selinux_state.initialized)) > > + return -EBUSY; > > I don't think this is viable; any arbitrary actions are possible before > policy is loaded, and a Linux distro can be brought up fully with > SELinux enabled and no policy loaded. You'll just need to have a > default behavior prior to initialization. We'd have to fail open then, I think, and return an S_PRIVATE inode (the regular anon inode). > > + > > + 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, so check that the state is as > > + * inode_alloc_security left it. > > + */ > > + BUG_ON(isec->initialized != LABEL_INVALID); > > + BUG_ON(isec->sclass != SECCLASS_FILE); > > I think the kernel discourages overuse of BUG_ON/BUG/... I'm not sure what counts as overuse. > > + > > +#ifdef CONFIG_USERFAULTFD > > + if (fops == &userfaultfd_fops) > > + isec->sclass = SECCLASS_UFFD; > > +#endif > > Not sure we want or need to introduce a new security class for each user > of anonymous inodes since the permissions should be the same as for > file. The purpose of this change is to apply special policy to userfaultfd FDs in particular. Isn't having a UFFD security class the best way to go about that? (There's no path.) Am I missing something? > Also not sure we want to be testing fops for each such case. I was also thinking of just providing some kind of context string (maybe the name), which might be friendlier to modules, but the loose coupling kind of scares me, and for this particular application, since UFFD is always in the core and never in a module, checking the fops seems a bit more robust and doesn't hurt anything. > We > were looking at possibly leveraging the name as a key and using > security_transition_sid() to generate a distinct SID/context/type for > the inode via type_transition rules in policy. We have some WIP along > those lines. Where? Any chance it would be ready soon? I'd rather not hold up this work for a more general mechanism. > > + > > + if (isec->sclass == SECCLASS_FILE) { > > + printk(KERN_WARNING "refusing to create secure anonymous inode " > > + "of unknown type"); > > + return -EOPNOTSUPP; > > + } > > + /* > > + * Always give secure anonymous inodes the sid of the > > + * creating task. > > + */ > > + > > + isec->sid = tsec->sid; > > This doesn't generalize for other users of anonymous inodes, e.g. the > /dev/kvm case where we'd rather inherit the SID and class from the > original /dev/kvm inode itself. I think someone mentioned on the first version of this patch that we could make it more flexible if the need arose. If we do want to do it now, we could have the anon_inode security hook accept a "parent" or "context" inode that modules could inspect for the purposes of forming the new inode's SID. Does that make sense to you?
next prev parent reply index Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-11 22:55 [PATCH v2 0/6] Harden userfaultfd Daniel Colascione 2020-02-11 22:55 ` [PATCH v2 1/6] Add a new flags-accepting interface for anonymous inodes Daniel Colascione 2020-02-12 16:37 ` Stephen Smalley 2020-02-12 17:23 ` Daniel Colascione 2020-02-11 22:55 ` [PATCH v2 2/6] Add a concept of a "secure" anonymous file Daniel Colascione 2020-02-12 16:49 ` Stephen Smalley 2020-02-14 22:13 ` kbuild test robot 2020-02-11 22:55 ` [PATCH v2 3/6] Teach SELinux about a new userfaultfd class Daniel Colascione 2020-02-12 17:05 ` Stephen Smalley 2020-02-12 17:19 ` Daniel Colascione [this message] 2020-02-12 18:04 ` Stephen Smalley 2020-02-12 18:59 ` Stephen Smalley 2020-02-12 19:04 ` Daniel Colascione 2020-02-12 19:11 ` Stephen Smalley 2020-02-12 19:13 ` Daniel Colascione 2020-02-12 19:17 ` Stephen Smalley 2020-02-11 22:55 ` [PATCH v2 4/6] Wire UFFD up to SELinux Daniel Colascione 2020-02-11 22:55 ` [PATCH v2 5/6] Let userfaultfd opt out of handling kernel-mode faults Daniel Colascione 2020-02-11 22:55 ` [PATCH v2 6/6] Add a new sysctl for limiting userfaultfd to user mode faults Daniel Colascione 2020-02-11 23:13 ` [PATCH v2 0/6] Harden userfaultfd Casey Schaufler 2020-02-11 23:27 ` Daniel Colascione 2020-02-12 16:09 ` Stephen Smalley 2020-02-21 17:56 ` James Morris 2020-02-12 7:50 ` Kees Cook 2020-02-12 16:54 ` Jann Horn 2020-02-12 17:14 ` Peter Xu 2020-02-12 19:41 ` Andrea Arcangeli 2020-02-12 20:04 ` Daniel Colascione 2020-02-12 23:41 ` Andrea Arcangeli 2020-02-12 17:12 ` Daniel Colascione 2020-02-14 3:26 ` [PATCH 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-02-14 3:26 ` [PATCH 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-02-14 3:26 ` [PATCH 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-02-14 16:39 ` Stephen Smalley 2020-02-14 17:21 ` Daniel Colascione 2020-02-14 18:02 ` Stephen Smalley 2020-02-14 18:08 ` Stephen Smalley 2020-02-14 20:24 ` Stephen Smalley 2020-02-14 3:26 ` [PATCH 3/3] Wire UFFD up to SELinux Daniel Colascione 2020-03-25 23:02 ` [PATCH v2 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-03-25 23:02 ` [PATCH v2 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-03-26 13:53 ` Stephen Smalley 2020-03-25 23:02 ` [PATCH v2 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-03-26 13:58 ` Stephen Smalley 2020-03-26 17:59 ` Daniel Colascione 2020-03-26 17:37 ` Stephen Smalley 2020-03-25 23:02 ` [PATCH v2 3/3] Wire UFFD up to SELinux Daniel Colascione 2020-03-25 23:49 ` Casey Schaufler 2020-03-26 18:14 ` [PATCH v3 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-03-26 18:14 ` [PATCH v3 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-03-26 19:00 ` Stephen Smalley 2020-03-26 18:14 ` [PATCH v3 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-03-26 19:02 ` Stephen Smalley 2020-03-26 18:14 ` [PATCH v3 3/3] Wire UFFD up to SELinux Daniel Colascione 2020-03-26 20:06 ` [PATCH v4 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-03-26 20:06 ` [PATCH v4 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-03-27 13:40 ` Stephen Smalley 2020-03-26 20:06 ` [PATCH v4 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-03-27 13:41 ` Stephen Smalley 2020-03-26 20:06 ` [PATCH v4 3/3] Wire UFFD up to SELinux Daniel Colascione 2020-04-01 21:39 ` [PATCH v5 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-04-01 21:39 ` [PATCH v5 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione 2020-05-07 16:02 ` James Morris 2020-08-04 21:22 ` Eric Biggers 2020-04-01 21:39 ` [PATCH v5 2/3] Teach SELinux about anonymous inodes Daniel Colascione 2020-04-01 21:39 ` [PATCH v5 3/3] Wire UFFD up to SELinux Daniel Colascione 2020-08-04 21:16 ` Eric Biggers 2020-04-13 13:29 ` [PATCH v5 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione 2020-04-22 16:55 ` James Morris 2020-04-22 17:12 ` Casey Schaufler 2020-04-23 22:24 ` Casey Schaufler 2020-04-27 16:18 ` Casey Schaufler 2020-04-27 16:48 ` Stephen Smalley 2020-04-27 17:12 ` Casey Schaufler 2020-04-29 17:02 ` Stephen Smalley 2020-04-27 17:15 ` Casey Schaufler 2020-04-27 19:40 ` Stephen Smalley 2020-06-04 3:56 ` James Morris 2020-06-04 18:51 ` Stephen Smalley 2020-06-04 19:24 ` Lokesh Gidra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAKOZuesUVSYJ6EjHFL3QyiWKVmyhm1fLp5Bm_SHjB3_s1gn08A@mail.gmail.com \ --to=dancol@google.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lokeshgidra@google.com \ --cc=nnk@google.com \ --cc=nosh@google.com \ --cc=sds@tycho.nsa.gov \ --cc=selinux@vger.kernel.org \ --cc=timmurray@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
SELinux Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \ selinux@vger.kernel.org public-inbox-index selinux Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.selinux AGPL code for this site: git clone https://public-inbox.org/public-inbox.git