linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Casey Schaufler <casey@schaufler-ca.com>
To: Ondrej Mosnacek <omosnace@redhat.com>,
	selinux@vger.kernel.org, Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	linux-security-module@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tejun Heo <tj@kernel.org>,
	linux-fsdevel@vger.kernel.org, cgroups@vger.kernel.org
Subject: Re: [PATCH v2 0/3] Allow initializing the kernfs node's secctx based on its parent
Date: Wed, 9 Jan 2019 09:19:31 -0800	[thread overview]
Message-ID: <fbdcf8ef-1587-18f2-3293-452d62305ab3@schaufler-ca.com> (raw)
In-Reply-To: <20190109162830.8309-1-omosnace@redhat.com>

On 1/9/2019 8:28 AM, Ondrej Mosnacek wrote:
> Changes in v2:
> - add docstring for the new hook in union security_list_options
> - initialize *ctx to NULL and *ctxlen to 0 in case the hook is not
>   implemented
> v1: https://lore.kernel.org/selinux/20190109091028.24485-1-omosnace@redhat.com/T/
>
> This series adds a new security hook that allows to initialize the security
> context of kernfs properly, taking into account the parent context. Kernfs
> nodes require special handling here, since they are not bound to specific
> inodes/superblocks, but instead represent the backing tree structure that
> is used to build the VFS tree when the kernfs tree is mounted.
>
> The kernfs nodes initially do not store any security context and rely on
> the LSM to assign some default context to inodes created over them. 

This seems like a bug in kernfs. Why doesn't kernfs adhere to the usual
and expected filesystem behavior?

> Kernfs
> inodes, however, allow setting an explicit context via the *setxattr(2)
> syscalls, in which case the context is stored inside the kernfs node's
> metadata.
>
> SELinux (and possibly other LSMs) initialize the context of newly created
> FS objects based on the parent object's context (usually the child inherits
> the parent's context, unless the policy dictates otherwise). 

An LSM might use information about the parent other than the "context".
Smack, for example, uses an attribute SMACK64TRANSMUTE from the parent
to determine whether the Smack label of the new object should be taken
from the parent or the process. Passing the "context" of the parent is
insufficient for Smack.

> This is done
> by hooking the creation of the new inode corresponding to the newly created
> file/directory via security_inode_init_security() (most filesystems always
> create a fresh inode when a new FS object is created). However, kernfs nodes
> can be created "behind the scenes" while the filesystem is not mounted
> anywhere and thus no inodes exist.
>
> Therefore, to allow maintaining similar behavior for kernfs nodes, a new LSM
> hook is needed, which would allow initializing the kernfs node's security
> context based on the context stored in the parent's node (if any).
>
> The main motivation for this change is that the userspace users of cgroupfs
> (which is built on kernfs) expect the usual security context inheritance
> to work under SELinux (see [1] and [2]). This functionality is required for
> better confinement of containers under SELinux.
>
> The first patch adds the new LSM hook; the second patch implements the hook
> in SELinux; and the third patch modifies kernfs to use the new hook to
> initialize the security context of kernfs nodes whenever its parent node
> has a non-default context set.
>
> Note: the patches are based on current selinux/next [3], but they seem to
> apply cleanly on top of v5.0-rc1 as well.
>
> Testing:
> - passed SELinux testsuite on Fedora 29 (x86_64) when applied on top of
>   current Rawhide kernel (5.0.0-0.rc1.git0.1) [4]
> - passed the reproducer from the last patch
>
> [1] https://github.com/SELinuxProject/selinux-kernel/issues/39
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1553803
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git/log/?h=selinux-pr-20181224
> [4] https://copr.fedorainfracloud.org/coprs/omos/kernel-testing/build/842855/
>
> Ondrej Mosnacek (3):
>   LSM: Add new hook for generic node initialization
>   selinux: Implement the object_init_security hook
>   kernfs: Initialize security of newly created nodes
>
>  fs/kernfs/dir.c             | 49 ++++++++++++++++++++++++++++++++++---
>  fs/kernfs/inode.c           |  9 +++----
>  fs/kernfs/kernfs-internal.h |  4 +++
>  include/linux/lsm_hooks.h   | 30 +++++++++++++++++++++++
>  include/linux/security.h    | 14 +++++++++++
>  security/security.c         | 10 ++++++++
>  security/selinux/hooks.c    | 41 +++++++++++++++++++++++++++++++
>  7 files changed, 149 insertions(+), 8 deletions(-)
>


  parent reply	other threads:[~2019-01-09 17:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-09 16:28 [PATCH v2 0/3] Allow initializing the kernfs node's secctx based on its parent Ondrej Mosnacek
2019-01-09 16:28 ` [PATCH v2 1/3] LSM: Add new hook for generic node initialization Ondrej Mosnacek
2019-01-09 17:08   ` Casey Schaufler
2019-01-11  1:57     ` Paul Moore
2019-01-11 18:30       ` Casey Schaufler
2019-01-14  9:01       ` Ondrej Mosnacek
2019-01-09 16:28 ` [PATCH v2 2/3] selinux: Implement the object_init_security hook Ondrej Mosnacek
2019-01-09 16:28 ` [PATCH v2 3/3] kernfs: Initialize security of newly created nodes Ondrej Mosnacek
2019-01-11 20:52   ` Tejun Heo
2019-01-09 17:19 ` Casey Schaufler [this message]
2019-01-09 20:37   ` [PATCH v2 0/3] Allow initializing the kernfs node's secctx based on its parent Stephen Smalley
2019-01-09 22:03     ` Casey Schaufler
2019-01-10 14:15       ` Stephen Smalley
2019-01-10 17:54         ` Casey Schaufler
2019-01-10 19:37           ` Stephen Smalley
2019-01-11  2:20             ` Paul Moore
2019-01-14  9:01               ` Ondrej Mosnacek
2019-01-11 18:22             ` Casey Schaufler
2019-01-14  9:01           ` Ondrej Mosnacek
2019-01-22  8:49             ` Ondrej Mosnacek
2019-01-22 14:17               ` Stephen Smalley
2019-01-22 15:26                 ` 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=fbdcf8ef-1587-18f2-3293-452d62305ab3@schaufler-ca.com \
    --to=casey@schaufler-ca.com \
    --cc=cgroups@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    --cc=tj@kernel.org \
    /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).