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;
>
next prev parent 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®