mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Christian Göttsche" <cgzones@googlemail.com>
Cc: Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	selinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selinux: allow kernfs symlinks to inherit parent directory context
Date: Fri, 24 Jan 2020 13:53:30 -0500	[thread overview]
Message-ID: <6e33cbcd-31fd-2d50-5d0f-70eb475f9811@tycho.nsa.gov> (raw)
In-Reply-To: <20200124184221.322248-1-cgzones@googlemail.com>

On 1/24/20 1:42 PM, Christian Göttsche wrote:
> Currently symlinks on kernel filesystems, like sysfs, are labeled on
> creation with the parent fs root sid.
> 
> Allow symlinks to inherit the parent directory context, so fine-grained
> kernfs labeling can be applied to symlinks too and checking contexts
> doesn't complain about them.
> 
> For backward-compatibility this behavior is contained in a new policy
> capability: kernfs_sovereign_symlinks
> 
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
>   security/selinux/hooks.c            | 5 ++++-
>   security/selinux/include/security.h | 8 ++++++++
>   security/selinux/ss/services.c      | 3 ++-
>   3 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index d9e8b2131..1303bc8c4 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1475,7 +1475,10 @@ static int inode_doinit_with_dentry(struct inode *inode, struct dentry *opt_dent
>   		/* Default to the fs superblock SID. */
>   		sid = sbsec->sid;
>   
> -		if ((sbsec->flags & SE_SBGENFS) && !S_ISLNK(inode->i_mode)) {
> +		if (((sbsec->flags & SE_SBGENFS) &&
> +		     (!S_ISLNK(inode->i_mode))) ||
> +		    (selinux_policycap_kernfs_sovereign_symlinks() &&

Not fond of the name.  1) kernfs is a kernel implementation detail, 
shouldn't be exposed to policy; genfs is the policy construct 2) 
sovereign doesn't seem to fit the meaning of this capability; seclabel 
would be more appropriate.

> +		     (sbsec->flags & SE_SBGENFS_XATTR))) {

Why limit this to SE_SBGENFS_XATTR filesystems?  Why not just make the test:
	if ((sbsec->flags & SE_SBGENFS) && (!S_ISLNK(inode->i_mode) || 
selinux_policycap_genfs_symlinkseclabel()))
or similar.

>   			/* We must have a dentry to determine the label on
>   			 * procfs inodes */
>   			if (opt_dentry) {
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index a39f9565d..cc8217848 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -79,6 +79,7 @@ enum {
>   	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>   	POLICYDB_CAPABILITY_CGROUPSECLABEL,
>   	POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION,
> +	POLICYDB_CAPABILITY_KERNFS_SOVEREIGN_SYMLINKS,
>   	__POLICYDB_CAPABILITY_MAX
>   };
>   #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
> @@ -209,6 +210,13 @@ static inline bool selinux_policycap_nnp_nosuid_transition(void)
>   	return state->policycap[POLICYDB_CAPABILITY_NNP_NOSUID_TRANSITION];
>   }
>   
> +static inline bool selinux_policycap_kernfs_sovereign_symlinks(void)
> +{
> +	struct selinux_state *state = &selinux_state;
> +
> +	return state->policycap[POLICYDB_CAPABILITY_KERNFS_SOVEREIGN_SYMLINKS];
> +}
> +
>   int security_mls_enabled(struct selinux_state *state);
>   int security_load_policy(struct selinux_state *state,
>   			 void *data, size_t len);
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 216ce602a..b70380947 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -73,7 +73,8 @@ const char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
>   	"extended_socket_class",
>   	"always_check_network",
>   	"cgroup_seclabel",
> -	"nnp_nosuid_transition"
> +	"nnp_nosuid_transition",
> +	"kernfs_sovereign_symlinks"
>   };
>   
>   static struct selinux_ss selinux_ss;
> 


  reply	other threads:[~2020-01-24 18:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-24 18:42 Christian Göttsche
2020-01-24 18:53 ` Stephen Smalley [this message]
2020-01-24 19:08   ` Christian Göttsche
2020-01-24 19:18     ` Stephen Smalley
2020-01-28 19:16 ` [PATCH v2] " Christian Göttsche

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=6e33cbcd-31fd-2d50-5d0f-70eb475f9811@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=cgzones@googlemail.com \
    --cc=eparis@parisplace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.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

all inboxes | Powered by JetHome®