SELinux Archive on lore.kernel.org
 help / color / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Daniel Colascione <dancol@google.com>
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 13:04:29 -0500
Message-ID: <ae8adb92-9c6e-2318-a3b9-903ead3848b5@tycho.nsa.gov> (raw)
In-Reply-To: <CAKOZuesUVSYJ6EjHFL3QyiWKVmyhm1fLp5Bm_SHjB3_s1gn08A@mail.gmail.com>

On 2/12/20 12:19 PM, Daniel Colascione wrote:
> 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,
>>> +
>>> +     /*
>>> +      * 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).

Not sure why.  You aren't doing anything in the hook that actually 
relies on selinux_state.initialized being set (i.e. nothing requires a 
policy).  The avc_has_perm() call will just succeed until a policy is 
loaded.  So if these inodes are created prior to policy load, they will 
get assigned the task SID (which would be the kernel SID prior to policy 
load or first exec or write to /proc/self/attr/current afterward) and 
UFFD class (in your current code), be permitted, and then once policy is 
loaded any further access will get checked against the kernel SID.

>>> +     /*
>>> +      * 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.

Me either (not my rule) but I'm pretty sure this counts or you'd see a 
lot more of these kinds of BUG_ON() checks throughout.  Try to reserve 
them for really critical cases.

>>> +
>>> +#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?

It is probably the simplest approach; it just doesn't generalize to all 
users of anonymous inodes. We can distinguish them in one of two ways: 
use a different class like you did (requires a code change every time we 
add a new one and yet another duplicate of the file class) or use a 
different SID/context/type. The latter could be achieved by calling 
security_transition_sid() with the provided name wrapped in a qstr and 
specifying type_transition rules on the name.  Then policy could define 
derived types for each domain, ala
type_transition init self:file "[userfaultfd]" init_userfaultfd;
type_transition untrusted_app self:file "[userfaultfd]" 
untrusted_app_userfaultfd;
...

>> 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.

Yes, not sure how the vfs folks feel about either coupling (the 
name-based one or the fops-based one).  Neither seems great.

>> 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.

Hopefully will have a patch available soon.  But not saying this 
necessarily has to wait either.

>>> +     /*
>>> +      * 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?

Yes, that's the approach in our current WIP, except we call it a 
"related" inode since it isn't necessarily connected to the anon inode 
in any vfs sense.

  reply index

Thread overview: 75+ 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
2020-02-12 18:04       ` Stephen Smalley [this message]
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-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-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

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=ae8adb92-9c6e-2318-a3b9-903ead3848b5@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=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=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