All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Taras Kondratiuk <takondra@cisco.com>,
	Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@parisplace.org>
Cc: selinux@tycho.nsa.gov, linux-kernel@vger.kernel.org,
	xe-linux-external@cisco.com
Subject: Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling
Date: Wed, 19 Sep 2018 15:00:33 -0400	[thread overview]
Message-ID: <f283c1e7-19eb-2b99-3fef-a19e2bf99a2b@tycho.nsa.gov> (raw)
In-Reply-To: <20180919165248.53090-1-takondra@cisco.com>

On 09/19/2018 12:52 PM, Taras Kondratiuk wrote:
> When files on NFSv4 server are not properly labeled (label doesn't match
> a policy on a client) they will end up with unlabeled_t type which is
> too generic. We would like to be able to set a default context per
> mount. 'defcontext' mount option looks like a nice solution, but it
> doesn't seem to be fully implemented for native labeling. Default
> context is stored, but is never used.
> 
> The patch adds a fallback to a default context if a received context is
> invalid. If the inode context is already initialized, then it is left
> untouched to preserve a context set locally on a client.

Can you explain the use case further?  Why are you exporting a 
filesystem with security labeling enabled to a client that doesn't 
understand all of the labels used within it?  Why wouldn't you just 
disable NFSv4 security labeling and/or use a regular context= mount to 
assign a single context to all files in the mount?

To be clear, defcontext= doesn't work that way for local/FS_USE_XATTR 
filesystems. The context specified by it is only used for:
1) files that don't implement the xattr inode operations at all,
2) files that lack a security.selinux xattr,
3) the MLS portion of the context if it was missing (strictly as a 
legacy compatibility mechanism for RHEL4 which predated the enabling of 
the MLS field/logic).

A file with a security.selinux xattr that is invalid under policy for 
any reason other than a missing MLS field will be handled as having the 
unlabeled context.

So this would be a divergence in semantics for defcontext= between 
local/FS_USE_XATTR and NFS/FS_USE_NATIVE filesystems.

> 
> Signed-off-by: Taras Kondratiuk <takondra@cisco.com>
> ---
>   security/selinux/hooks.c | 25 ++++++++++++++++++++++++-
>   1 file changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index ad9a9b8e9979..f7debe798bf5 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -6598,7 +6598,30 @@ static void selinux_inode_invalidate_secctx(struct inode *inode)
>    */
>   static int selinux_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen)
>   {
> -	return selinux_inode_setsecurity(inode, XATTR_SELINUX_SUFFIX, ctx, ctxlen, 0);
> +	struct superblock_security_struct *sbsec;
> +	struct inode_security_struct *isec;
> +	int rc;
> +
> +	rc = selinux_inode_setsecurity(inode, XATTR_SELINUX_SUFFIX, ctx, ctxlen, 0);

In this case, we likely don't gain much by reusing 
selinux_inode_setsecurity() here and could just inline the relevant 
portion of it if we were to make this change.  Logically they mean 
different things.

> +
> +	/*
> +	 * In case of Native labeling with defcontext mount option fall back
> +	 * to a default SID if received context is invalid.
> +	 */
> +	if (rc == -EINVAL) {
> +		sbsec = inode->i_sb->s_security;
> +		if (sbsec->behavior == SECURITY_FS_USE_NATIVE &&
> +		    sbsec->flags & DEFCONTEXT_MNT) {
> +			isec = inode->i_security;
> +			if (!isec->initialized) {
> +				isec->sclass = inode_mode_to_security_class(inode->i_mode);
> +				isec->sid = sbsec->def_sid;
> +				isec->initialized = 1;
> +			}
> +			rc = 0;
> +		}
> +	}
> +	return rc;
>   }
>   
>   /*
> 


  parent reply	other threads:[~2018-09-19 18:58 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19 16:52 [RFC PATCH] selinux: add a fallback to defcontext for native labeling Taras Kondratiuk
2018-09-19 18:47 ` Paul Moore
2018-09-19 19:00 ` Stephen Smalley [this message]
2018-09-20  2:41   ` Taras Kondratiuk
2018-09-20 14:49     ` Stephen Smalley
2018-09-20 22:59       ` Taras Kondratiuk
2018-09-21 14:40         ` Stephen Smalley
2018-09-24 21:17           ` Taras Kondratiuk
2018-09-25  3:46           ` Paul Moore
2018-09-25  5:45             ` Taras Kondratiuk
2018-09-25 14:00               ` Stephen Smalley
2018-09-25 16:03                 ` Paul Moore
2018-09-25 16:03                   ` Paul Moore
2018-09-25 16:39                   ` Stephen Smalley
2018-09-25 19:10                     ` Taras Kondratiuk
2018-10-02 18:48                       ` Taras Kondratiuk
2018-10-02 19:41                         ` Stephen Smalley
2018-10-03  0:58                           ` Taras Kondratiuk
2018-09-25 15:41               ` Paul Moore

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=f283c1e7-19eb-2b99-3fef-a19e2bf99a2b@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=eparis@parisplace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=takondra@cisco.com \
    --cc=xe-linux-external@cisco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.