From: Stephen Smalley <sds@tycho.nsa.gov>
To: Daniel Colascione <dancol@google.com>
Cc: Tim Murray <timmurray@google.com>,
SElinux list <selinux@vger.kernel.org>,
LSM List <linux-security-module@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
kvm@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
paul@paul-moore.com, Nick Kralevich <nnk@google.com>,
Lokesh Gidra <lokeshgidra@google.com>
Subject: Re: [PATCH 2/3] Teach SELinux about anonymous inodes
Date: Fri, 14 Feb 2020 13:02:43 -0500 [thread overview]
Message-ID: <23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov> (raw)
In-Reply-To: <CAKOZuev-=7Lgu35E3tzpHQn0m_KAvvrqi+ZJr1dpqRjHERRSqg@mail.gmail.com>
On 2/14/20 12:21 PM, Daniel Colascione wrote:
> On Fri, Feb 14, 2020 at 8:38 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> That's assuming you are ok with having to define these type_transition
>> rules for the userfaultfd case instead of having your own separate
>> security class. Wondering how many different anon inode names/classes
>> there are in the kernel today and how much they change over time; for a
>> small, relatively stable set, separate classes might be ok; for a large,
>> dynamic set, type transitions should scale better.
>
> I think we can get away without a class per anonymous-inode-type. I do
> wonder whether we need a class for all anonymous inodes, though: if we
> just give them the file class and use the anon inode type name for the
> type_transition rule, isn't it possible that the type_transition rule
> might also fire for plain files with the same names in the last path
> component and the same originating sid? (Maybe I'm not understanding
> type_transition rules properly.) Using a class to encompass all
> anonymous inodes would address this problem (assuming the problem
> exists in the first place).
It shouldn't fire for non-anon inodes because on a (non-anon) file
creation, security_transition_sid() is passed the parent directory SID
as the second argument and we only assign task SIDs to /proc/pid
directories, which don't support (userspace) file creation anyway.
However, in the absence of a matching type_transition rule, we'll end up
defaulting to the task SID on the anon inode, and without a separate
class we won't be able to distinguish it from a /proc/pid inode. So
that might justify a separate anoninode or similar class.
This however reminded me that for the context_inode case, we not only
want to inherit the SID but also the sclass from the context_inode.
That is so that anon inodes created via device node ioctls inherit the
same SID/class pair as the device node and a single allowx rule can
govern all ioctl commands on that device.
next prev parent reply other threads:[~2020-02-14 18:02 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200211225547.235083-1-dancol@google.com>
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 [this message]
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=23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=dancol@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lokeshgidra@google.com \
--cc=nnk@google.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=timmurray@google.com \
--cc=viro@zeniv.linux.org.uk \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).