From: Daniel Colascione <hidden> Date: 2020-02-14 03:27:22
Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor. SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
Inside the kernel, a pair of new anon_inodes interface,
anon_inode_getfile_secure and anon_inode_getfd_secure, allow callers
to opt into this SELinux management. In this new "secure" mode,
anon_inodes creates new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.
This patch series is one of two fork of [1] and is an
alternative to [2].
The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.
I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.
The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].
This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.
[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
[2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 196 ++++++++++++++++++++++++++++--------
fs/userfaultfd.c | 34 +++++--
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
security/selinux/hooks.c | 57 +++++++++++
7 files changed, 274 insertions(+), 49 deletions(-)
--
2.25.0.265.gbab2e86ba0-goog
From: Daniel Colascione <hidden> Date: 2020-02-14 03:27:05
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 196 ++++++++++++++++++++++++++++--------
fs/userfaultfd.c | 4 +-
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
6 files changed, 191 insertions(+), 45 deletions(-)
From: Daniel Colascione <hidden> Date: 2020-02-14 03:27:06
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 };
(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 <redacted>
---
security/selinux/hooks.c | 57 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
This is not possible since the caller clears S_PRIVATE before calling
and it would be a bug to call the hook on an inode that was intended to
be private, so we shouldn't check it here.
+
+ if (unlikely(!selinux_state.initialized))
+ return 0;
Are we doing this to defer initialization until selinux_complete_init()
- that's normally why we bail in the !initialized case? Not entirely
sure what will happen in such a situation since we won't have the
context_inode or the allocating task information at that time, so we
certainly won't get the same result - probably they would all be labeled
with whatever anon_inodefs is assigned via genfscon or
SECINITSID_UNLABELED by default. If we instead just drop this test and
proceed, we'll inherit the context inode SID if specified or we'll call
security_transition_sid(), which in the !initialized case will just
return the tsid i.e. tsec->sid, so it will be labeled with the creating
task SID (SECINITSID_KERNEL prior to initialization). Then the
avc_has_perm() call will pass because everything gets allowed until
initialization. So you could drop this check and userfaultfds created
before policy load would get the kernel SID, or you can keep it and they
will get the unlabeled SID. Preference?
+
+ 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 (IS_ERR(context_isec))
+ return PTR_ERR(context_isec);
This isn't possible AFAICT so you don't need to test for it or handle
it. In fact, even the test for NULL in selinux_inode() is bogus and
should get dropped AFAICT; we always allocate an inode security blob
even before policy load so it would be a bug if we ever had a NULL there.
Since you switched to using security_transition_sid(), you are not using
the fops parameter anymore nor comparing with userfaultfd_fops, so you
could drop the parameter from the hook and leave the latter static in
the first patch.
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. We might still need
to create a mapping table in SELinux from the names to some stable
identifier for the policy lookup if we can't rely on the names being stable.
This is not possible since the caller clears S_PRIVATE before calling
and it would be a bug to call the hook on an inode that was intended to
be private, so we shouldn't check it here.
quoted
+
+ if (unlikely(!selinux_state.initialized))
+ return 0;
Are we doing this to defer initialization until selinux_complete_init()
- that's normally why we bail in the !initialized case? Not entirely
sure what will happen in such a situation since we won't have the
context_inode or the allocating task information at that time, so we
certainly won't get the same result - probably they would all be labeled
with whatever anon_inodefs is assigned via genfscon or
SECINITSID_UNLABELED by default.
If we instead just drop this test and
proceed, we'll inherit the context inode SID if specified or we'll call
security_transition_sid(), which in the !initialized case will just
return the tsid i.e. tsec->sid, so it will be labeled with the creating
task SID (SECINITSID_KERNEL prior to initialization). Then the
avc_has_perm() call will pass because everything gets allowed until
initialization. So you could drop this check and userfaultfds created
before policy load would get the kernel SID, or you can keep it and they
will get the unlabeled SID. Preference?
The kernel SID seems safer. Thanks for the explanation!
quoted
+
+ 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 (IS_ERR(context_isec))
+ return PTR_ERR(context_isec);
This isn't possible AFAICT so you don't need to test for it or handle
it. In fact, even the test for NULL in selinux_inode() is bogus and
should get dropped AFAICT; we always allocate an inode security blob
even before policy load so it would be a bug if we ever had a NULL there.
Since you switched to using security_transition_sid(), you are not using
the fops parameter anymore nor comparing with userfaultfd_fops, so you
could drop the parameter from the hook and leave the latter static in
the first patch.
That's true, but I figured different LSMs might want different rules
that depend on the fops. I'm also okay with removing this parameter
for now, since we're not using it.
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).
We might still need
to create a mapping table in SELinux from the names to some stable
identifier for the policy lookup if we can't rely on the names being stable.
Sure. The anonymous inode type names have historically been stable,
though, so maybe we can just use the names from anon_inodes directly
for now and then add some kind of remapping if we want to change those
names in the core, remaping to the old name for SELinux
type_transition purposes.
From: Stephen Smalley <hidden> Date: 2020-02-14 18:02:08
On 2/14/20 12:21 PM, Daniel Colascione wrote:
On Fri, Feb 14, 2020 at 8:38 AM Stephen Smalley [off-list ref] wrote:
quoted
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.
From: Stephen Smalley <hidden> Date: 2020-02-14 18:07:46
On 2/14/20 1:02 PM, Stephen Smalley wrote:
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.
At least that's the way our patch worked with the /dev/kvm example.
However, if we are introducing a separate anoninode class for the
type_transition case, maybe we should apply that to all anon inodes
regardless of how they are labeled (based on context_inode or
transition) and then we'd need to write two allowx rules, one for ioctls
on the original device node and one for those on anon inodes created
from it. Not sure how Android wants to handle that as the original
developer and primary user of SELinux ioctl whitelisting.
From: Stephen Smalley <hidden> Date: 2020-02-14 20:23:41
On 2/14/20 1:08 PM, Stephen Smalley wrote:
On 2/14/20 1:02 PM, Stephen Smalley wrote:
quoted
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.
At least that's the way our patch worked with the /dev/kvm example.
However, if we are introducing a separate anoninode class for the
type_transition case, maybe we should apply that to all anon inodes
regardless of how they are labeled (based on context_inode or
transition) and then we'd need to write two allowx rules, one for ioctls
on the original device node and one for those on anon inodes created
from it. Not sure how Android wants to handle that as the original
developer and primary user of SELinux ioctl whitelisting.
I would tentatively argue for inheriting both sclass and SID from the
context_inode for the sake of sane policy writing. In the userfaultfd
case, that will still end up using the new SECCLASS_ANONINODE or
whatever since the sclass will be initially set to that value for the
transition SID case and then inherited on fork. But for /dev/kvm, it
would be the class from the /dev/kvm inode, i.e. SECCLASS_CHR_FILE.
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1020,8 +1022,10 @@ static int resolve_userfault_fork(struct userfaultfd_ctx *ctx,{intfd;-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,new,-O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS));+fd=anon_inode_getfd_secure(+"[userfaultfd]",&userfaultfd_fops,new,+O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS),+ctx->owner);if(fd<0)returnfd;
@@ -1972,8 +1977,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
From: Daniel Colascione <hidden> Date: 2020-03-25 23:03:03
Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor. SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
Inside the kernel, a pair of new anon_inodes interface,
anon_inode_getfile_secure and anon_inode_getfd_secure, allow callers
to opt into this SELinux management. In this new "secure" mode,
anon_inodes creates new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.
This patch series is one of two fork of [1] and is an
alternative to [2].
The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.
I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.
The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].
This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.
Changes from the first version of the patch:
- Removed some error checks
- Defined a new anon_inode SELinux class to resolve the
ambiguity in [3]
- Inherit sclass as well as descriptor from context inode
[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
[2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/
[3] https://lore.kernel.org/lkml/23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov/
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 196 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
security/selinux/hooks.c | 54 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 272 insertions(+), 46 deletions(-)
--
2.25.1.696.g5e7596f4ac-goog
From: Daniel Colascione <hidden> Date: 2020-03-25 23:03:34
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 196 ++++++++++++++++++++++++++++--------
fs/userfaultfd.c | 4 +-
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
6 files changed, 191 insertions(+), 45 deletions(-)
From: Stephen Smalley <hidden> Date: 2020-03-26 14:01:54
On 3/25/20 7:02 PM, Daniel Colascione wrote:
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
From: Daniel Colascione <hidden> Date: 2020-03-25 23:03:55
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 };
(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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
From: Stephen Smalley <hidden> Date: 2020-03-26 14:04:01
On 3/25/20 7:02 PM, Daniel Colascione wrote:
quoted hunk
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 };
(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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
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.
quoted hunk
+
+ 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);
+ isec->sclass = context_isec->sclass;
+ isec->sid = context_isec->sid;
+ } else {
+ isec->sclass = SECCLASS_ANON_INODE;
+ rc = security_transition_sid(
+ &selinux_state, tsec->sid, tsec->sid,
+ SECCLASS_FILE, 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,
+ FILE__CREATE,
+ &ad);
+}
+
static int selinux_inode_create(struct inode *dir, struct dentry *dentry, umode_t mode)
{
return may_create(dir, dentry, SECCLASS_FILE);
From: Daniel Colascione <hidden> Date: 2020-03-26 18:00:28
Thanks for taking a look!
On Thu, Mar 26, 2020 at 6:57 AM Stephen Smalley [off-list ref] wrote:
On 3/25/20 7:02 PM, Daniel Colascione wrote:
quoted
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.
quoted
(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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
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/
From: Stephen Smalley <hidden> Date: 2020-03-26 17:37:37
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 };
These should use :anon_inode rather than :file since the class is no
longer file.
quoted hunk
(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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1972,8 +1979,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
This change gives userfaultfd file descriptors a real security
context, allowing policy to act on them.
You should change the title to "Wire UFFD up to secure anon inodes".
This code should support any LSM that wants to control anon inodes.
If it doesn't, it isn't correct.
All references to SELinux behavior (i.e. assigning a "security context")
should be restricted to the SELinux specific bits of the patch set. You
should be describing how any LSM can use this, not just the LSM you've
targeted.
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1972,8 +1979,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
From: Daniel Colascione <hidden> Date: 2020-03-26 18:15:16
Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor. SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
Inside the kernel, a pair of new anon_inodes interface,
anon_inode_getfile_secure and anon_inode_getfd_secure, allow callers
to opt into this SELinux management. In this new "secure" mode,
anon_inodes creates new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.
This patch series is one of two fork of [1] and is an
alternative to [2].
The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.
I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.
The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].
This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.
Changes from the first version of the patch:
- Removed some error checks
- Defined a new anon_inode SELinux class to resolve the
ambiguity in [3]
- Inherit sclass as well as descriptor from context inode
Changes from the second version of the patch:
- Fixed example policy in the commit message to reflect the use of
the new anon_inode class.
[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
[2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/
[3] https://lore.kernel.org/lkml/23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov/
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 196 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
security/selinux/hooks.c | 54 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 272 insertions(+), 46 deletions(-)
--
2.25.1.696.g5e7596f4ac-goog
From: Daniel Colascione <hidden> Date: 2020-03-26 18:15:19
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 196 ++++++++++++++++++++++++++++--------
fs/userfaultfd.c | 4 +-
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 9 ++
include/linux/security.h | 4 +
security/security.c | 10 ++
6 files changed, 191 insertions(+), 45 deletions(-)
From: Stephen Smalley <hidden> Date: 2020-03-26 18:59:25
On 3/26/20 2:14 PM, Daniel Colascione wrote:
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
Repeating verbatim what I said on v2 of patch 1/3.
From: Daniel Colascione <hidden> Date: 2020-03-26 18:15:25
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 : 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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
From: Stephen Smalley <hidden> Date: 2020-03-26 19:08:29
On 3/26/20 2:14 PM, Daniel Colascione wrote:
quoted hunk
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 : 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 <redacted>
---
security/selinux/hooks.c | 54 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 56 insertions(+)
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1972,8 +1979,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
From: Daniel Colascione <hidden> Date: 2020-03-26 20:06:47
Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor. SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
Inside the kernel, a pair of new anon_inodes interface,
anon_inode_getfile_secure and anon_inode_getfd_secure, allow callers
to opt into this SELinux management. In this new "secure" mode,
anon_inodes creates new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.
This patch series is one of two fork of [1] and is an
alternative to [2].
The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.
I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.
The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].
This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.
Changes from the first version of the patch:
- Removed some error checks
- Defined a new anon_inode SELinux class to resolve the
ambiguity in [3]
- Inherit sclass as well as descriptor from context inode
Changes from the second version of the patch:
- Fixed example policy in the commit message to reflect the use of
the new anon_inode class.
Changes from the third version of the patch:
- Dropped the fops parameter to the LSM hook
- Documented hook parameters
- Fixed incorrect class used for SELinux transition
- Removed stray UFFD changed early in the series
- Removed a redundant ERR_PTR(PTR_ERR())
[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
[2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/
[3] https://lore.kernel.org/lkml/23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov/
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 196 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
security/selinux/hooks.c | 53 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 271 insertions(+), 46 deletions(-)
--
2.25.1.696.g5e7596f4ac-goog
From: Daniel Colascione <hidden> Date: 2020-03-26 20:06:49
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 196 ++++++++++++++++++++++++++++--------
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
5 files changed, 190 insertions(+), 42 deletions(-)
From: Stephen Smalley <hidden> Date: 2020-03-27 13:39:02
On 3/26/20 4:06 PM, Daniel Colascione wrote:
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fops argument can be removed here too, unused now by this function.
/**
- * anon_inode_getfd - creates a new file instance by hooking it up to an
- * anonymous inode, and a dentry that describe the "class"
- * of the file
+ * anon_inode_getfile_secure - creates a new file instance by hooking
+ * it up to a new anonymous inode and a
+ * dentry that describe the "class" of the
+ * file. Make it possible to use security
+ * modules to control access to the
+ * new file.
*
* @name: [in] name of the "class" of the new file
* @fops: [in] file operations for the new file
* @priv: [in] private data for the new file (will be file's private_data)
- * @flags: [in] flags
+ * @flags: [in] flags for the file
+ * @anon_inode_flags: [in] flags for anon_inode*
anon_inode_flags leftover from prior version of the patch, not an
argument in the current code. Likewise, the "for the file" addendum to
the @flags argument description is a leftover and not needed.
> + * Creates a new file by hooking it on an unspecified inode. This is
> + * useful for files that do not need to have a full-fledged inode in
> + * order to operate correctly. All the files created with
> + * anon_inode_getfile_secure() will have distinct inodes, avoiding
> + * code duplication for the file/inode/dentry setup.
The two preceding sentences directly contradict each other.
+/**
+ * anon_inode_getfile - creates a new file instance by hooking it up
+ * to an anonymous inode and a dentry that
+ * describe the "class" of the file.
This would be identical to the original except for different word
wrapping. Probably a leftover from prior version of the patch where you
were modifying the existing interface. Recommend reverting such changes
to minimize unnecessary noise in your diff and meke it easier to tell
what changes are real.
+ *
+ * @name: [in] name of the "class" of the new file
+ * @fops: [in] file operations for the new file
+ * @priv: [in] private data for the new file (will be file's private_data)
+ * @flags: [in] flags for the file
*
- * Creates a new file by hooking it on a single inode. This is useful for files
+ * Creates a new file by hooking it on an unspecified inode. This is useful for files
Unnecessary difference here; this interface does use a single inode.
quoted hunk
@@ -146,6 +207,57 @@ int anon_inode_getfd(const char *name, const struct file_operations *fops, put_unused_fd(fd); return error; }++/**+ * anon_inode_getfd_secure - creates a new file instance by hooking it+ * up to a new anonymous inode and a dentry+ * that describe the "class" of the file.+ * Make it possible to use security modules+ * to control access to the new file.+ *+ * @name: [in] name of the "class" of the new file+ * @fops: [in] file operations for the new file+ * @priv: [in] private data for the new file (will be file's private_data)+ * @flags: [in] flags+ *
> + * Creates a new file by hooking it on an unspecified inode. This is
> + * useful for files that do not need to have a full-fledged inode in
> + * order to operate correctly. All the files created with
> + * anon_inode_getfile_secure() will have distinct inodes, avoiding
> + * code duplication for the file/inode/dentry setup.
The two preceding sentences contradict each other.
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1022,8 +1024,10 @@ static int resolve_userfault_fork(struct userfaultfd_ctx *ctx,{intfd;-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,new,-O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS));+fd=anon_inode_getfd_secure(+"[userfaultfd]",&userfaultfd_fops,new,+O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS),+ctx->owner);if(fd<0)returnfd;
@@ -1974,8 +1979,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
From: Daniel Colascione <hidden> Date: 2020-03-26 20:07:00
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 : 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 <redacted>
---
security/selinux/hooks.c | 53 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 55 insertions(+)
From: Stephen Smalley <hidden> Date: 2020-03-27 13:48:25
On 3/26/20 4:06 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 : 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 <redacted>
From: Daniel Colascione <hidden> Date: 2020-04-01 21:39:16
Userfaultfd in unprivileged contexts could be potentially very
useful. We'd like to harden userfaultfd to make such unprivileged use
less risky. This patch series allows SELinux to manage userfaultfd
file descriptors and in the future, other kinds of
anonymous-inode-based file descriptor. SELinux policy authors can
apply policy types to anonymous inodes by providing name-based
transition rules keyed off the anonymous inode internal name (
"[userfaultfd]" in the case of userfaultfd(2) file descriptors) and
applying policy to the new SIDs thus produced.
Inside the kernel, a pair of new anon_inodes interface,
anon_inode_getfile_secure and anon_inode_getfd_secure, allow callers
to opt into this SELinux management. In this new "secure" mode,
anon_inodes creates new ephemeral inodes for anonymous file objects
instead of reusing the normal anon_inodes singleton dummy inode. A new
LSM hook gives security modules an opportunity to configure and veto
these ephemeral inodes.
This patch series is one of two fork of [1] and is an
alternative to [2].
The primary difference between the two patch series is that this
partch series creates a unique inode for each "secure" anonymous
inode, while the other patch series ([2]) continues using the
singleton dummy anonymous inode and adds a way to attach SELinux
security information directly to file objects.
I prefer the approach in this patch series because 1) it's a smaller
patch than [2], and 2) it produces a more regular security
architecture: in this patch series, secure anonymous inodes aren't
S_PRIVATE and they maintain the SELinux property that the label for a
file is in its inode. We do need an additional inode per anonymous
file, but per-struct-file inode creation doesn't seem to be a problem
for pipes and sockets.
The previous version of this feature ([1]) created a new SELinux
security class for userfaultfd file descriptors. This version adopts
the generic transition-based approach of [2].
This patch series also differs from [2] in that it doesn't affect all
anonymous inodes right away --- instead requiring anon_inodes callers
to opt in --- but this difference isn't one of basic approach. The
important question to resolve is whether we should be creating new
inodes or enhancing per-file data.
Changes from the first version of the patch:
- Removed some error checks
- Defined a new anon_inode SELinux class to resolve the
ambiguity in [3]
- Inherit sclass as well as descriptor from context inode
Changes from the second version of the patch:
- Fixed example policy in the commit message to reflect the use of
the new anon_inode class.
Changes from the third version of the patch:
- Dropped the fops parameter to the LSM hook
- Documented hook parameters
- Fixed incorrect class used for SELinux transition
- Removed stray UFFD changed early in the series
- Removed a redundant ERR_PTR(PTR_ERR())
Changes from the fourth version of the patch:
- Removed an unused parameter from an internal function
- Fixed function documentation
[1] https://lore.kernel.org/lkml/20200211225547.235083-1-dancol@google.com/
[2] https://lore.kernel.org/linux-fsdevel/20200213194157.5877-1-sds@tycho.nsa.gov/
[3] https://lore.kernel.org/lkml/23f725ca-5b5a-5938-fcc8-5bbbfc9ba9bc@tycho.nsa.gov/
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 191 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
security/selinux/hooks.c | 53 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 267 insertions(+), 45 deletions(-)
--
2.26.0.rc2.310.g2932bb562d-goog
From: Daniel Colascione <hidden> Date: 2020-04-01 21:39:18
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 191 ++++++++++++++++++++++++++++--------
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 11 +++
include/linux/security.h | 3 +
security/security.c | 9 ++
5 files changed, 186 insertions(+), 41 deletions(-)
From: James Morris <jmorris@namei.org> Date: 2020-05-07 16:03:20
On Wed, 1 Apr 2020, Daniel Colascione wrote:
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
Al, Andrew, wondering if you could look at these anon inode changes
before we merge this?
From: Eric Biggers <ebiggers@kernel.org> Date: 2020-08-04 21:22:22
On Wed, Apr 01, 2020 at 02:39:01PM -0700, Daniel Colascione wrote:
quoted hunk
This change adds two new functions, anon_inode_getfile_secure and
anon_inode_getfd_secure, that create anonymous-node files with
individual non-S_PRIVATE inodes to which security modules can apply
policy. Existing callers continue using the original singleton-inode
kind of anonymous-inode file. We can transition anonymous inode users
to the new kind of anonymous inode in individual patches for the sake
of bisection and review.
The new functions accept an optional context_inode parameter that
callers can use to provide additional contextual information to
security modules, e.g., indicating that one anonymous struct file is a
logical child of another, allowing a security model to propagate
security information from one to the other.
Signed-off-by: Daniel Colascione <redacted>
---
fs/anon_inodes.c | 191 ++++++++++++++++++++++++++++--------
include/linux/anon_inodes.h | 13 +++
include/linux/lsm_hooks.h | 11 +++
include/linux/security.h | 3 +
security/security.c | 9 ++
5 files changed, 186 insertions(+), 41 deletions(-)
/**
- * anon_inode_getfd - creates a new file instance by hooking it up to an
- * anonymous inode, and a dentry that describe the "class"
- * of the file
+ * anon_inode_getfile_secure - creates a new file instance by hooking
+ * it up to a new anonymous inode and a
+ * dentry that describe the "class" of the
+ * file. Make it possible to use security
+ * modules to control access to the
+ * new file.
+ *
+ * @name: [in] name of the "class" of the new file
+ * @fops: [in] file operations for the new file
+ * @priv: [in] private data for the new file (will be file's private_data)
+ * @flags: [in] flags
+ *
+ * Creates a new file by hooking it on an unspecified inode. This is
+ * useful for files that do not need to have a full-fledged filesystem
+ * to operate correctly. All the files created with
+ * anon_inode_getfile_secure() will have distinct inodes, avoiding
+ * code duplication for the file/inode/dentry setup. Returns the
+ * newly created file* or an error pointer.
+ */
+struct file *anon_inode_getfile_secure(const char *name,
+ const struct file_operations *fops,
+ void *priv, int flags,
+ const struct inode *context_inode)
Why copy-and-paste this long comment if it's not even updated to document the
new argument?
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};structuserfaultfd_fork_ctx{
@@ -1022,8 +1024,10 @@ static int resolve_userfault_fork(struct userfaultfd_ctx *ctx,{intfd;-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,new,-O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS));+fd=anon_inode_getfd_secure(+"[userfaultfd]",&userfaultfd_fops,new,+O_RDWR|(new->flags&UFFD_SHARED_FCNTL_FLAGS),+ctx->owner);if(fd<0)returnfd;
@@ -1974,8 +1979,25 @@ SYSCALL_DEFINE1(userfaultfd, int, flags)/* prevent the mm struct to be freed */mmgrab(ctx->mm);-fd=anon_inode_getfd("[userfaultfd]",&userfaultfd_fops,ctx,-O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS));+file=anon_inode_getfile_secure(+"[userfaultfd]",&userfaultfd_fops,ctx,+O_RDWR|(flags&UFFD_SHARED_FCNTL_FLAGS),+NULL);+if(IS_ERR(file)){+fd=PTR_ERR(file);+gotoout;+}++fd=get_unused_fd_flags(O_RDONLY|O_CLOEXEC);+if(fd<0){+fput(file);+gotoout;+}++ctx->owner=file_inode(file);+fd_install(fd,file);++out:if(fd<0){mmdrop(ctx->mm);kmem_cache_free(userfaultfd_ctx_cachep,ctx);
@@ -76,6 +76,8 @@ struct userfaultfd_ctx {boolmmap_changing;/* mm with one ore more vmas attached to this userfaultfd_ctx */structmm_struct*mm;+/* The inode that owns this context --- not a strong reference. */+conststructinode*owner;};
Adding this field seems wrong. There's no reference held to it, so it can only
be used if the caller holds a reference to the inode anyway. The only user of
this field is via userfafultfd_read(), so why not just use the inode of the
struct file passed to userfaultfd_read()?
From: Daniel Colascione <hidden> Date: 2020-04-01 21:39:33
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 : 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 <redacted>
---
security/selinux/hooks.c | 53 +++++++++++++++++++++++++++++
security/selinux/include/classmap.h | 2 ++
2 files changed, 55 insertions(+)
From: James Morris <jmorris@namei.org> Date: 2020-04-22 16:55:46
On Mon, 13 Apr 2020, Daniel Colascione wrote:
On Wed, Apr 1, 2020 at 2:39 PM Daniel Colascione [off-list ref] wrote:
quoted
Changes from the fourth version of the patch:
Is there anything else that needs to be done before merging this patch series?
The vfs changes need review and signoff from the vfs folk, the SELinux
changes by either Paul or Stephen, and we also need signoff on the LSM
hooks from other major LSM authors (Casey and John, at a minimum).
--
James Morris
[off-list ref]
On Wed, Apr 1, 2020 at 2:39 PM Daniel Colascione [off-list ref] wrote:
quoted
Changes from the fourth version of the patch:
Is there anything else that needs to be done before merging this patch series?
The vfs changes need review and signoff from the vfs folk, the SELinux
changes by either Paul or Stephen, and we also need signoff on the LSM
hooks from other major LSM authors (Casey and John, at a minimum).
I haven't had the opportunity to test this relative to Smack.
It's unclear whether the change would impact security modules that
don't provide hooks for it. I will bump my priority on this, but it's
still going to be a bit before I can get to it.
NB The example cited above needs to be tweaked for changes in the
logic from the original RFC patch on which the example was
based. In particular, the userfaultfd CIL policy needs to be updated
to define and use the new anon_inode class and to allow create
permission as follows.
$ cat userfaultfd.cil
(class anon_inode ())
(classcommon anon_inode file)
(classorder (unordered anon_inode))
(type uffd_t)
; Label the UFFD with uffd_t; this can be specialized per domain
(typetransition unconfined_t unconfined_t anon_inode "[userfaultfd]" uffd_t)
(allow unconfined_t uffd_t (anon_inode (create)))
; Permit read() and ioctl() on the UFFD.
; Comment out if you want to test read or basic ioctl enforcement.
(allow unconfined_t uffd_t (anon_inode (read)))
(allow unconfined_t uffd_t (anon_inode (ioctl)))
; Uncomment one of the allowx lines below to test ioctl whitelisting.
; Currently the 1st one is uncommented; comment that out if trying another.
; None
(allowx unconfined_t uffd_t (ioctl anon_inode ((0x00))))
; UFFDIO_API
;(allowx unconfined_t uffd_t (ioctl anon_inode ((0xaa3f))))
On Wed, Apr 1, 2020 at 2:39 PM Daniel Colascione [off-list ref] wrote:
quoted
Changes from the fourth version of the patch:
Is there anything else that needs to be done before merging this patch series?
The vfs changes need review and signoff from the vfs folk, the SELinux
changes by either Paul or Stephen, and we also need signoff on the LSM
hooks from other major LSM authors (Casey and John, at a minimum).
You can add my
Acked-by: Casey Schaufler [off-list ref]
for this patchset.
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-04-27 19:41:08
On Mon, Apr 27, 2020 at 1:17 PM Casey Schaufler [off-list ref] wrote:
On 4/22/2020 9:55 AM, James Morris wrote:
quoted
On Mon, 13 Apr 2020, Daniel Colascione wrote:
quoted
On Wed, Apr 1, 2020 at 2:39 PM Daniel Colascione [off-list ref] wrote:
quoted
Changes from the fourth version of the patch:
Is there anything else that needs to be done before merging this patch series?
The vfs changes need review and signoff from the vfs folk, the SELinux
changes by either Paul or Stephen, and we also need signoff on the LSM
hooks from other major LSM authors (Casey and John, at a minimum).
You can add my
Acked-by: Casey Schaufler [off-list ref]
for this patchset.
This version of the series addresses all of my comments, so you can add my
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
I don't know though how to get a response from the vfs folks; the
series has been posted repeatedly without any
response by them.
From: James Morris <jmorris@namei.org> Date: 2020-06-04 03:56:46
On Wed, 1 Apr 2020, Daniel Colascione wrote:
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 191 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
security/selinux/hooks.c | 53 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 267 insertions(+), 45 deletions(-)
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git secure_uffd_v5.9
and next-testing.
This will provide test coverage in linux-next, as we aim to get this
upstream for v5.9.
I had to make some minor fixups, please review.
--
James Morris
[off-list ref]
From: Stephen Smalley <stephen.smalley.work@gmail.com> Date: 2020-06-04 18:52:08
On Wed, Jun 3, 2020 at 11:59 PM James Morris [off-list ref] wrote:
On Wed, 1 Apr 2020, Daniel Colascione wrote:
quoted
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 191 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
security/selinux/hooks.c | 53 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 267 insertions(+), 45 deletions(-)
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git secure_uffd_v5.9
and next-testing.
This will provide test coverage in linux-next, as we aim to get this
upstream for v5.9.
I had to make some minor fixups, please review.
Adding a colleague from the Android kernel team.
On Thu, Jun 4, 2020 at 11:52 AM Stephen Smalley
[off-list ref] wrote:
On Wed, Jun 3, 2020 at 11:59 PM James Morris [off-list ref] wrote:
quoted
On Wed, 1 Apr 2020, Daniel Colascione wrote:
quoted
Daniel Colascione (3):
Add a new LSM-supporting anonymous inode interface
Teach SELinux about anonymous inodes
Wire UFFD up to SELinux
fs/anon_inodes.c | 191 ++++++++++++++++++++++------
fs/userfaultfd.c | 30 ++++-
include/linux/anon_inodes.h | 13 ++
include/linux/lsm_hooks.h | 11 ++
include/linux/security.h | 3 +
security/security.c | 9 ++
security/selinux/hooks.c | 53 ++++++++
security/selinux/include/classmap.h | 2 +
8 files changed, 267 insertions(+), 45 deletions(-)
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git secure_uffd_v5.9
and next-testing.
This will provide test coverage in linux-next, as we aim to get this
upstream for v5.9.
I had to make some minor fixups, please review.