[RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

As systemd ramps up enabling NoNewPrivileges (either explicitly in
service unit files or as a side effect of other security-related
settings in service unit files), we're increasingly running afoul of
its interactions with SELinux.

The end result is bad for the security of both SELinux-disabled and
SELinux-enabled systems.  Packagers have to turn off these
options in the unit files to preserve SELinux domain transitions.  For
users who choose to disable SELinux, this means that they miss out on
at least having the systemd-supported protections.  For users who keep
SELinux enabled, they may still be missing out on some protections
because it isn't necessarily guaranteed that the SELinux policy for
that service provides the same protections in all cases.

Our options seem to be:

1) Just keep on the way we are now, i.e. packagers have to remove
default protection settings from upstream package unit files in order
to have them work with SELinux (and not just NoNewPrivileges=
itself; increasingly systemd is enabling NNP as a side effect of other
unit file options, even seemingly unrelated ones like PrivateDevices).
SELinux-disabled users lose entirely, SELinux-enabled users may lose
(depending on whether SELinux policy provides equivalent or
better guarantees).

2) Change systemd to automatically disable NNP on SELinux-enabled
systems.  Unit files can be left unmodified from upstream.  SELinux-
disabled users win.  SELinux-enabled users may lose.

3) Try to use typebounds, since we allow bounded transitions under NNP.
Unit files can be left unmodified from upstream. SELinux-disabled users
win.  SELinux-enabled users get to benefit from systemd-provided
protections.  However, this option is impractical to implement in policy
currently, since typebounds requires us to ensure that each domain is
allowed everything all of its descendant domains are allowed, and this
has to be repeated for the entire chain of domain transitions.  There is
no way to clone all allow rules from children to the parent in policy
currently, and it is doubtful that doing so would be desirable even if
it were practical, as it requires leaking permissions to objects and
operations into parent domains that could weaken their own security in
order to allow them to the children (e.g. if a child requires execmem
permission, then so does the parent; if a child requires read to a symbolic
link or temporary file that it can write, then so does the parent, ...).

4) Decouple NNP from SELinux transitions, so that we don't have to
make a choice between them. Introduce a new policy capability that
causes the ability to transition under NNP to be based on a new permission
check between the old and new contexts rather than typebounds.  Domain
transitions can then be allowed in policy without requiring the parent
to be a strict superset of all of its children.  The rationale for this
divergence from NNP behavior for capabilities is that SELinux permissions
are substantially broader than just capabilities (they express a full
access matrix, not just privileges) and can only be used to further
restrict capabilities, not grant them beyond what is already permitted.
Unit files can be left unmodified from upstream.  SELinux-disabled users
win.  SELinux-enabled users can benefit from systemd-provided protections
and policy won't need to radically change.

This change takes the last approach above, as it seems to be the
best option.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
---
 security/selinux/hooks.c            | 41 ++++++++++++++++++++++++-------------
 security/selinux/include/classmap.h |  2 +-
 security/selinux/include/security.h |  2 ++
 security/selinux/ss/services.c      |  7 ++++++-
 4 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3a06afb..f0c11c2 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
 		return 0; /* No change in credentials */
 
 	/*
-	 * The only transitions we permit under NNP or nosuid
-	 * are transitions to bounded SIDs, i.e. SIDs that are
-	 * guaranteed to only be allowed a subset of the permissions
-	 * of the current SID.
+	 * If the policy enables the nnp_transition policy capability,
+	 * then we permit transitions under NNP or nosuid if the
+	 * policy explicitly allows nnp_transition permission between
+	 * the old and new contexts.
 	 */
-	rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
-	if (rc) {
+	if (selinux_policycap_nnptransition) {
+		rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
+				  SECCLASS_PROCESS,
+				  PROCESS__NNP_TRANSITION, NULL);
+		if (!rc)
+			return 0;
+	} else {
 		/*
-		 * On failure, preserve the errno values for NNP vs nosuid.
-		 * NNP:  Operation not permitted for caller.
-		 * nosuid:  Permission denied to file.
+		 * Otherwise, the only transitions we permit under NNP or nosuid
+		 * are transitions to bounded SIDs, i.e. SIDs that are
+		 * guaranteed to only be allowed a subset of the permissions
+		 * of the current SID.
 		 */
-		if (nnp)
-			return -EPERM;
-		else
-			return -EACCES;
+		rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
+		if (!rc)
+			return 0;
 	}
-	return 0;
+
+	/*
+	 * On failure, preserve the errno values for NNP vs nosuid.
+	 * NNP:  Operation not permitted for caller.
+	 * nosuid:  Permission denied to file.
+	 */
+	if (nnp)
+		return -EPERM;
+	return -EACCES;
 }
 
 static int selinux_bprm_set_creds(struct linux_binprm *bprm)
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index b9fe343..7fde56d 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = {
 	    "getattr", "setexec", "setfscreate", "noatsecure", "siginh",
 	    "setrlimit", "rlimitinh", "dyntransition", "setcurrent",
 	    "execmem", "execstack", "execheap", "setkeycreate",
-	    "setsockcreate", "getrlimit", NULL } },
+	    "setsockcreate", "getrlimit", "nnp_transition", NULL } },
 	{ "system",
 	  { "ipc_info", "syslog_read", "syslog_mod",
 	    "syslog_console", "module_request", "module_load", NULL } },
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index e91f08c..88efb1b 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -73,6 +73,7 @@ enum {
 	POLICYDB_CAPABILITY_EXTSOCKCLASS,
 	POLICYDB_CAPABILITY_ALWAYSNETWORK,
 	POLICYDB_CAPABILITY_CGROUPSECLABEL,
+	POLICYDB_CAPABILITY_NNPTRANSITION,
 	__POLICYDB_CAPABILITY_MAX
 };
 #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
@@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
 extern int selinux_policycap_extsockclass;
 extern int selinux_policycap_alwaysnetwork;
 extern int selinux_policycap_cgroupseclabel;
+extern int selinux_policycap_nnptransition;
 
 /*
  * type_datum properties
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 2f02fa6..2faf47a 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -76,7 +76,8 @@ char *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
 	"open_perms",
 	"extended_socket_class",
 	"always_check_network",
-	"cgroup_seclabel"
+	"cgroup_seclabel",
+	"nnp_transition"
 };
 
 int selinux_policycap_netpeer;
@@ -84,6 +85,7 @@ int selinux_policycap_openperm;
 int selinux_policycap_extsockclass;
 int selinux_policycap_alwaysnetwork;
 int selinux_policycap_cgroupseclabel;
+int selinux_policycap_nnptransition;
 
 static DEFINE_RWLOCK(policy_rwlock);
 
@@ -2009,6 +2011,9 @@ static void security_load_policycaps(void)
 	selinux_policycap_cgroupseclabel =
 		ebitmap_get_bit(&policydb.policycaps,
 				POLICYDB_CAPABILITY_CGROUPSECLABEL);
+	selinux_policycap_nnptransition =
+		ebitmap_get_bit(&policydb.policycaps,
+				POLICYDB_CAPABILITY_NNPTRANSITION);
 
 	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++)
 		pr_info("SELinux:  policy capability %s=%d\n",
-- 
2.9.4

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> As systemd ramps up enabling NoNewPrivileges (either explicitly in
> service unit files or as a side effect of other security-related
> settings in service unit files), we're increasingly running afoul of
> its interactions with SELinux.
> 
> The end result is bad for the security of both SELinux-disabled and
> SELinux-enabled systems.  Packagers have to turn off these
> options in the unit files to preserve SELinux domain
> transitions.  For
> users who choose to disable SELinux, this means that they miss out on
> at least having the systemd-supported protections.  For users who
> keep
> SELinux enabled, they may still be missing out on some protections
> because it isn't necessarily guaranteed that the SELinux policy for
> that service provides the same protections in all cases.
> 
> Our options seem to be:
> 
> 1) Just keep on the way we are now, i.e. packagers have to remove
> default protection settings from upstream package unit files in order
> to have them work with SELinux (and not just NoNewPrivileges=
> itself; increasingly systemd is enabling NNP as a side effect of
> other
> unit file options, even seemingly unrelated ones like
> PrivateDevices).
> SELinux-disabled users lose entirely, SELinux-enabled users may lose
> (depending on whether SELinux policy provides equivalent or
> better guarantees).
> 
> 2) Change systemd to automatically disable NNP on SELinux-enabled
> systems.  Unit files can be left unmodified from upstream.  SELinux-
> disabled users win.  SELinux-enabled users may lose.
> 
> 3) Try to use typebounds, since we allow bounded transitions under
> NNP.
> Unit files can be left unmodified from upstream. SELinux-disabled
> users
> win.  SELinux-enabled users get to benefit from systemd-provided
> protections.  However, this option is impractical to implement in
> policy
> currently, since typebounds requires us to ensure that each domain is
> allowed everything all of its descendant domains are allowed, and
> this
> has to be repeated for the entire chain of domain transitions.  There
> is
> no way to clone all allow rules from children to the parent in policy
> currently, and it is doubtful that doing so would be desirable even
> if
> it were practical, as it requires leaking permissions to objects and
> operations into parent domains that could weaken their own security
> in
> order to allow them to the children (e.g. if a child requires execmem
> permission, then so does the parent; if a child requires read to a
> symbolic
> link or temporary file that it can write, then so does the parent,
> ...).
> 
> 4) Decouple NNP from SELinux transitions, so that we don't have to
> make a choice between them. Introduce a new policy capability that
> causes the ability to transition under NNP to be based on a new
> permission
> check between the old and new contexts rather than
> typebounds.  Domain
> transitions can then be allowed in policy without requiring the
> parent
> to be a strict superset of all of its children.  The rationale for
> this
> divergence from NNP behavior for capabilities is that SELinux
> permissions
> are substantially broader than just capabilities (they express a full
> access matrix, not just privileges) and can only be used to further
> restrict capabilities, not grant them beyond what is already
> permitted.
> Unit files can be left unmodified from upstream.  SELinux-disabled
> users
> win.  SELinux-enabled users can benefit from systemd-provided
> protections
> and policy won't need to radically change.
> 
> This change takes the last approach above, as it seems to be the
> best option.
> 
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
>  security/selinux/hooks.c            | 41 ++++++++++++++++++++++++---
> ----------
>  security/selinux/include/classmap.h |  2 +-
>  security/selinux/include/security.h |  2 ++
>  security/selinux/ss/services.c      |  7 ++++++-
>  4 files changed, 36 insertions(+), 16 deletions(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3a06afb..f0c11c2 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct
> linux_binprm *bprm,
>  		return 0; /* No change in credentials */
>  
>  	/*
> -	 * The only transitions we permit under NNP or nosuid
> -	 * are transitions to bounded SIDs, i.e. SIDs that are
> -	 * guaranteed to only be allowed a subset of the permissions
> -	 * of the current SID.
> +	 * If the policy enables the nnp_transition policy
> capability,
> +	 * then we permit transitions under NNP or nosuid if the
> +	 * policy explicitly allows nnp_transition permission
> between
> +	 * the old and new contexts.
>  	 */
> -	rc = security_bounded_transition(old_tsec->sid, new_tsec-
> >sid);
> -	if (rc) {
> +	if (selinux_policycap_nnptransition) {
> +		rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> +				  SECCLASS_PROCESS,
> +				  PROCESS__NNP_TRANSITION, NULL);
> +		if (!rc)
> +			return 0;
> +	} else {
>  		/*
> -		 * On failure, preserve the errno values for NNP vs
> nosuid.
> -		 * NNP:  Operation not permitted for caller.
> -		 * nosuid:  Permission denied to file.
> +		 * Otherwise, the only transitions we permit under
> NNP or nosuid
> +		 * are transitions to bounded SIDs, i.e. SIDs that
> are
> +		 * guaranteed to only be allowed a subset of the
> permissions
> +		 * of the current SID.
>  		 */
> -		if (nnp)
> -			return -EPERM;
> -		else
> -			return -EACCES;
> +		rc = security_bounded_transition(old_tsec->sid,
> new_tsec->sid);
> +		if (!rc)
> +			return 0;

NB: As currently written, this logic means that if you enable the new
policy capability, the only way to allow a transition under NNP is by
allowing nnp_transition permission between the old and new domains. The
alternative would be to fall back to checking for a bounded SID if
nnp_transition permission is not allowed. The former approach has the
advantage of being simpler (only a single check with a single audit
message), but means that you can't mix usage of bounded SIDs and
nnp_transition permission as a means of allowing a transitions under
NNP within the same policy.  The latter approach provides more
flexibility / compatibility but will end up producing two audit
messages in the case where the transition is denied by both checks: an
AVC message for the permission denial and a SELINUX_ERR message for the
security_bounded_transition failure, which might be confusing to users
(but probably not; they'll likely just feed the AVC through audit2allow
and be done with it).  Thoughts?

>  	}
> -	return 0;
> +
> +	/*
> +	 * On failure, preserve the errno values for NNP vs nosuid.
> +	 * NNP:  Operation not permitted for caller.
> +	 * nosuid:  Permission denied to file.
> +	 */
> +	if (nnp)
> +		return -EPERM;
> +	return -EACCES;
>  }
>  
>  static int selinux_bprm_set_creds(struct linux_binprm *bprm)
> diff --git a/security/selinux/include/classmap.h
> b/security/selinux/include/classmap.h
> index b9fe343..7fde56d 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = {
>  	    "getattr", "setexec", "setfscreate", "noatsecure",
> "siginh",
>  	    "setrlimit", "rlimitinh", "dyntransition", "setcurrent",
>  	    "execmem", "execstack", "execheap", "setkeycreate",
> -	    "setsockcreate", "getrlimit", NULL } },
> +	    "setsockcreate", "getrlimit", "nnp_transition", NULL }
> },
>  	{ "system",
>  	  { "ipc_info", "syslog_read", "syslog_mod",
>  	    "syslog_console", "module_request", "module_load", NULL
> } },
> diff --git a/security/selinux/include/security.h
> b/security/selinux/include/security.h
> index e91f08c..88efb1b 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -73,6 +73,7 @@ enum {
>  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
>  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> +	POLICYDB_CAPABILITY_NNPTRANSITION,
>  	__POLICYDB_CAPABILITY_MAX
>  };
>  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
> @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
>  extern int selinux_policycap_extsockclass;
>  extern int selinux_policycap_alwaysnetwork;
>  extern int selinux_policycap_cgroupseclabel;
> +extern int selinux_policycap_nnptransition;
>  
>  /*
>   * type_datum properties
> diff --git a/security/selinux/ss/services.c
> b/security/selinux/ss/services.c
> index 2f02fa6..2faf47a 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -76,7 +76,8 @@ char
> *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
>  	"open_perms",
>  	"extended_socket_class",
>  	"always_check_network",
> -	"cgroup_seclabel"
> +	"cgroup_seclabel",
> +	"nnp_transition"
>  };
>  
>  int selinux_policycap_netpeer;
> @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
>  int selinux_policycap_extsockclass;
>  int selinux_policycap_alwaysnetwork;
>  int selinux_policycap_cgroupseclabel;
> +int selinux_policycap_nnptransition;
>  
>  static DEFINE_RWLOCK(policy_rwlock);
>  
> @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void)
>  	selinux_policycap_cgroupseclabel =
>  		ebitmap_get_bit(&policydb.policycaps,
>  				POLICYDB_CAPABILITY_CGROUPSECLABEL);
> +	selinux_policycap_nnptransition =
> +		ebitmap_get_bit(&policydb.policycaps,
> +				POLICYDB_CAPABILITY_NNPTRANSITION);
>  
>  	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++)
>  		pr_info("SELinux:  policy capability %s=%d\n",

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 11001 bytes --]

On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote:
> On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > As systemd ramps up enabling NoNewPrivileges (either explicitly in
> > service unit files or as a side effect of other security-related
> > settings in service unit files), we're increasingly running afoul of
> > its interactions with SELinux.
> > 
> > The end result is bad for the security of both SELinux-disabled and
> > SELinux-enabled systems.  Packagers have to turn off these
> > options in the unit files to preserve SELinux domain
> > transitions.  For
> > users who choose to disable SELinux, this means that they miss out on
> > at least having the systemd-supported protections.  For users who
> > keep
> > SELinux enabled, they may still be missing out on some protections
> > because it isn't necessarily guaranteed that the SELinux policy for
> > that service provides the same protections in all cases.
> > 
> > Our options seem to be:
> > 
> > 1) Just keep on the way we are now, i.e. packagers have to remove
> > default protection settings from upstream package unit files in order
> > to have them work with SELinux (and not just NoNewPrivileges=
> > itself; increasingly systemd is enabling NNP as a side effect of
> > other
> > unit file options, even seemingly unrelated ones like
> > PrivateDevices).
> > SELinux-disabled users lose entirely, SELinux-enabled users may lose
> > (depending on whether SELinux policy provides equivalent or
> > better guarantees).
> > 
> > 2) Change systemd to automatically disable NNP on SELinux-enabled
> > systems.  Unit files can be left unmodified from upstream.  SELinux-
> > disabled users win.  SELinux-enabled users may lose.
> > 
> > 3) Try to use typebounds, since we allow bounded transitions under
> > NNP.
> > Unit files can be left unmodified from upstream. SELinux-disabled
> > users
> > win.  SELinux-enabled users get to benefit from systemd-provided
> > protections.  However, this option is impractical to implement in
> > policy
> > currently, since typebounds requires us to ensure that each domain is
> > allowed everything all of its descendant domains are allowed, and
> > this
> > has to be repeated for the entire chain of domain transitions.  There
> > is
> > no way to clone all allow rules from children to the parent in policy
> > currently, and it is doubtful that doing so would be desirable even
> > if
> > it were practical, as it requires leaking permissions to objects and
> > operations into parent domains that could weaken their own security
> > in
> > order to allow them to the children (e.g. if a child requires execmem
> > permission, then so does the parent; if a child requires read to a
> > symbolic
> > link or temporary file that it can write, then so does the parent,
> > ...).
> > 
> > 4) Decouple NNP from SELinux transitions, so that we don't have to
> > make a choice between them. Introduce a new policy capability that
> > causes the ability to transition under NNP to be based on a new
> > permission
> > check between the old and new contexts rather than
> > typebounds.  Domain
> > transitions can then be allowed in policy without requiring the
> > parent
> > to be a strict superset of all of its children.  The rationale for
> > this
> > divergence from NNP behavior for capabilities is that SELinux
> > permissions
> > are substantially broader than just capabilities (they express a full
> > access matrix, not just privileges) and can only be used to further
> > restrict capabilities, not grant them beyond what is already
> > permitted.
> > Unit files can be left unmodified from upstream.  SELinux-disabled
> > users
> > win.  SELinux-enabled users can benefit from systemd-provided
> > protections
> > and policy won't need to radically change.
> > 
> > This change takes the last approach above, as it seems to be the
> > best option.
> > 
> > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > ---
> >  security/selinux/hooks.c            | 41 ++++++++++++++++++++++++---
> > ----------
> >  security/selinux/include/classmap.h |  2 +-
> >  security/selinux/include/security.h |  2 ++
> >  security/selinux/ss/services.c      |  7 ++++++-
> >  4 files changed, 36 insertions(+), 16 deletions(-)
> > 
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 3a06afb..f0c11c2 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct
> > linux_binprm *bprm,
> >  		return 0; /* No change in credentials */
> >  
> >  	/*
> > -	 * The only transitions we permit under NNP or nosuid
> > -	 * are transitions to bounded SIDs, i.e. SIDs that are
> > -	 * guaranteed to only be allowed a subset of the permissions
> > -	 * of the current SID.
> > +	 * If the policy enables the nnp_transition policy
> > capability,
> > +	 * then we permit transitions under NNP or nosuid if the
> > +	 * policy explicitly allows nnp_transition permission
> > between
> > +	 * the old and new contexts.
> >  	 */
> > -	rc = security_bounded_transition(old_tsec->sid, new_tsec-
> > >sid);
> > -	if (rc) {
> > +	if (selinux_policycap_nnptransition) {
> > +		rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> > +				  SECCLASS_PROCESS,
> > +				  PROCESS__NNP_TRANSITION, NULL);
> > +		if (!rc)
> > +			return 0;
> > +	} else {
> >  		/*
> > -		 * On failure, preserve the errno values for NNP vs
> > nosuid.
> > -		 * NNP:  Operation not permitted for caller.
> > -		 * nosuid:  Permission denied to file.
> > +		 * Otherwise, the only transitions we permit under
> > NNP or nosuid
> > +		 * are transitions to bounded SIDs, i.e. SIDs that
> > are
> > +		 * guaranteed to only be allowed a subset of the
> > permissions
> > +		 * of the current SID.
> >  		 */
> > -		if (nnp)
> > -			return -EPERM;
> > -		else
> > -			return -EACCES;
> > +		rc = security_bounded_transition(old_tsec->sid,
> > new_tsec->sid);
> > +		if (!rc)
> > +			return 0;
> 
> NB: As currently written, this logic means that if you enable the new
> policy capability, the only way to allow a transition under NNP is by
> allowing nnp_transition permission between the old and new domains. The
> alternative would be to fall back to checking for a bounded SID if
> nnp_transition permission is not allowed. The former approach has the
> advantage of being simpler (only a single check with a single audit
> message), but means that you can't mix usage of bounded SIDs and
> nnp_transition permission as a means of allowing a transitions under
> NNP within the same policy.  The latter approach provides more
> flexibility / compatibility but will end up producing two audit
> messages in the case where the transition is denied by both checks: an
> AVC message for the permission denial and a SELINUX_ERR message for the
> security_bounded_transition failure, which might be confusing to users
> (but probably not; they'll likely just feed the AVC through audit2allow
> and be done with it).  Thoughts?

I think the current implementation is fine if i understand correctly:

1. With the policy capability disabled the behavior doesnt change, so if you dont want the current behavior (type_bounds) then just to enable the polcap
2. If you enable the policy capability then you decided to leverage nnp_transition instead of the current behavior

Theres plenty flexibility with this approach i would argue

> 
> >  	}
> > -	return 0;
> > +
> > +	/*
> > +	 * On failure, preserve the errno values for NNP vs nosuid.
> > +	 * NNP:  Operation not permitted for caller.
> > +	 * nosuid:  Permission denied to file.
> > +	 */
> > +	if (nnp)
> > +		return -EPERM;
> > +	return -EACCES;
> >  }
> >  
> >  static int selinux_bprm_set_creds(struct linux_binprm *bprm)
> > diff --git a/security/selinux/include/classmap.h
> > b/security/selinux/include/classmap.h
> > index b9fe343..7fde56d 100644
> > --- a/security/selinux/include/classmap.h
> > +++ b/security/selinux/include/classmap.h
> > @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = {
> >  	    "getattr", "setexec", "setfscreate", "noatsecure",
> > "siginh",
> >  	    "setrlimit", "rlimitinh", "dyntransition", "setcurrent",
> >  	    "execmem", "execstack", "execheap", "setkeycreate",
> > -	    "setsockcreate", "getrlimit", NULL } },
> > +	    "setsockcreate", "getrlimit", "nnp_transition", NULL }
> > },
> >  	{ "system",
> >  	  { "ipc_info", "syslog_read", "syslog_mod",
> >  	    "syslog_console", "module_request", "module_load", NULL
> > } },
> > diff --git a/security/selinux/include/security.h
> > b/security/selinux/include/security.h
> > index e91f08c..88efb1b 100644
> > --- a/security/selinux/include/security.h
> > +++ b/security/selinux/include/security.h
> > @@ -73,6 +73,7 @@ enum {
> >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> >  	__POLICYDB_CAPABILITY_MAX
> >  };
> >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
> > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> >  extern int selinux_policycap_extsockclass;
> >  extern int selinux_policycap_alwaysnetwork;
> >  extern int selinux_policycap_cgroupseclabel;
> > +extern int selinux_policycap_nnptransition;
> >  
> >  /*
> >   * type_datum properties
> > diff --git a/security/selinux/ss/services.c
> > b/security/selinux/ss/services.c
> > index 2f02fa6..2faf47a 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -76,7 +76,8 @@ char
> > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> >  	"open_perms",
> >  	"extended_socket_class",
> >  	"always_check_network",
> > -	"cgroup_seclabel"
> > +	"cgroup_seclabel",
> > +	"nnp_transition"
> >  };
> >  
> >  int selinux_policycap_netpeer;
> > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> >  int selinux_policycap_extsockclass;
> >  int selinux_policycap_alwaysnetwork;
> >  int selinux_policycap_cgroupseclabel;
> > +int selinux_policycap_nnptransition;
> >  
> >  static DEFINE_RWLOCK(policy_rwlock);
> >  
> > @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void)
> >  	selinux_policycap_cgroupseclabel =
> >  		ebitmap_get_bit(&policydb.policycaps,
> >  				POLICYDB_CAPABILITY_CGROUPSECLABEL);
> > +	selinux_policycap_nnptransition =
> > +		ebitmap_get_bit(&policydb.policycaps,
> > +				POLICYDB_CAPABILITY_NNPTRANSITION);
> >  
> >  	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++)
> >  		pr_info("SELinux:  policy capability %s=%d\n",

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 11939 bytes --]

On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote:
> > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > As systemd ramps up enabling NoNewPrivileges (either explicitly in
> > > service unit files or as a side effect of other security-related
> > > settings in service unit files), we're increasingly running afoul of
> > > its interactions with SELinux.
> > > 
> > > The end result is bad for the security of both SELinux-disabled and
> > > SELinux-enabled systems.  Packagers have to turn off these
> > > options in the unit files to preserve SELinux domain
> > > transitions.  For
> > > users who choose to disable SELinux, this means that they miss out on
> > > at least having the systemd-supported protections.  For users who
> > > keep
> > > SELinux enabled, they may still be missing out on some protections
> > > because it isn't necessarily guaranteed that the SELinux policy for
> > > that service provides the same protections in all cases.
> > > 
> > > Our options seem to be:
> > > 
> > > 1) Just keep on the way we are now, i.e. packagers have to remove
> > > default protection settings from upstream package unit files in order
> > > to have them work with SELinux (and not just NoNewPrivileges=
> > > itself; increasingly systemd is enabling NNP as a side effect of
> > > other
> > > unit file options, even seemingly unrelated ones like
> > > PrivateDevices).
> > > SELinux-disabled users lose entirely, SELinux-enabled users may lose
> > > (depending on whether SELinux policy provides equivalent or
> > > better guarantees).
> > > 
> > > 2) Change systemd to automatically disable NNP on SELinux-enabled
> > > systems.  Unit files can be left unmodified from upstream.  SELinux-
> > > disabled users win.  SELinux-enabled users may lose.
> > > 
> > > 3) Try to use typebounds, since we allow bounded transitions under
> > > NNP.
> > > Unit files can be left unmodified from upstream. SELinux-disabled
> > > users
> > > win.  SELinux-enabled users get to benefit from systemd-provided
> > > protections.  However, this option is impractical to implement in
> > > policy
> > > currently, since typebounds requires us to ensure that each domain is
> > > allowed everything all of its descendant domains are allowed, and
> > > this
> > > has to be repeated for the entire chain of domain transitions.  There
> > > is
> > > no way to clone all allow rules from children to the parent in policy
> > > currently, and it is doubtful that doing so would be desirable even
> > > if
> > > it were practical, as it requires leaking permissions to objects and
> > > operations into parent domains that could weaken their own security
> > > in
> > > order to allow them to the children (e.g. if a child requires execmem
> > > permission, then so does the parent; if a child requires read to a
> > > symbolic
> > > link or temporary file that it can write, then so does the parent,
> > > ...).
> > > 
> > > 4) Decouple NNP from SELinux transitions, so that we don't have to
> > > make a choice between them. Introduce a new policy capability that
> > > causes the ability to transition under NNP to be based on a new
> > > permission
> > > check between the old and new contexts rather than
> > > typebounds.  Domain
> > > transitions can then be allowed in policy without requiring the
> > > parent
> > > to be a strict superset of all of its children.  The rationale for
> > > this
> > > divergence from NNP behavior for capabilities is that SELinux
> > > permissions
> > > are substantially broader than just capabilities (they express a full
> > > access matrix, not just privileges) and can only be used to further
> > > restrict capabilities, not grant them beyond what is already
> > > permitted.
> > > Unit files can be left unmodified from upstream.  SELinux-disabled
> > > users
> > > win.  SELinux-enabled users can benefit from systemd-provided
> > > protections
> > > and policy won't need to radically change.
> > > 
> > > This change takes the last approach above, as it seems to be the
> > > best option.
> > > 
> > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > ---
> > >  security/selinux/hooks.c            | 41 ++++++++++++++++++++++++---
> > > ----------
> > >  security/selinux/include/classmap.h |  2 +-
> > >  security/selinux/include/security.h |  2 ++
> > >  security/selinux/ss/services.c      |  7 ++++++-
> > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > > index 3a06afb..f0c11c2 100644
> > > --- a/security/selinux/hooks.c
> > > +++ b/security/selinux/hooks.c
> > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct
> > > linux_binprm *bprm,
> > >  		return 0; /* No change in credentials */
> > >  
> > >  	/*
> > > -	 * The only transitions we permit under NNP or nosuid
> > > -	 * are transitions to bounded SIDs, i.e. SIDs that are
> > > -	 * guaranteed to only be allowed a subset of the permissions
> > > -	 * of the current SID.
> > > +	 * If the policy enables the nnp_transition policy
> > > capability,
> > > +	 * then we permit transitions under NNP or nosuid if the
> > > +	 * policy explicitly allows nnp_transition permission
> > > between
> > > +	 * the old and new contexts.
> > >  	 */
> > > -	rc = security_bounded_transition(old_tsec->sid, new_tsec-
> > > >sid);
> > > -	if (rc) {
> > > +	if (selinux_policycap_nnptransition) {
> > > +		rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> > > +				  SECCLASS_PROCESS,
> > > +				  PROCESS__NNP_TRANSITION, NULL);
> > > +		if (!rc)
> > > +			return 0;
> > > +	} else {
> > >  		/*
> > > -		 * On failure, preserve the errno values for NNP vs
> > > nosuid.
> > > -		 * NNP:  Operation not permitted for caller.
> > > -		 * nosuid:  Permission denied to file.
> > > +		 * Otherwise, the only transitions we permit under
> > > NNP or nosuid
> > > +		 * are transitions to bounded SIDs, i.e. SIDs that
> > > are
> > > +		 * guaranteed to only be allowed a subset of the
> > > permissions
> > > +		 * of the current SID.
> > >  		 */
> > > -		if (nnp)
> > > -			return -EPERM;
> > > -		else
> > > -			return -EACCES;
> > > +		rc = security_bounded_transition(old_tsec->sid,
> > > new_tsec->sid);
> > > +		if (!rc)
> > > +			return 0;
> > 
> > NB: As currently written, this logic means that if you enable the new
> > policy capability, the only way to allow a transition under NNP is by
> > allowing nnp_transition permission between the old and new domains. The
> > alternative would be to fall back to checking for a bounded SID if
> > nnp_transition permission is not allowed. The former approach has the
> > advantage of being simpler (only a single check with a single audit
> > message), but means that you can't mix usage of bounded SIDs and
> > nnp_transition permission as a means of allowing a transitions under
> > NNP within the same policy.  The latter approach provides more
> > flexibility / compatibility but will end up producing two audit
> > messages in the case where the transition is denied by both checks: an
> > AVC message for the permission denial and a SELINUX_ERR message for the
> > security_bounded_transition failure, which might be confusing to users
> > (but probably not; they'll likely just feed the AVC through audit2allow
> > and be done with it).  Thoughts?
> 
> I think the current implementation is fine if i understand correctly:
> 
> 1. With the policy capability disabled the behavior doesnt change, so if you dont want the current behavior (type_bounds) then just to enable the polcap
> 2. If you enable the policy capability then you decided to leverage nnp_transition instead of the current behavior
> 
> Theres plenty flexibility with this approach i would argue

Hmm. that came out wrong:

1. without nnptransition polcap: everything stays the same
2. with nnptransition polcap: you choose nnp_transition over current type_bounds behavior

> 
> > 
> > >  	}
> > > -	return 0;
> > > +
> > > +	/*
> > > +	 * On failure, preserve the errno values for NNP vs nosuid.
> > > +	 * NNP:  Operation not permitted for caller.
> > > +	 * nosuid:  Permission denied to file.
> > > +	 */
> > > +	if (nnp)
> > > +		return -EPERM;
> > > +	return -EACCES;
> > >  }
> > >  
> > >  static int selinux_bprm_set_creds(struct linux_binprm *bprm)
> > > diff --git a/security/selinux/include/classmap.h
> > > b/security/selinux/include/classmap.h
> > > index b9fe343..7fde56d 100644
> > > --- a/security/selinux/include/classmap.h
> > > +++ b/security/selinux/include/classmap.h
> > > @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[] = {
> > >  	    "getattr", "setexec", "setfscreate", "noatsecure",
> > > "siginh",
> > >  	    "setrlimit", "rlimitinh", "dyntransition", "setcurrent",
> > >  	    "execmem", "execstack", "execheap", "setkeycreate",
> > > -	    "setsockcreate", "getrlimit", NULL } },
> > > +	    "setsockcreate", "getrlimit", "nnp_transition", NULL }
> > > },
> > >  	{ "system",
> > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > >  	    "syslog_console", "module_request", "module_load", NULL
> > > } },
> > > diff --git a/security/selinux/include/security.h
> > > b/security/selinux/include/security.h
> > > index e91f08c..88efb1b 100644
> > > --- a/security/selinux/include/security.h
> > > +++ b/security/selinux/include/security.h
> > > @@ -73,6 +73,7 @@ enum {
> > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > >  	__POLICYDB_CAPABILITY_MAX
> > >  };
> > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
> > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > >  extern int selinux_policycap_extsockclass;
> > >  extern int selinux_policycap_alwaysnetwork;
> > >  extern int selinux_policycap_cgroupseclabel;
> > > +extern int selinux_policycap_nnptransition;
> > >  
> > >  /*
> > >   * type_datum properties
> > > diff --git a/security/selinux/ss/services.c
> > > b/security/selinux/ss/services.c
> > > index 2f02fa6..2faf47a 100644
> > > --- a/security/selinux/ss/services.c
> > > +++ b/security/selinux/ss/services.c
> > > @@ -76,7 +76,8 @@ char
> > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > >  	"open_perms",
> > >  	"extended_socket_class",
> > >  	"always_check_network",
> > > -	"cgroup_seclabel"
> > > +	"cgroup_seclabel",
> > > +	"nnp_transition"
> > >  };
> > >  
> > >  int selinux_policycap_netpeer;
> > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > >  int selinux_policycap_extsockclass;
> > >  int selinux_policycap_alwaysnetwork;
> > >  int selinux_policycap_cgroupseclabel;
> > > +int selinux_policycap_nnptransition;
> > >  
> > >  static DEFINE_RWLOCK(policy_rwlock);
> > >  
> > > @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void)
> > >  	selinux_policycap_cgroupseclabel =
> > >  		ebitmap_get_bit(&policydb.policycaps,
> > >  				POLICYDB_CAPABILITY_CGROUPSECLABEL);
> > > +	selinux_policycap_nnptransition =
> > > +		ebitmap_get_bit(&policydb.policycaps,
> > > +				POLICYDB_CAPABILITY_NNPTRANSITION);
> > >  
> > >  	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++)
> > >  		pr_info("SELinux:  policy capability %s=%d\n",
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote:
> > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > As systemd ramps up enabling NoNewPrivileges (either explicitly
> > > > in
> > > > service unit files or as a side effect of other security-
> > > > related
> > > > settings in service unit files), we're increasingly running
> > > > afoul of
> > > > its interactions with SELinux.
> > > > 
> > > > The end result is bad for the security of both SELinux-disabled 
> > > > and
> > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > options in the unit files to preserve SELinux domain
> > > > transitions.  For
> > > > users who choose to disable SELinux, this means that they miss
> > > > out on
> > > > at least having the systemd-supported protections.  For users
> > > > who
> > > > keep
> > > > SELinux enabled, they may still be missing out on some
> > > > protections
> > > > because it isn't necessarily guaranteed that the SELinux policy
> > > > for
> > > > that service provides the same protections in all cases.
> > > > 
> > > > Our options seem to be:
> > > > 
> > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > remove
> > > > default protection settings from upstream package unit files in
> > > > order
> > > > to have them work with SELinux (and not just NoNewPrivileges=
> > > > itself; increasingly systemd is enabling NNP as a side effect
> > > > of
> > > > other
> > > > unit file options, even seemingly unrelated ones like
> > > > PrivateDevices).
> > > > SELinux-disabled users lose entirely, SELinux-enabled users may
> > > > lose
> > > > (depending on whether SELinux policy provides equivalent or
> > > > better guarantees).
> > > > 
> > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > enabled
> > > > systems.  Unit files can be left unmodified from
> > > > upstream.  SELinux-
> > > > disabled users win.  SELinux-enabled users may lose.
> > > > 
> > > > 3) Try to use typebounds, since we allow bounded transitions
> > > > under
> > > > NNP.
> > > > Unit files can be left unmodified from upstream. SELinux-
> > > > disabled
> > > > users
> > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > provided
> > > > protections.  However, this option is impractical to implement
> > > > in
> > > > policy
> > > > currently, since typebounds requires us to ensure that each
> > > > domain is
> > > > allowed everything all of its descendant domains are allowed,
> > > > and
> > > > this
> > > > has to be repeated for the entire chain of domain
> > > > transitions.  There
> > > > is
> > > > no way to clone all allow rules from children to the parent in
> > > > policy
> > > > currently, and it is doubtful that doing so would be desirable
> > > > even
> > > > if
> > > > it were practical, as it requires leaking permissions to
> > > > objects and
> > > > operations into parent domains that could weaken their own
> > > > security
> > > > in
> > > > order to allow them to the children (e.g. if a child requires
> > > > execmem
> > > > permission, then so does the parent; if a child requires read
> > > > to a
> > > > symbolic
> > > > link or temporary file that it can write, then so does the
> > > > parent,
> > > > ...).
> > > > 
> > > > 4) Decouple NNP from SELinux transitions, so that we don't have
> > > > to
> > > > make a choice between them. Introduce a new policy capability
> > > > that
> > > > causes the ability to transition under NNP to be based on a new
> > > > permission
> > > > check between the old and new contexts rather than
> > > > typebounds.  Domain
> > > > transitions can then be allowed in policy without requiring the
> > > > parent
> > > > to be a strict superset of all of its children.  The rationale
> > > > for
> > > > this
> > > > divergence from NNP behavior for capabilities is that SELinux
> > > > permissions
> > > > are substantially broader than just capabilities (they express
> > > > a full
> > > > access matrix, not just privileges) and can only be used to
> > > > further
> > > > restrict capabilities, not grant them beyond what is already
> > > > permitted.
> > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > disabled
> > > > users
> > > > win.  SELinux-enabled users can benefit from systemd-provided
> > > > protections
> > > > and policy won't need to radically change.
> > > > 
> > > > This change takes the last approach above, as it seems to be
> > > > the
> > > > best option.
> > > > 
> > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > ---
> > > >  security/selinux/hooks.c            | 41
> > > > ++++++++++++++++++++++++---
> > > > ----------
> > > >  security/selinux/include/classmap.h |  2 +-
> > > >  security/selinux/include/security.h |  2 ++
> > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > 
> > > > diff --git a/security/selinux/hooks.c
> > > > b/security/selinux/hooks.c
> > > > index 3a06afb..f0c11c2 100644
> > > > --- a/security/selinux/hooks.c
> > > > +++ b/security/selinux/hooks.c
> > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > struct
> > > > linux_binprm *bprm,
> > > >  		return 0; /* No change in credentials */
> > > >  
> > > >  	/*
> > > > -	 * The only transitions we permit under NNP or nosuid
> > > > -	 * are transitions to bounded SIDs, i.e. SIDs that are
> > > > -	 * guaranteed to only be allowed a subset of the
> > > > permissions
> > > > -	 * of the current SID.
> > > > +	 * If the policy enables the nnp_transition policy
> > > > capability,
> > > > +	 * then we permit transitions under NNP or nosuid if
> > > > the
> > > > +	 * policy explicitly allows nnp_transition permission
> > > > between
> > > > +	 * the old and new contexts.
> > > >  	 */
> > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > new_tsec-
> > > > > sid);
> > > > 
> > > > -	if (rc) {
> > > > +	if (selinux_policycap_nnptransition) {
> > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > >sid,
> > > > +				  SECCLASS_PROCESS,
> > > > +				  PROCESS__NNP_TRANSITION,
> > > > NULL);
> > > > +		if (!rc)
> > > > +			return 0;
> > > > +	} else {
> > > >  		/*
> > > > -		 * On failure, preserve the errno values for
> > > > NNP vs
> > > > nosuid.
> > > > -		 * NNP:  Operation not permitted for caller.
> > > > -		 * nosuid:  Permission denied to file.
> > > > +		 * Otherwise, the only transitions we permit
> > > > under
> > > > NNP or nosuid
> > > > +		 * are transitions to bounded SIDs, i.e. SIDs
> > > > that
> > > > are
> > > > +		 * guaranteed to only be allowed a subset of
> > > > the
> > > > permissions
> > > > +		 * of the current SID.
> > > >  		 */
> > > > -		if (nnp)
> > > > -			return -EPERM;
> > > > -		else
> > > > -			return -EACCES;
> > > > +		rc = security_bounded_transition(old_tsec-
> > > > >sid,
> > > > new_tsec->sid);
> > > > +		if (!rc)
> > > > +			return 0;
> > > 
> > > NB: As currently written, this logic means that if you enable the
> > > new
> > > policy capability, the only way to allow a transition under NNP
> > > is by
> > > allowing nnp_transition permission between the old and new
> > > domains. The
> > > alternative would be to fall back to checking for a bounded SID
> > > if
> > > nnp_transition permission is not allowed. The former approach has
> > > the
> > > advantage of being simpler (only a single check with a single
> > > audit
> > > message), but means that you can't mix usage of bounded SIDs and
> > > nnp_transition permission as a means of allowing a transitions
> > > under
> > > NNP within the same policy.  The latter approach provides more
> > > flexibility / compatibility but will end up producing two audit
> > > messages in the case where the transition is denied by both
> > > checks: an
> > > AVC message for the permission denial and a SELINUX_ERR message
> > > for the
> > > security_bounded_transition failure, which might be confusing to
> > > users
> > > (but probably not; they'll likely just feed the AVC through
> > > audit2allow
> > > and be done with it).  Thoughts?
> > 
> > I think the current implementation is fine if i understand
> > correctly:
> > 
> > 1. With the policy capability disabled the behavior doesnt change,
> > so if you dont want the current behavior (type_bounds) then just to
> > enable the polcap
> > 2. If you enable the policy capability then you decided to leverage
> > nnp_transition instead of the current behavior
> > 
> > Theres plenty flexibility with this approach i would argue
> 
> Hmm. that came out wrong:
> 
> 1. without nnptransition polcap: everything stays the same
> 2. with nnptransition polcap: you choose nnp_transition over current
> type_bounds behavior

Yes, that's correct. It is somewhat limiting in that if you want to
leverage nnp_transition at all, you have to give up using typebounds
entirely for allowing NNP transitions.  So, let's say there is an
existing policy module that defines a typebounds in order to allow a
NNP transition, and then another policy module decides to enable the
policy capability and leverage nnp_transition permission to allow
another NNP transition that wouldn't work under typebounds.  The first
one will break under the former approach, while it would keep working
under the latter approach. Not sure if that's a real concern or just a
contrived one.  Let's say someone writes a third party policy module
using typebounds for this purpose on Fedora today, and then updates to
a new version of Fedora that enables the policy capability and
leverages nnp_transition in its policy to allow such transitions.  Now
that third party policy module will stop working (it would need to be
changed to allow nnp_transition explicitly).

> 
> > 
> > > 
> > > >  	}
> > > > -	return 0;
> > > > +
> > > > +	/*
> > > > +	 * On failure, preserve the errno values for NNP vs
> > > > nosuid.
> > > > +	 * NNP:  Operation not permitted for caller.
> > > > +	 * nosuid:  Permission denied to file.
> > > > +	 */
> > > > +	if (nnp)
> > > > +		return -EPERM;
> > > > +	return -EACCES;
> > > >  }
> > > >  
> > > >  static int selinux_bprm_set_creds(struct linux_binprm *bprm)
> > > > diff --git a/security/selinux/include/classmap.h
> > > > b/security/selinux/include/classmap.h
> > > > index b9fe343..7fde56d 100644
> > > > --- a/security/selinux/include/classmap.h
> > > > +++ b/security/selinux/include/classmap.h
> > > > @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[]
> > > > = {
> > > >  	    "getattr", "setexec", "setfscreate", "noatsecure",
> > > > "siginh",
> > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > "setcurrent",
> > > >  	    "execmem", "execstack", "execheap",
> > > > "setkeycreate",
> > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > +	    "setsockcreate", "getrlimit", "nnp_transition",
> > > > NULL }
> > > > },
> > > >  	{ "system",
> > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > >  	    "syslog_console", "module_request", "module_load",
> > > > NULL
> > > > } },
> > > > diff --git a/security/selinux/include/security.h
> > > > b/security/selinux/include/security.h
> > > > index e91f08c..88efb1b 100644
> > > > --- a/security/selinux/include/security.h
> > > > +++ b/security/selinux/include/security.h
> > > > @@ -73,6 +73,7 @@ enum {
> > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > >  	__POLICYDB_CAPABILITY_MAX
> > > >  };
> > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX -
> > > > 1)
> > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > >  extern int selinux_policycap_extsockclass;
> > > >  extern int selinux_policycap_alwaysnetwork;
> > > >  extern int selinux_policycap_cgroupseclabel;
> > > > +extern int selinux_policycap_nnptransition;
> > > >  
> > > >  /*
> > > >   * type_datum properties
> > > > diff --git a/security/selinux/ss/services.c
> > > > b/security/selinux/ss/services.c
> > > > index 2f02fa6..2faf47a 100644
> > > > --- a/security/selinux/ss/services.c
> > > > +++ b/security/selinux/ss/services.c
> > > > @@ -76,7 +76,8 @@ char
> > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > >  	"open_perms",
> > > >  	"extended_socket_class",
> > > >  	"always_check_network",
> > > > -	"cgroup_seclabel"
> > > > +	"cgroup_seclabel",
> > > > +	"nnp_transition"
> > > >  };
> > > >  
> > > >  int selinux_policycap_netpeer;
> > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > >  int selinux_policycap_extsockclass;
> > > >  int selinux_policycap_alwaysnetwork;
> > > >  int selinux_policycap_cgroupseclabel;
> > > > +int selinux_policycap_nnptransition;
> > > >  
> > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > >  
> > > > @@ -2009,6 +2011,9 @@ static void
> > > > security_load_policycaps(void)
> > > >  	selinux_policycap_cgroupseclabel =
> > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > >  				POLICYDB_CAPABILITY_CGROUPSECL
> > > > ABEL);
> > > > +	selinux_policycap_nnptransition =
> > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > +				POLICYDB_CAPABILITY_NNPTRANSIT
> > > > ION);
> > > >  
> > > >  	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names);
> > > > i++)
> > > >  		pr_info("SELinux:  policy capability %s=%d\n",
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6
> > B02
> > Dominick Grift
> 
> 
> 

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 15539 bytes --]

On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote:
> On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote:
> > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > > As systemd ramps up enabling NoNewPrivileges (either explicitly
> > > > > in
> > > > > service unit files or as a side effect of other security-
> > > > > related
> > > > > settings in service unit files), we're increasingly running
> > > > > afoul of
> > > > > its interactions with SELinux.
> > > > > 
> > > > > The end result is bad for the security of both SELinux-disabled 
> > > > > and
> > > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > > options in the unit files to preserve SELinux domain
> > > > > transitions.  For
> > > > > users who choose to disable SELinux, this means that they miss
> > > > > out on
> > > > > at least having the systemd-supported protections.  For users
> > > > > who
> > > > > keep
> > > > > SELinux enabled, they may still be missing out on some
> > > > > protections
> > > > > because it isn't necessarily guaranteed that the SELinux policy
> > > > > for
> > > > > that service provides the same protections in all cases.
> > > > > 
> > > > > Our options seem to be:
> > > > > 
> > > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > > remove
> > > > > default protection settings from upstream package unit files in
> > > > > order
> > > > > to have them work with SELinux (and not just NoNewPrivileges=
> > > > > itself; increasingly systemd is enabling NNP as a side effect
> > > > > of
> > > > > other
> > > > > unit file options, even seemingly unrelated ones like
> > > > > PrivateDevices).
> > > > > SELinux-disabled users lose entirely, SELinux-enabled users may
> > > > > lose
> > > > > (depending on whether SELinux policy provides equivalent or
> > > > > better guarantees).
> > > > > 
> > > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > > enabled
> > > > > systems.  Unit files can be left unmodified from
> > > > > upstream.  SELinux-
> > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > 
> > > > > 3) Try to use typebounds, since we allow bounded transitions
> > > > > under
> > > > > NNP.
> > > > > Unit files can be left unmodified from upstream. SELinux-
> > > > > disabled
> > > > > users
> > > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > > provided
> > > > > protections.  However, this option is impractical to implement
> > > > > in
> > > > > policy
> > > > > currently, since typebounds requires us to ensure that each
> > > > > domain is
> > > > > allowed everything all of its descendant domains are allowed,
> > > > > and
> > > > > this
> > > > > has to be repeated for the entire chain of domain
> > > > > transitions.  There
> > > > > is
> > > > > no way to clone all allow rules from children to the parent in
> > > > > policy
> > > > > currently, and it is doubtful that doing so would be desirable
> > > > > even
> > > > > if
> > > > > it were practical, as it requires leaking permissions to
> > > > > objects and
> > > > > operations into parent domains that could weaken their own
> > > > > security
> > > > > in
> > > > > order to allow them to the children (e.g. if a child requires
> > > > > execmem
> > > > > permission, then so does the parent; if a child requires read
> > > > > to a
> > > > > symbolic
> > > > > link or temporary file that it can write, then so does the
> > > > > parent,
> > > > > ...).
> > > > > 
> > > > > 4) Decouple NNP from SELinux transitions, so that we don't have
> > > > > to
> > > > > make a choice between them. Introduce a new policy capability
> > > > > that
> > > > > causes the ability to transition under NNP to be based on a new
> > > > > permission
> > > > > check between the old and new contexts rather than
> > > > > typebounds.  Domain
> > > > > transitions can then be allowed in policy without requiring the
> > > > > parent
> > > > > to be a strict superset of all of its children.  The rationale
> > > > > for
> > > > > this
> > > > > divergence from NNP behavior for capabilities is that SELinux
> > > > > permissions
> > > > > are substantially broader than just capabilities (they express
> > > > > a full
> > > > > access matrix, not just privileges) and can only be used to
> > > > > further
> > > > > restrict capabilities, not grant them beyond what is already
> > > > > permitted.
> > > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > > disabled
> > > > > users
> > > > > win.  SELinux-enabled users can benefit from systemd-provided
> > > > > protections
> > > > > and policy won't need to radically change.
> > > > > 
> > > > > This change takes the last approach above, as it seems to be
> > > > > the
> > > > > best option.
> > > > > 
> > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > ---
> > > > >  security/selinux/hooks.c            | 41
> > > > > ++++++++++++++++++++++++---
> > > > > ----------
> > > > >  security/selinux/include/classmap.h |  2 +-
> > > > >  security/selinux/include/security.h |  2 ++
> > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/security/selinux/hooks.c
> > > > > b/security/selinux/hooks.c
> > > > > index 3a06afb..f0c11c2 100644
> > > > > --- a/security/selinux/hooks.c
> > > > > +++ b/security/selinux/hooks.c
> > > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > > struct
> > > > > linux_binprm *bprm,
> > > > >  		return 0; /* No change in credentials */
> > > > >  
> > > > >  	/*
> > > > > -	 * The only transitions we permit under NNP or nosuid
> > > > > -	 * are transitions to bounded SIDs, i.e. SIDs that are
> > > > > -	 * guaranteed to only be allowed a subset of the
> > > > > permissions
> > > > > -	 * of the current SID.
> > > > > +	 * If the policy enables the nnp_transition policy
> > > > > capability,
> > > > > +	 * then we permit transitions under NNP or nosuid if
> > > > > the
> > > > > +	 * policy explicitly allows nnp_transition permission
> > > > > between
> > > > > +	 * the old and new contexts.
> > > > >  	 */
> > > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > > new_tsec-
> > > > > > sid);
> > > > > 
> > > > > -	if (rc) {
> > > > > +	if (selinux_policycap_nnptransition) {
> > > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > > >sid,
> > > > > +				  SECCLASS_PROCESS,
> > > > > +				  PROCESS__NNP_TRANSITION,
> > > > > NULL);
> > > > > +		if (!rc)
> > > > > +			return 0;
> > > > > +	} else {
> > > > >  		/*
> > > > > -		 * On failure, preserve the errno values for
> > > > > NNP vs
> > > > > nosuid.
> > > > > -		 * NNP:  Operation not permitted for caller.
> > > > > -		 * nosuid:  Permission denied to file.
> > > > > +		 * Otherwise, the only transitions we permit
> > > > > under
> > > > > NNP or nosuid
> > > > > +		 * are transitions to bounded SIDs, i.e. SIDs
> > > > > that
> > > > > are
> > > > > +		 * guaranteed to only be allowed a subset of
> > > > > the
> > > > > permissions
> > > > > +		 * of the current SID.
> > > > >  		 */
> > > > > -		if (nnp)
> > > > > -			return -EPERM;
> > > > > -		else
> > > > > -			return -EACCES;
> > > > > +		rc = security_bounded_transition(old_tsec-
> > > > > >sid,
> > > > > new_tsec->sid);
> > > > > +		if (!rc)
> > > > > +			return 0;
> > > > 
> > > > NB: As currently written, this logic means that if you enable the
> > > > new
> > > > policy capability, the only way to allow a transition under NNP
> > > > is by
> > > > allowing nnp_transition permission between the old and new
> > > > domains. The
> > > > alternative would be to fall back to checking for a bounded SID
> > > > if
> > > > nnp_transition permission is not allowed. The former approach has
> > > > the
> > > > advantage of being simpler (only a single check with a single
> > > > audit
> > > > message), but means that you can't mix usage of bounded SIDs and
> > > > nnp_transition permission as a means of allowing a transitions
> > > > under
> > > > NNP within the same policy.  The latter approach provides more
> > > > flexibility / compatibility but will end up producing two audit
> > > > messages in the case where the transition is denied by both
> > > > checks: an
> > > > AVC message for the permission denial and a SELINUX_ERR message
> > > > for the
> > > > security_bounded_transition failure, which might be confusing to
> > > > users
> > > > (but probably not; they'll likely just feed the AVC through
> > > > audit2allow
> > > > and be done with it).  Thoughts?
> > > 
> > > I think the current implementation is fine if i understand
> > > correctly:
> > > 
> > > 1. With the policy capability disabled the behavior doesnt change,
> > > so if you dont want the current behavior (type_bounds) then just to
> > > enable the polcap
> > > 2. If you enable the policy capability then you decided to leverage
> > > nnp_transition instead of the current behavior
> > > 
> > > Theres plenty flexibility with this approach i would argue
> > 
> > Hmm. that came out wrong:
> > 
> > 1. without nnptransition polcap: everything stays the same
> > 2. with nnptransition polcap: you choose nnp_transition over current
> > type_bounds behavior
> 
> Yes, that's correct. It is somewhat limiting in that if you want to
> leverage nnp_transition at all, you have to give up using typebounds
> entirely for allowing NNP transitions.  So, let's say there is an
> existing policy module that defines a typebounds in order to allow a
> NNP transition, and then another policy module decides to enable the
> policy capability and leverage nnp_transition permission to allow
> another NNP transition that wouldn't work under typebounds.  The first
> one will break under the former approach, while it would keep working
> under the latter approach. Not sure if that's a real concern or just a
> contrived one.  Let's say someone writes a third party policy module
> using typebounds for this purpose on Fedora today, and then updates to
> a new version of Fedora that enables the policy capability and
> leverages nnp_transition in its policy to allow such transitions.  Now
> that third party policy module will stop working (it would need to be
> changed to allow nnp_transition explicitly).

Would this affect the requirement of typebounds by for example mod_selinux? I think that apache module also requires typebounds but not for NNP AFAIK (that stuff predates it i believe)

I prefer this implementation if this implementation is reasonably possible. I dont believe that there are any third party modules that support NNP (its too un-usable and hard to write)

I wont be leveraging nnp_transition or type_bounds for NNP BTW. I will just contrinue removing the NNP= for systemd service units.

> 
> > 
> > > 
> > > > 
> > > > >  	}
> > > > > -	return 0;
> > > > > +
> > > > > +	/*
> > > > > +	 * On failure, preserve the errno values for NNP vs
> > > > > nosuid.
> > > > > +	 * NNP:  Operation not permitted for caller.
> > > > > +	 * nosuid:  Permission denied to file.
> > > > > +	 */
> > > > > +	if (nnp)
> > > > > +		return -EPERM;
> > > > > +	return -EACCES;
> > > > >  }
> > > > >  
> > > > >  static int selinux_bprm_set_creds(struct linux_binprm *bprm)
> > > > > diff --git a/security/selinux/include/classmap.h
> > > > > b/security/selinux/include/classmap.h
> > > > > index b9fe343..7fde56d 100644
> > > > > --- a/security/selinux/include/classmap.h
> > > > > +++ b/security/selinux/include/classmap.h
> > > > > @@ -47,7 +47,7 @@ struct security_class_mapping secclass_map[]
> > > > > = {
> > > > >  	    "getattr", "setexec", "setfscreate", "noatsecure",
> > > > > "siginh",
> > > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > > "setcurrent",
> > > > >  	    "execmem", "execstack", "execheap",
> > > > > "setkeycreate",
> > > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > > +	    "setsockcreate", "getrlimit", "nnp_transition",
> > > > > NULL }
> > > > > },
> > > > >  	{ "system",
> > > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > > >  	    "syslog_console", "module_request", "module_load",
> > > > > NULL
> > > > > } },
> > > > > diff --git a/security/selinux/include/security.h
> > > > > b/security/selinux/include/security.h
> > > > > index e91f08c..88efb1b 100644
> > > > > --- a/security/selinux/include/security.h
> > > > > +++ b/security/selinux/include/security.h
> > > > > @@ -73,6 +73,7 @@ enum {
> > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > >  };
> > > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX -
> > > > > 1)
> > > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > > >  extern int selinux_policycap_extsockclass;
> > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > +extern int selinux_policycap_nnptransition;
> > > > >  
> > > > >  /*
> > > > >   * type_datum properties
> > > > > diff --git a/security/selinux/ss/services.c
> > > > > b/security/selinux/ss/services.c
> > > > > index 2f02fa6..2faf47a 100644
> > > > > --- a/security/selinux/ss/services.c
> > > > > +++ b/security/selinux/ss/services.c
> > > > > @@ -76,7 +76,8 @@ char
> > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > > >  	"open_perms",
> > > > >  	"extended_socket_class",
> > > > >  	"always_check_network",
> > > > > -	"cgroup_seclabel"
> > > > > +	"cgroup_seclabel",
> > > > > +	"nnp_transition"
> > > > >  };
> > > > >  
> > > > >  int selinux_policycap_netpeer;
> > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > >  int selinux_policycap_extsockclass;
> > > > >  int selinux_policycap_alwaysnetwork;
> > > > >  int selinux_policycap_cgroupseclabel;
> > > > > +int selinux_policycap_nnptransition;
> > > > >  
> > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > >  
> > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > security_load_policycaps(void)
> > > > >  	selinux_policycap_cgroupseclabel =
> > > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > > >  				POLICYDB_CAPABILITY_CGROUPSECL
> > > > > ABEL);
> > > > > +	selinux_policycap_nnptransition =
> > > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > > +				POLICYDB_CAPABILITY_NNPTRANSIT
> > > > > ION);
> > > > >  
> > > > >  	for (i = 0; i < ARRAY_SIZE(selinux_policycap_names);
> > > > > i++)
> > > > >  		pr_info("SELinux:  policy capability %s=%d\n",
> > > 
> > > -- 
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6
> > > B02
> > > Dominick Grift
> > 
> > 
> > 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Paul Moore]

On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> As systemd ramps up enabling NoNewPrivileges (either explicitly in
> service unit files or as a side effect of other security-related
> settings in service unit files), we're increasingly running afoul of
> its interactions with SELinux...

We already talked about this in the other thread so I'll refrain from
repeating myself.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 3a06afb..f0c11c2 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct linux_binprm *bprm,
>                 return 0; /* No change in credentials */
>
>         /*
> -        * The only transitions we permit under NNP or nosuid
> -        * are transitions to bounded SIDs, i.e. SIDs that are
> -        * guaranteed to only be allowed a subset of the permissions
> -        * of the current SID.
> +        * If the policy enables the nnp_transition policy capability,
> +        * then we permit transitions under NNP or nosuid if the
> +        * policy explicitly allows nnp_transition permission between
> +        * the old and new contexts.
>          */
> -       rc = security_bounded_transition(old_tsec->sid, new_tsec->sid);
> -       if (rc) {
> +       if (selinux_policycap_nnptransition) {
> +               rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> +                                 SECCLASS_PROCESS,
> +                                 PROCESS__NNP_TRANSITION, NULL);
> +               if (!rc)
> +                       return 0;

This is interesting, we had been talking about domain transitions
under NNP, but we never really discussed transitions under nosuid
mounts, and the motivation for this patch appears to be entirely
around NNP alone.

I think the policycap/permission approach is reasonable, but I wonder
if we should separate this into two permissions, e.g. process {
nnp_transition nosuid_transition }, especially since such a change in
the future would likely require another policycap?

-- 
paul moore
www.paul-moore.com

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote:
> > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > > > As systemd ramps up enabling NoNewPrivileges (either
> > > > > > explicitly
> > > > > > in
> > > > > > service unit files or as a side effect of other security-
> > > > > > related
> > > > > > settings in service unit files), we're increasingly running
> > > > > > afoul of
> > > > > > its interactions with SELinux.
> > > > > > 
> > > > > > The end result is bad for the security of both SELinux-
> > > > > > disabled 
> > > > > > and
> > > > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > > > options in the unit files to preserve SELinux domain
> > > > > > transitions.  For
> > > > > > users who choose to disable SELinux, this means that they
> > > > > > miss
> > > > > > out on
> > > > > > at least having the systemd-supported protections.  For
> > > > > > users
> > > > > > who
> > > > > > keep
> > > > > > SELinux enabled, they may still be missing out on some
> > > > > > protections
> > > > > > because it isn't necessarily guaranteed that the SELinux
> > > > > > policy
> > > > > > for
> > > > > > that service provides the same protections in all cases.
> > > > > > 
> > > > > > Our options seem to be:
> > > > > > 
> > > > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > > > remove
> > > > > > default protection settings from upstream package unit
> > > > > > files in
> > > > > > order
> > > > > > to have them work with SELinux (and not just
> > > > > > NoNewPrivileges=
> > > > > > itself; increasingly systemd is enabling NNP as a side
> > > > > > effect
> > > > > > of
> > > > > > other
> > > > > > unit file options, even seemingly unrelated ones like
> > > > > > PrivateDevices).
> > > > > > SELinux-disabled users lose entirely, SELinux-enabled users
> > > > > > may
> > > > > > lose
> > > > > > (depending on whether SELinux policy provides equivalent or
> > > > > > better guarantees).
> > > > > > 
> > > > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > > > enabled
> > > > > > systems.  Unit files can be left unmodified from
> > > > > > upstream.  SELinux-
> > > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > > 
> > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > transitions
> > > > > > under
> > > > > > NNP.
> > > > > > Unit files can be left unmodified from upstream. SELinux-
> > > > > > disabled
> > > > > > users
> > > > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > > > provided
> > > > > > protections.  However, this option is impractical to
> > > > > > implement
> > > > > > in
> > > > > > policy
> > > > > > currently, since typebounds requires us to ensure that each
> > > > > > domain is
> > > > > > allowed everything all of its descendant domains are
> > > > > > allowed,
> > > > > > and
> > > > > > this
> > > > > > has to be repeated for the entire chain of domain
> > > > > > transitions.  There
> > > > > > is
> > > > > > no way to clone all allow rules from children to the parent
> > > > > > in
> > > > > > policy
> > > > > > currently, and it is doubtful that doing so would be
> > > > > > desirable
> > > > > > even
> > > > > > if
> > > > > > it were practical, as it requires leaking permissions to
> > > > > > objects and
> > > > > > operations into parent domains that could weaken their own
> > > > > > security
> > > > > > in
> > > > > > order to allow them to the children (e.g. if a child
> > > > > > requires
> > > > > > execmem
> > > > > > permission, then so does the parent; if a child requires
> > > > > > read
> > > > > > to a
> > > > > > symbolic
> > > > > > link or temporary file that it can write, then so does the
> > > > > > parent,
> > > > > > ...).
> > > > > > 
> > > > > > 4) Decouple NNP from SELinux transitions, so that we don't
> > > > > > have
> > > > > > to
> > > > > > make a choice between them. Introduce a new policy
> > > > > > capability
> > > > > > that
> > > > > > causes the ability to transition under NNP to be based on a
> > > > > > new
> > > > > > permission
> > > > > > check between the old and new contexts rather than
> > > > > > typebounds.  Domain
> > > > > > transitions can then be allowed in policy without requiring
> > > > > > the
> > > > > > parent
> > > > > > to be a strict superset of all of its children.  The
> > > > > > rationale
> > > > > > for
> > > > > > this
> > > > > > divergence from NNP behavior for capabilities is that
> > > > > > SELinux
> > > > > > permissions
> > > > > > are substantially broader than just capabilities (they
> > > > > > express
> > > > > > a full
> > > > > > access matrix, not just privileges) and can only be used to
> > > > > > further
> > > > > > restrict capabilities, not grant them beyond what is
> > > > > > already
> > > > > > permitted.
> > > > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > > > disabled
> > > > > > users
> > > > > > win.  SELinux-enabled users can benefit from systemd-
> > > > > > provided
> > > > > > protections
> > > > > > and policy won't need to radically change.
> > > > > > 
> > > > > > This change takes the last approach above, as it seems to
> > > > > > be
> > > > > > the
> > > > > > best option.
> > > > > > 
> > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > ---
> > > > > >  security/selinux/hooks.c            | 41
> > > > > > ++++++++++++++++++++++++---
> > > > > > ----------
> > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > >  security/selinux/include/security.h |  2 ++
> > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > 
> > > > > > diff --git a/security/selinux/hooks.c
> > > > > > b/security/selinux/hooks.c
> > > > > > index 3a06afb..f0c11c2 100644
> > > > > > --- a/security/selinux/hooks.c
> > > > > > +++ b/security/selinux/hooks.c
> > > > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > > > struct
> > > > > > linux_binprm *bprm,
> > > > > >  		return 0; /* No change in credentials */
> > > > > >  
> > > > > >  	/*
> > > > > > -	 * The only transitions we permit under NNP or
> > > > > > nosuid
> > > > > > -	 * are transitions to bounded SIDs, i.e. SIDs that
> > > > > > are
> > > > > > -	 * guaranteed to only be allowed a subset of the
> > > > > > permissions
> > > > > > -	 * of the current SID.
> > > > > > +	 * If the policy enables the nnp_transition policy
> > > > > > capability,
> > > > > > +	 * then we permit transitions under NNP or nosuid
> > > > > > if
> > > > > > the
> > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > permission
> > > > > > between
> > > > > > +	 * the old and new contexts.
> > > > > >  	 */
> > > > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > > > new_tsec-
> > > > > > > sid);
> > > > > > 
> > > > > > -	if (rc) {
> > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > > > > sid,
> > > > > > 
> > > > > > +				  SECCLASS_PROCESS,
> > > > > > +				  PROCESS__NNP_TRANSITION,
> > > > > > NULL);
> > > > > > +		if (!rc)
> > > > > > +			return 0;
> > > > > > +	} else {
> > > > > >  		/*
> > > > > > -		 * On failure, preserve the errno values
> > > > > > for
> > > > > > NNP vs
> > > > > > nosuid.
> > > > > > -		 * NNP:  Operation not permitted for
> > > > > > caller.
> > > > > > -		 * nosuid:  Permission denied to file.
> > > > > > +		 * Otherwise, the only transitions we
> > > > > > permit
> > > > > > under
> > > > > > NNP or nosuid
> > > > > > +		 * are transitions to bounded SIDs, i.e.
> > > > > > SIDs
> > > > > > that
> > > > > > are
> > > > > > +		 * guaranteed to only be allowed a subset
> > > > > > of
> > > > > > the
> > > > > > permissions
> > > > > > +		 * of the current SID.
> > > > > >  		 */
> > > > > > -		if (nnp)
> > > > > > -			return -EPERM;
> > > > > > -		else
> > > > > > -			return -EACCES;
> > > > > > +		rc = security_bounded_transition(old_tsec-
> > > > > > > sid,
> > > > > > 
> > > > > > new_tsec->sid);
> > > > > > +		if (!rc)
> > > > > > +			return 0;
> > > > > 
> > > > > NB: As currently written, this logic means that if you enable
> > > > > the
> > > > > new
> > > > > policy capability, the only way to allow a transition under
> > > > > NNP
> > > > > is by
> > > > > allowing nnp_transition permission between the old and new
> > > > > domains. The
> > > > > alternative would be to fall back to checking for a bounded
> > > > > SID
> > > > > if
> > > > > nnp_transition permission is not allowed. The former approach
> > > > > has
> > > > > the
> > > > > advantage of being simpler (only a single check with a single
> > > > > audit
> > > > > message), but means that you can't mix usage of bounded SIDs
> > > > > and
> > > > > nnp_transition permission as a means of allowing a
> > > > > transitions
> > > > > under
> > > > > NNP within the same policy.  The latter approach provides
> > > > > more
> > > > > flexibility / compatibility but will end up producing two
> > > > > audit
> > > > > messages in the case where the transition is denied by both
> > > > > checks: an
> > > > > AVC message for the permission denial and a SELINUX_ERR
> > > > > message
> > > > > for the
> > > > > security_bounded_transition failure, which might be confusing
> > > > > to
> > > > > users
> > > > > (but probably not; they'll likely just feed the AVC through
> > > > > audit2allow
> > > > > and be done with it).  Thoughts?
> > > > 
> > > > I think the current implementation is fine if i understand
> > > > correctly:
> > > > 
> > > > 1. With the policy capability disabled the behavior doesnt
> > > > change,
> > > > so if you dont want the current behavior (type_bounds) then
> > > > just to
> > > > enable the polcap
> > > > 2. If you enable the policy capability then you decided to
> > > > leverage
> > > > nnp_transition instead of the current behavior
> > > > 
> > > > Theres plenty flexibility with this approach i would argue
> > > 
> > > Hmm. that came out wrong:
> > > 
> > > 1. without nnptransition polcap: everything stays the same
> > > 2. with nnptransition polcap: you choose nnp_transition over
> > > current
> > > type_bounds behavior
> > 
> > Yes, that's correct. It is somewhat limiting in that if you want to
> > leverage nnp_transition at all, you have to give up using
> > typebounds
> > entirely for allowing NNP transitions.  So, let's say there is an
> > existing policy module that defines a typebounds in order to allow
> > a
> > NNP transition, and then another policy module decides to enable
> > the
> > policy capability and leverage nnp_transition permission to allow
> > another NNP transition that wouldn't work under typebounds.  The
> > first
> > one will break under the former approach, while it would keep
> > working
> > under the latter approach. Not sure if that's a real concern or
> > just a
> > contrived one.  Let's say someone writes a third party policy
> > module
> > using typebounds for this purpose on Fedora today, and then updates
> > to
> > a new version of Fedora that enables the policy capability and
> > leverages nnp_transition in its policy to allow such
> > transitions.  Now
> > that third party policy module will stop working (it would need to
> > be
> > changed to allow nnp_transition explicitly).
> 
> Would this affect the requirement of typebounds by for example
> mod_selinux? I think that apache module also requires typebounds but
> not for NNP AFAIK (that stuff predates it i believe)

No, this doesn't affect that.  That's a security_bounded_transition()
check in selinux_setprocattr() for writes to /proc/self/attr/current if
the process is multi-threaded.

> I prefer this implementation if this implementation is reasonably
> possible. I dont believe that there are any third party modules that
> support NNP (its too un-usable and hard to write)
> 
> I wont be leveraging nnp_transition or type_bounds for NNP BTW. I
> will just contrinue removing the NNP= for systemd service units.

Note that it isn't sufficient to just remove NoNewPrivileges= from the
unit file; you also have to remove any other options that implicitly
enable NNP, which seems to be growing.  For example, any of the
following will now enable NNP too as a side effect:
SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=,
RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
ProtectKernelModules=, MemoryDenyWriteExecute=, or RestrictRealtime= 

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > >  	}
> > > > > > -	return 0;
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * On failure, preserve the errno values for NNP
> > > > > > vs
> > > > > > nosuid.
> > > > > > +	 * NNP:  Operation not permitted for caller.
> > > > > > +	 * nosuid:  Permission denied to file.
> > > > > > +	 */
> > > > > > +	if (nnp)
> > > > > > +		return -EPERM;
> > > > > > +	return -EACCES;
> > > > > >  }
> > > > > >  
> > > > > >  static int selinux_bprm_set_creds(struct linux_binprm
> > > > > > *bprm)
> > > > > > diff --git a/security/selinux/include/classmap.h
> > > > > > b/security/selinux/include/classmap.h
> > > > > > index b9fe343..7fde56d 100644
> > > > > > --- a/security/selinux/include/classmap.h
> > > > > > +++ b/security/selinux/include/classmap.h
> > > > > > @@ -47,7 +47,7 @@ struct security_class_mapping
> > > > > > secclass_map[]
> > > > > > = {
> > > > > >  	    "getattr", "setexec", "setfscreate",
> > > > > > "noatsecure",
> > > > > > "siginh",
> > > > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > > > "setcurrent",
> > > > > >  	    "execmem", "execstack", "execheap",
> > > > > > "setkeycreate",
> > > > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > > > +	    "setsockcreate", "getrlimit",
> > > > > > "nnp_transition",
> > > > > > NULL }
> > > > > > },
> > > > > >  	{ "system",
> > > > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > > > >  	    "syslog_console", "module_request",
> > > > > > "module_load",
> > > > > > NULL
> > > > > > } },
> > > > > > diff --git a/security/selinux/include/security.h
> > > > > > b/security/selinux/include/security.h
> > > > > > index e91f08c..88efb1b 100644
> > > > > > --- a/security/selinux/include/security.h
> > > > > > +++ b/security/selinux/include/security.h
> > > > > > @@ -73,6 +73,7 @@ enum {
> > > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > > >  };
> > > > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX
> > > > > > -
> > > > > > 1)
> > > > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > > > >  extern int selinux_policycap_extsockclass;
> > > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > > +extern int selinux_policycap_nnptransition;
> > > > > >  
> > > > > >  /*
> > > > > >   * type_datum properties
> > > > > > diff --git a/security/selinux/ss/services.c
> > > > > > b/security/selinux/ss/services.c
> > > > > > index 2f02fa6..2faf47a 100644
> > > > > > --- a/security/selinux/ss/services.c
> > > > > > +++ b/security/selinux/ss/services.c
> > > > > > @@ -76,7 +76,8 @@ char
> > > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > > > >  	"open_perms",
> > > > > >  	"extended_socket_class",
> > > > > >  	"always_check_network",
> > > > > > -	"cgroup_seclabel"
> > > > > > +	"cgroup_seclabel",
> > > > > > +	"nnp_transition"
> > > > > >  };
> > > > > >  
> > > > > >  int selinux_policycap_netpeer;
> > > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > > >  int selinux_policycap_extsockclass;
> > > > > >  int selinux_policycap_alwaysnetwork;
> > > > > >  int selinux_policycap_cgroupseclabel;
> > > > > > +int selinux_policycap_nnptransition;
> > > > > >  
> > > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > > >  
> > > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > > security_load_policycaps(void)
> > > > > >  	selinux_policycap_cgroupseclabel =
> > > > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > > > >  				POLICYDB_CAPABILITY_CGROUP
> > > > > > SECL
> > > > > > ABEL);
> > > > > > +	selinux_policycap_nnptransition =
> > > > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > > > +				POLICYDB_CAPABILITY_NNPTRA
> > > > > > NSIT
> > > > > > ION);
> > > > > >  
> > > > > >  	for (i = 0; i <
> > > > > > ARRAY_SIZE(selinux_policycap_names);
> > > > > > i++)
> > > > > >  		pr_info("SELinux:  policy capability
> > > > > > %s=%d\n",
> > > > 
> > > > -- 
> > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > > 6B02
> > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
> > > > C7B6
> > > > B02
> > > > Dominick Grift
> > > 
> > > 
> > > 
> 
> 

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > As systemd ramps up enabling NoNewPrivileges (either explicitly in
> > service unit files or as a side effect of other security-related
> > settings in service unit files), we're increasingly running afoul
> > of
> > its interactions with SELinux...
> 
> We already talked about this in the other thread so I'll refrain from
> repeating myself.
> 
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 3a06afb..f0c11c2 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct
> > linux_binprm *bprm,
> >                 return 0; /* No change in credentials */
> > 
> >         /*
> > -        * The only transitions we permit under NNP or nosuid
> > -        * are transitions to bounded SIDs, i.e. SIDs that are
> > -        * guaranteed to only be allowed a subset of the
> > permissions
> > -        * of the current SID.
> > +        * If the policy enables the nnp_transition policy
> > capability,
> > +        * then we permit transitions under NNP or nosuid if the
> > +        * policy explicitly allows nnp_transition permission
> > between
> > +        * the old and new contexts.
> >          */
> > -       rc = security_bounded_transition(old_tsec->sid, new_tsec-
> > >sid);
> > -       if (rc) {
> > +       if (selinux_policycap_nnptransition) {
> > +               rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> > +                                 SECCLASS_PROCESS,
> > +                                 PROCESS__NNP_TRANSITION, NULL);
> > +               if (!rc)
> > +                       return 0;
> 
> This is interesting, we had been talking about domain transitions
> under NNP, but we never really discussed transitions under nosuid
> mounts, and the motivation for this patch appears to be entirely
> around NNP alone.

Yes, I decided to keep NNP and nosuid handling consistent.  Similar
arguments apply; the current restriction on SELinux transitions on
nosuid mounts forces users to make a choice between SELinux transitions
and nosuid mounts, which can leave them less protected.  That has been
a common issue e.g. for httpd transitions on cgi scripts and the like.

> I think the policycap/permission approach is reasonable, but I wonder
> if we should separate this into two permissions, e.g. process {
> nnp_transition nosuid_transition }, especially since such a change in
> the future would likely require another policycap?

I was hoping to avoid that and keep the nnp/nosuid handling consistent.
 Also, we are out of process permissions after nnp_transition, so we
can't do that without adding a process2 or similar class. Possibly we
could name the capability and permission more generally to make it
clearer that it affect both, but not sure what to suggest there
(nnpnosuid_transition?).

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 18941 bytes --]

On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote:
> > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > > > > As systemd ramps up enabling NoNewPrivileges (either
> > > > > > > explicitly
> > > > > > > in
> > > > > > > service unit files or as a side effect of other security-
> > > > > > > related
> > > > > > > settings in service unit files), we're increasingly running
> > > > > > > afoul of
> > > > > > > its interactions with SELinux.
> > > > > > > 
> > > > > > > The end result is bad for the security of both SELinux-
> > > > > > > disabled 
> > > > > > > and
> > > > > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > > > > options in the unit files to preserve SELinux domain
> > > > > > > transitions.  For
> > > > > > > users who choose to disable SELinux, this means that they
> > > > > > > miss
> > > > > > > out on
> > > > > > > at least having the systemd-supported protections.  For
> > > > > > > users
> > > > > > > who
> > > > > > > keep
> > > > > > > SELinux enabled, they may still be missing out on some
> > > > > > > protections
> > > > > > > because it isn't necessarily guaranteed that the SELinux
> > > > > > > policy
> > > > > > > for
> > > > > > > that service provides the same protections in all cases.
> > > > > > > 
> > > > > > > Our options seem to be:
> > > > > > > 
> > > > > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > > > > remove
> > > > > > > default protection settings from upstream package unit
> > > > > > > files in
> > > > > > > order
> > > > > > > to have them work with SELinux (and not just
> > > > > > > NoNewPrivileges=
> > > > > > > itself; increasingly systemd is enabling NNP as a side
> > > > > > > effect
> > > > > > > of
> > > > > > > other
> > > > > > > unit file options, even seemingly unrelated ones like
> > > > > > > PrivateDevices).
> > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users
> > > > > > > may
> > > > > > > lose
> > > > > > > (depending on whether SELinux policy provides equivalent or
> > > > > > > better guarantees).
> > > > > > > 
> > > > > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > > > > enabled
> > > > > > > systems.  Unit files can be left unmodified from
> > > > > > > upstream.  SELinux-
> > > > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > > > 
> > > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > > transitions
> > > > > > > under
> > > > > > > NNP.
> > > > > > > Unit files can be left unmodified from upstream. SELinux-
> > > > > > > disabled
> > > > > > > users
> > > > > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > > > > provided
> > > > > > > protections.  However, this option is impractical to
> > > > > > > implement
> > > > > > > in
> > > > > > > policy
> > > > > > > currently, since typebounds requires us to ensure that each
> > > > > > > domain is
> > > > > > > allowed everything all of its descendant domains are
> > > > > > > allowed,
> > > > > > > and
> > > > > > > this
> > > > > > > has to be repeated for the entire chain of domain
> > > > > > > transitions.  There
> > > > > > > is
> > > > > > > no way to clone all allow rules from children to the parent
> > > > > > > in
> > > > > > > policy
> > > > > > > currently, and it is doubtful that doing so would be
> > > > > > > desirable
> > > > > > > even
> > > > > > > if
> > > > > > > it were practical, as it requires leaking permissions to
> > > > > > > objects and
> > > > > > > operations into parent domains that could weaken their own
> > > > > > > security
> > > > > > > in
> > > > > > > order to allow them to the children (e.g. if a child
> > > > > > > requires
> > > > > > > execmem
> > > > > > > permission, then so does the parent; if a child requires
> > > > > > > read
> > > > > > > to a
> > > > > > > symbolic
> > > > > > > link or temporary file that it can write, then so does the
> > > > > > > parent,
> > > > > > > ...).
> > > > > > > 
> > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't
> > > > > > > have
> > > > > > > to
> > > > > > > make a choice between them. Introduce a new policy
> > > > > > > capability
> > > > > > > that
> > > > > > > causes the ability to transition under NNP to be based on a
> > > > > > > new
> > > > > > > permission
> > > > > > > check between the old and new contexts rather than
> > > > > > > typebounds.  Domain
> > > > > > > transitions can then be allowed in policy without requiring
> > > > > > > the
> > > > > > > parent
> > > > > > > to be a strict superset of all of its children.  The
> > > > > > > rationale
> > > > > > > for
> > > > > > > this
> > > > > > > divergence from NNP behavior for capabilities is that
> > > > > > > SELinux
> > > > > > > permissions
> > > > > > > are substantially broader than just capabilities (they
> > > > > > > express
> > > > > > > a full
> > > > > > > access matrix, not just privileges) and can only be used to
> > > > > > > further
> > > > > > > restrict capabilities, not grant them beyond what is
> > > > > > > already
> > > > > > > permitted.
> > > > > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > > > > disabled
> > > > > > > users
> > > > > > > win.  SELinux-enabled users can benefit from systemd-
> > > > > > > provided
> > > > > > > protections
> > > > > > > and policy won't need to radically change.
> > > > > > > 
> > > > > > > This change takes the last approach above, as it seems to
> > > > > > > be
> > > > > > > the
> > > > > > > best option.
> > > > > > > 
> > > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > > ---
> > > > > > >  security/selinux/hooks.c            | 41
> > > > > > > ++++++++++++++++++++++++---
> > > > > > > ----------
> > > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > > >  security/selinux/include/security.h |  2 ++
> > > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/security/selinux/hooks.c
> > > > > > > b/security/selinux/hooks.c
> > > > > > > index 3a06afb..f0c11c2 100644
> > > > > > > --- a/security/selinux/hooks.c
> > > > > > > +++ b/security/selinux/hooks.c
> > > > > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > > > > struct
> > > > > > > linux_binprm *bprm,
> > > > > > >  		return 0; /* No change in credentials */
> > > > > > >  
> > > > > > >  	/*
> > > > > > > -	 * The only transitions we permit under NNP or
> > > > > > > nosuid
> > > > > > > -	 * are transitions to bounded SIDs, i.e. SIDs that
> > > > > > > are
> > > > > > > -	 * guaranteed to only be allowed a subset of the
> > > > > > > permissions
> > > > > > > -	 * of the current SID.
> > > > > > > +	 * If the policy enables the nnp_transition policy
> > > > > > > capability,
> > > > > > > +	 * then we permit transitions under NNP or nosuid
> > > > > > > if
> > > > > > > the
> > > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > > permission
> > > > > > > between
> > > > > > > +	 * the old and new contexts.
> > > > > > >  	 */
> > > > > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > > > > new_tsec-
> > > > > > > > sid);
> > > > > > > 
> > > > > > > -	if (rc) {
> > > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > > > > > sid,
> > > > > > > 
> > > > > > > +				  SECCLASS_PROCESS,
> > > > > > > +				  PROCESS__NNP_TRANSITION,
> > > > > > > NULL);
> > > > > > > +		if (!rc)
> > > > > > > +			return 0;
> > > > > > > +	} else {
> > > > > > >  		/*
> > > > > > > -		 * On failure, preserve the errno values
> > > > > > > for
> > > > > > > NNP vs
> > > > > > > nosuid.
> > > > > > > -		 * NNP:  Operation not permitted for
> > > > > > > caller.
> > > > > > > -		 * nosuid:  Permission denied to file.
> > > > > > > +		 * Otherwise, the only transitions we
> > > > > > > permit
> > > > > > > under
> > > > > > > NNP or nosuid
> > > > > > > +		 * are transitions to bounded SIDs, i.e.
> > > > > > > SIDs
> > > > > > > that
> > > > > > > are
> > > > > > > +		 * guaranteed to only be allowed a subset
> > > > > > > of
> > > > > > > the
> > > > > > > permissions
> > > > > > > +		 * of the current SID.
> > > > > > >  		 */
> > > > > > > -		if (nnp)
> > > > > > > -			return -EPERM;
> > > > > > > -		else
> > > > > > > -			return -EACCES;
> > > > > > > +		rc = security_bounded_transition(old_tsec-
> > > > > > > > sid,
> > > > > > > 
> > > > > > > new_tsec->sid);
> > > > > > > +		if (!rc)
> > > > > > > +			return 0;
> > > > > > 
> > > > > > NB: As currently written, this logic means that if you enable
> > > > > > the
> > > > > > new
> > > > > > policy capability, the only way to allow a transition under
> > > > > > NNP
> > > > > > is by
> > > > > > allowing nnp_transition permission between the old and new
> > > > > > domains. The
> > > > > > alternative would be to fall back to checking for a bounded
> > > > > > SID
> > > > > > if
> > > > > > nnp_transition permission is not allowed. The former approach
> > > > > > has
> > > > > > the
> > > > > > advantage of being simpler (only a single check with a single
> > > > > > audit
> > > > > > message), but means that you can't mix usage of bounded SIDs
> > > > > > and
> > > > > > nnp_transition permission as a means of allowing a
> > > > > > transitions
> > > > > > under
> > > > > > NNP within the same policy.  The latter approach provides
> > > > > > more
> > > > > > flexibility / compatibility but will end up producing two
> > > > > > audit
> > > > > > messages in the case where the transition is denied by both
> > > > > > checks: an
> > > > > > AVC message for the permission denial and a SELINUX_ERR
> > > > > > message
> > > > > > for the
> > > > > > security_bounded_transition failure, which might be confusing
> > > > > > to
> > > > > > users
> > > > > > (but probably not; they'll likely just feed the AVC through
> > > > > > audit2allow
> > > > > > and be done with it).  Thoughts?
> > > > > 
> > > > > I think the current implementation is fine if i understand
> > > > > correctly:
> > > > > 
> > > > > 1. With the policy capability disabled the behavior doesnt
> > > > > change,
> > > > > so if you dont want the current behavior (type_bounds) then
> > > > > just to
> > > > > enable the polcap
> > > > > 2. If you enable the policy capability then you decided to
> > > > > leverage
> > > > > nnp_transition instead of the current behavior
> > > > > 
> > > > > Theres plenty flexibility with this approach i would argue
> > > > 
> > > > Hmm. that came out wrong:
> > > > 
> > > > 1. without nnptransition polcap: everything stays the same
> > > > 2. with nnptransition polcap: you choose nnp_transition over
> > > > current
> > > > type_bounds behavior
> > > 
> > > Yes, that's correct. It is somewhat limiting in that if you want to
> > > leverage nnp_transition at all, you have to give up using
> > > typebounds
> > > entirely for allowing NNP transitions.  So, let's say there is an
> > > existing policy module that defines a typebounds in order to allow
> > > a
> > > NNP transition, and then another policy module decides to enable
> > > the
> > > policy capability and leverage nnp_transition permission to allow
> > > another NNP transition that wouldn't work under typebounds.  The
> > > first
> > > one will break under the former approach, while it would keep
> > > working
> > > under the latter approach. Not sure if that's a real concern or
> > > just a
> > > contrived one.  Let's say someone writes a third party policy
> > > module
> > > using typebounds for this purpose on Fedora today, and then updates
> > > to
> > > a new version of Fedora that enables the policy capability and
> > > leverages nnp_transition in its policy to allow such
> > > transitions.  Now
> > > that third party policy module will stop working (it would need to
> > > be
> > > changed to allow nnp_transition explicitly).
> > 
> > Would this affect the requirement of typebounds by for example
> > mod_selinux? I think that apache module also requires typebounds but
> > not for NNP AFAIK (that stuff predates it i believe)
> 
> No, this doesn't affect that.  That's a security_bounded_transition()
> check in selinux_setprocattr() for writes to /proc/self/attr/current if
> the process is multi-threaded.
> 
> > I prefer this implementation if this implementation is reasonably
> > possible. I dont believe that there are any third party modules that
> > support NNP (its too un-usable and hard to write)
> > 
> > I wont be leveraging nnp_transition or type_bounds for NNP BTW. I
> > will just contrinue removing the NNP= for systemd service units.
> 
> Note that it isn't sufficient to just remove NoNewPrivileges= from the
> unit file; you also have to remove any other options that implicitly
> enable NNP, which seems to be growing.  For example, any of the
> following will now enable NNP too as a side effect:
> SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=,
> RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
> ProtectKernelModules=, MemoryDenyWriteExecute=, or RestrictRealtime= 

Are you sure because if that was the case I probably would have noticed?

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > >  	}
> > > > > > > -	return 0;
> > > > > > > +
> > > > > > > +	/*
> > > > > > > +	 * On failure, preserve the errno values for NNP
> > > > > > > vs
> > > > > > > nosuid.
> > > > > > > +	 * NNP:  Operation not permitted for caller.
> > > > > > > +	 * nosuid:  Permission denied to file.
> > > > > > > +	 */
> > > > > > > +	if (nnp)
> > > > > > > +		return -EPERM;
> > > > > > > +	return -EACCES;
> > > > > > >  }
> > > > > > >  
> > > > > > >  static int selinux_bprm_set_creds(struct linux_binprm
> > > > > > > *bprm)
> > > > > > > diff --git a/security/selinux/include/classmap.h
> > > > > > > b/security/selinux/include/classmap.h
> > > > > > > index b9fe343..7fde56d 100644
> > > > > > > --- a/security/selinux/include/classmap.h
> > > > > > > +++ b/security/selinux/include/classmap.h
> > > > > > > @@ -47,7 +47,7 @@ struct security_class_mapping
> > > > > > > secclass_map[]
> > > > > > > = {
> > > > > > >  	    "getattr", "setexec", "setfscreate",
> > > > > > > "noatsecure",
> > > > > > > "siginh",
> > > > > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > > > > "setcurrent",
> > > > > > >  	    "execmem", "execstack", "execheap",
> > > > > > > "setkeycreate",
> > > > > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > > > > +	    "setsockcreate", "getrlimit",
> > > > > > > "nnp_transition",
> > > > > > > NULL }
> > > > > > > },
> > > > > > >  	{ "system",
> > > > > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > > > > >  	    "syslog_console", "module_request",
> > > > > > > "module_load",
> > > > > > > NULL
> > > > > > > } },
> > > > > > > diff --git a/security/selinux/include/security.h
> > > > > > > b/security/selinux/include/security.h
> > > > > > > index e91f08c..88efb1b 100644
> > > > > > > --- a/security/selinux/include/security.h
> > > > > > > +++ b/security/selinux/include/security.h
> > > > > > > @@ -73,6 +73,7 @@ enum {
> > > > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > > > >  };
> > > > > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX
> > > > > > > -
> > > > > > > 1)
> > > > > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > > > > >  extern int selinux_policycap_extsockclass;
> > > > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > > > +extern int selinux_policycap_nnptransition;
> > > > > > >  
> > > > > > >  /*
> > > > > > >   * type_datum properties
> > > > > > > diff --git a/security/selinux/ss/services.c
> > > > > > > b/security/selinux/ss/services.c
> > > > > > > index 2f02fa6..2faf47a 100644
> > > > > > > --- a/security/selinux/ss/services.c
> > > > > > > +++ b/security/selinux/ss/services.c
> > > > > > > @@ -76,7 +76,8 @@ char
> > > > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > > > > >  	"open_perms",
> > > > > > >  	"extended_socket_class",
> > > > > > >  	"always_check_network",
> > > > > > > -	"cgroup_seclabel"
> > > > > > > +	"cgroup_seclabel",
> > > > > > > +	"nnp_transition"
> > > > > > >  };
> > > > > > >  
> > > > > > >  int selinux_policycap_netpeer;
> > > > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > > > >  int selinux_policycap_extsockclass;
> > > > > > >  int selinux_policycap_alwaysnetwork;
> > > > > > >  int selinux_policycap_cgroupseclabel;
> > > > > > > +int selinux_policycap_nnptransition;
> > > > > > >  
> > > > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > > > >  
> > > > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > > > security_load_policycaps(void)
> > > > > > >  	selinux_policycap_cgroupseclabel =
> > > > > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > > > > >  				POLICYDB_CAPABILITY_CGROUP
> > > > > > > SECL
> > > > > > > ABEL);
> > > > > > > +	selinux_policycap_nnptransition =
> > > > > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > > > > +				POLICYDB_CAPABILITY_NNPTRA
> > > > > > > NSIT
> > > > > > > ION);
> > > > > > >  
> > > > > > >  	for (i = 0; i <
> > > > > > > ARRAY_SIZE(selinux_policycap_names);
> > > > > > > i++)
> > > > > > >  		pr_info("SELinux:  policy capability
> > > > > > > %s=%d\n",
> > > > > 
> > > > > -- 
> > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > > > 6B02
> > > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
> > > > > C7B6
> > > > > B02
> > > > > Dominick Grift
> > > > 
> > > > 
> > > > 
> > 
> > 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 20343 bytes --]

On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote:
> > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > > > > > As systemd ramps up enabling NoNewPrivileges (either
> > > > > > > > explicitly
> > > > > > > > in
> > > > > > > > service unit files or as a side effect of other security-
> > > > > > > > related
> > > > > > > > settings in service unit files), we're increasingly running
> > > > > > > > afoul of
> > > > > > > > its interactions with SELinux.
> > > > > > > > 
> > > > > > > > The end result is bad for the security of both SELinux-
> > > > > > > > disabled 
> > > > > > > > and
> > > > > > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > > > > > options in the unit files to preserve SELinux domain
> > > > > > > > transitions.  For
> > > > > > > > users who choose to disable SELinux, this means that they
> > > > > > > > miss
> > > > > > > > out on
> > > > > > > > at least having the systemd-supported protections.  For
> > > > > > > > users
> > > > > > > > who
> > > > > > > > keep
> > > > > > > > SELinux enabled, they may still be missing out on some
> > > > > > > > protections
> > > > > > > > because it isn't necessarily guaranteed that the SELinux
> > > > > > > > policy
> > > > > > > > for
> > > > > > > > that service provides the same protections in all cases.
> > > > > > > > 
> > > > > > > > Our options seem to be:
> > > > > > > > 
> > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > > > > > remove
> > > > > > > > default protection settings from upstream package unit
> > > > > > > > files in
> > > > > > > > order
> > > > > > > > to have them work with SELinux (and not just
> > > > > > > > NoNewPrivileges=
> > > > > > > > itself; increasingly systemd is enabling NNP as a side
> > > > > > > > effect
> > > > > > > > of
> > > > > > > > other
> > > > > > > > unit file options, even seemingly unrelated ones like
> > > > > > > > PrivateDevices).
> > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users
> > > > > > > > may
> > > > > > > > lose
> > > > > > > > (depending on whether SELinux policy provides equivalent or
> > > > > > > > better guarantees).
> > > > > > > > 
> > > > > > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > > > > > enabled
> > > > > > > > systems.  Unit files can be left unmodified from
> > > > > > > > upstream.  SELinux-
> > > > > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > > > > 
> > > > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > > > transitions
> > > > > > > > under
> > > > > > > > NNP.
> > > > > > > > Unit files can be left unmodified from upstream. SELinux-
> > > > > > > > disabled
> > > > > > > > users
> > > > > > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > > > > > provided
> > > > > > > > protections.  However, this option is impractical to
> > > > > > > > implement
> > > > > > > > in
> > > > > > > > policy
> > > > > > > > currently, since typebounds requires us to ensure that each
> > > > > > > > domain is
> > > > > > > > allowed everything all of its descendant domains are
> > > > > > > > allowed,
> > > > > > > > and
> > > > > > > > this
> > > > > > > > has to be repeated for the entire chain of domain
> > > > > > > > transitions.  There
> > > > > > > > is
> > > > > > > > no way to clone all allow rules from children to the parent
> > > > > > > > in
> > > > > > > > policy
> > > > > > > > currently, and it is doubtful that doing so would be
> > > > > > > > desirable
> > > > > > > > even
> > > > > > > > if
> > > > > > > > it were practical, as it requires leaking permissions to
> > > > > > > > objects and
> > > > > > > > operations into parent domains that could weaken their own
> > > > > > > > security
> > > > > > > > in
> > > > > > > > order to allow them to the children (e.g. if a child
> > > > > > > > requires
> > > > > > > > execmem
> > > > > > > > permission, then so does the parent; if a child requires
> > > > > > > > read
> > > > > > > > to a
> > > > > > > > symbolic
> > > > > > > > link or temporary file that it can write, then so does the
> > > > > > > > parent,
> > > > > > > > ...).
> > > > > > > > 
> > > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't
> > > > > > > > have
> > > > > > > > to
> > > > > > > > make a choice between them. Introduce a new policy
> > > > > > > > capability
> > > > > > > > that
> > > > > > > > causes the ability to transition under NNP to be based on a
> > > > > > > > new
> > > > > > > > permission
> > > > > > > > check between the old and new contexts rather than
> > > > > > > > typebounds.  Domain
> > > > > > > > transitions can then be allowed in policy without requiring
> > > > > > > > the
> > > > > > > > parent
> > > > > > > > to be a strict superset of all of its children.  The
> > > > > > > > rationale
> > > > > > > > for
> > > > > > > > this
> > > > > > > > divergence from NNP behavior for capabilities is that
> > > > > > > > SELinux
> > > > > > > > permissions
> > > > > > > > are substantially broader than just capabilities (they
> > > > > > > > express
> > > > > > > > a full
> > > > > > > > access matrix, not just privileges) and can only be used to
> > > > > > > > further
> > > > > > > > restrict capabilities, not grant them beyond what is
> > > > > > > > already
> > > > > > > > permitted.
> > > > > > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > > > > > disabled
> > > > > > > > users
> > > > > > > > win.  SELinux-enabled users can benefit from systemd-
> > > > > > > > provided
> > > > > > > > protections
> > > > > > > > and policy won't need to radically change.
> > > > > > > > 
> > > > > > > > This change takes the last approach above, as it seems to
> > > > > > > > be
> > > > > > > > the
> > > > > > > > best option.
> > > > > > > > 
> > > > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > > > ---
> > > > > > > >  security/selinux/hooks.c            | 41
> > > > > > > > ++++++++++++++++++++++++---
> > > > > > > > ----------
> > > > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > > > >  security/selinux/include/security.h |  2 ++
> > > > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/security/selinux/hooks.c
> > > > > > > > b/security/selinux/hooks.c
> > > > > > > > index 3a06afb..f0c11c2 100644
> > > > > > > > --- a/security/selinux/hooks.c
> > > > > > > > +++ b/security/selinux/hooks.c
> > > > > > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > > > > > struct
> > > > > > > > linux_binprm *bprm,
> > > > > > > >  		return 0; /* No change in credentials */
> > > > > > > >  
> > > > > > > >  	/*
> > > > > > > > -	 * The only transitions we permit under NNP or
> > > > > > > > nosuid
> > > > > > > > -	 * are transitions to bounded SIDs, i.e. SIDs that
> > > > > > > > are
> > > > > > > > -	 * guaranteed to only be allowed a subset of the
> > > > > > > > permissions
> > > > > > > > -	 * of the current SID.
> > > > > > > > +	 * If the policy enables the nnp_transition policy
> > > > > > > > capability,
> > > > > > > > +	 * then we permit transitions under NNP or nosuid
> > > > > > > > if
> > > > > > > > the
> > > > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > > > permission
> > > > > > > > between
> > > > > > > > +	 * the old and new contexts.
> > > > > > > >  	 */
> > > > > > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > > > > > new_tsec-
> > > > > > > > > sid);
> > > > > > > > 
> > > > > > > > -	if (rc) {
> > > > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > > > > > > sid,
> > > > > > > > 
> > > > > > > > +				  SECCLASS_PROCESS,
> > > > > > > > +				  PROCESS__NNP_TRANSITION,
> > > > > > > > NULL);
> > > > > > > > +		if (!rc)
> > > > > > > > +			return 0;
> > > > > > > > +	} else {
> > > > > > > >  		/*
> > > > > > > > -		 * On failure, preserve the errno values
> > > > > > > > for
> > > > > > > > NNP vs
> > > > > > > > nosuid.
> > > > > > > > -		 * NNP:  Operation not permitted for
> > > > > > > > caller.
> > > > > > > > -		 * nosuid:  Permission denied to file.
> > > > > > > > +		 * Otherwise, the only transitions we
> > > > > > > > permit
> > > > > > > > under
> > > > > > > > NNP or nosuid
> > > > > > > > +		 * are transitions to bounded SIDs, i.e.
> > > > > > > > SIDs
> > > > > > > > that
> > > > > > > > are
> > > > > > > > +		 * guaranteed to only be allowed a subset
> > > > > > > > of
> > > > > > > > the
> > > > > > > > permissions
> > > > > > > > +		 * of the current SID.
> > > > > > > >  		 */
> > > > > > > > -		if (nnp)
> > > > > > > > -			return -EPERM;
> > > > > > > > -		else
> > > > > > > > -			return -EACCES;
> > > > > > > > +		rc = security_bounded_transition(old_tsec-
> > > > > > > > > sid,
> > > > > > > > 
> > > > > > > > new_tsec->sid);
> > > > > > > > +		if (!rc)
> > > > > > > > +			return 0;
> > > > > > > 
> > > > > > > NB: As currently written, this logic means that if you enable
> > > > > > > the
> > > > > > > new
> > > > > > > policy capability, the only way to allow a transition under
> > > > > > > NNP
> > > > > > > is by
> > > > > > > allowing nnp_transition permission between the old and new
> > > > > > > domains. The
> > > > > > > alternative would be to fall back to checking for a bounded
> > > > > > > SID
> > > > > > > if
> > > > > > > nnp_transition permission is not allowed. The former approach
> > > > > > > has
> > > > > > > the
> > > > > > > advantage of being simpler (only a single check with a single
> > > > > > > audit
> > > > > > > message), but means that you can't mix usage of bounded SIDs
> > > > > > > and
> > > > > > > nnp_transition permission as a means of allowing a
> > > > > > > transitions
> > > > > > > under
> > > > > > > NNP within the same policy.  The latter approach provides
> > > > > > > more
> > > > > > > flexibility / compatibility but will end up producing two
> > > > > > > audit
> > > > > > > messages in the case where the transition is denied by both
> > > > > > > checks: an
> > > > > > > AVC message for the permission denial and a SELINUX_ERR
> > > > > > > message
> > > > > > > for the
> > > > > > > security_bounded_transition failure, which might be confusing
> > > > > > > to
> > > > > > > users
> > > > > > > (but probably not; they'll likely just feed the AVC through
> > > > > > > audit2allow
> > > > > > > and be done with it).  Thoughts?
> > > > > > 
> > > > > > I think the current implementation is fine if i understand
> > > > > > correctly:
> > > > > > 
> > > > > > 1. With the policy capability disabled the behavior doesnt
> > > > > > change,
> > > > > > so if you dont want the current behavior (type_bounds) then
> > > > > > just to
> > > > > > enable the polcap
> > > > > > 2. If you enable the policy capability then you decided to
> > > > > > leverage
> > > > > > nnp_transition instead of the current behavior
> > > > > > 
> > > > > > Theres plenty flexibility with this approach i would argue
> > > > > 
> > > > > Hmm. that came out wrong:
> > > > > 
> > > > > 1. without nnptransition polcap: everything stays the same
> > > > > 2. with nnptransition polcap: you choose nnp_transition over
> > > > > current
> > > > > type_bounds behavior
> > > > 
> > > > Yes, that's correct. It is somewhat limiting in that if you want to
> > > > leverage nnp_transition at all, you have to give up using
> > > > typebounds
> > > > entirely for allowing NNP transitions.  So, let's say there is an
> > > > existing policy module that defines a typebounds in order to allow
> > > > a
> > > > NNP transition, and then another policy module decides to enable
> > > > the
> > > > policy capability and leverage nnp_transition permission to allow
> > > > another NNP transition that wouldn't work under typebounds.  The
> > > > first
> > > > one will break under the former approach, while it would keep
> > > > working
> > > > under the latter approach. Not sure if that's a real concern or
> > > > just a
> > > > contrived one.  Let's say someone writes a third party policy
> > > > module
> > > > using typebounds for this purpose on Fedora today, and then updates
> > > > to
> > > > a new version of Fedora that enables the policy capability and
> > > > leverages nnp_transition in its policy to allow such
> > > > transitions.  Now
> > > > that third party policy module will stop working (it would need to
> > > > be
> > > > changed to allow nnp_transition explicitly).
> > > 
> > > Would this affect the requirement of typebounds by for example
> > > mod_selinux? I think that apache module also requires typebounds but
> > > not for NNP AFAIK (that stuff predates it i believe)
> > 
> > No, this doesn't affect that.  That's a security_bounded_transition()
> > check in selinux_setprocattr() for writes to /proc/self/attr/current if
> > the process is multi-threaded.
> > 
> > > I prefer this implementation if this implementation is reasonably
> > > possible. I dont believe that there are any third party modules that
> > > support NNP (its too un-usable and hard to write)
> > > 
> > > I wont be leveraging nnp_transition or type_bounds for NNP BTW. I
> > > will just contrinue removing the NNP= for systemd service units.
> > 
> > Note that it isn't sufficient to just remove NoNewPrivileges= from the
> > unit file; you also have to remove any other options that implicitly
> > enable NNP, which seems to be growing.  For example, any of the
> > following will now enable NNP too as a side effect:
> > SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=,
> > RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
> > ProtectKernelModules=, MemoryDenyWriteExecute=, or RestrictRealtime= 
> 
> Are you sure because if that was the case I probably would have noticed?

Hmm.. man systemd.exec does say that its implied. It is strange that i haven't encountered it.

Why would nnp have to be implied for for example ProtectKernelTunables?

This makes things really ugly ...

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > >  	}
> > > > > > > > -	return 0;
> > > > > > > > +
> > > > > > > > +	/*
> > > > > > > > +	 * On failure, preserve the errno values for NNP
> > > > > > > > vs
> > > > > > > > nosuid.
> > > > > > > > +	 * NNP:  Operation not permitted for caller.
> > > > > > > > +	 * nosuid:  Permission denied to file.
> > > > > > > > +	 */
> > > > > > > > +	if (nnp)
> > > > > > > > +		return -EPERM;
> > > > > > > > +	return -EACCES;
> > > > > > > >  }
> > > > > > > >  
> > > > > > > >  static int selinux_bprm_set_creds(struct linux_binprm
> > > > > > > > *bprm)
> > > > > > > > diff --git a/security/selinux/include/classmap.h
> > > > > > > > b/security/selinux/include/classmap.h
> > > > > > > > index b9fe343..7fde56d 100644
> > > > > > > > --- a/security/selinux/include/classmap.h
> > > > > > > > +++ b/security/selinux/include/classmap.h
> > > > > > > > @@ -47,7 +47,7 @@ struct security_class_mapping
> > > > > > > > secclass_map[]
> > > > > > > > = {
> > > > > > > >  	    "getattr", "setexec", "setfscreate",
> > > > > > > > "noatsecure",
> > > > > > > > "siginh",
> > > > > > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > > > > > "setcurrent",
> > > > > > > >  	    "execmem", "execstack", "execheap",
> > > > > > > > "setkeycreate",
> > > > > > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > > > > > +	    "setsockcreate", "getrlimit",
> > > > > > > > "nnp_transition",
> > > > > > > > NULL }
> > > > > > > > },
> > > > > > > >  	{ "system",
> > > > > > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > > > > > >  	    "syslog_console", "module_request",
> > > > > > > > "module_load",
> > > > > > > > NULL
> > > > > > > > } },
> > > > > > > > diff --git a/security/selinux/include/security.h
> > > > > > > > b/security/selinux/include/security.h
> > > > > > > > index e91f08c..88efb1b 100644
> > > > > > > > --- a/security/selinux/include/security.h
> > > > > > > > +++ b/security/selinux/include/security.h
> > > > > > > > @@ -73,6 +73,7 @@ enum {
> > > > > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > > > > >  };
> > > > > > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX
> > > > > > > > -
> > > > > > > > 1)
> > > > > > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > > > > > >  extern int selinux_policycap_extsockclass;
> > > > > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > > > > +extern int selinux_policycap_nnptransition;
> > > > > > > >  
> > > > > > > >  /*
> > > > > > > >   * type_datum properties
> > > > > > > > diff --git a/security/selinux/ss/services.c
> > > > > > > > b/security/selinux/ss/services.c
> > > > > > > > index 2f02fa6..2faf47a 100644
> > > > > > > > --- a/security/selinux/ss/services.c
> > > > > > > > +++ b/security/selinux/ss/services.c
> > > > > > > > @@ -76,7 +76,8 @@ char
> > > > > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > > > > > >  	"open_perms",
> > > > > > > >  	"extended_socket_class",
> > > > > > > >  	"always_check_network",
> > > > > > > > -	"cgroup_seclabel"
> > > > > > > > +	"cgroup_seclabel",
> > > > > > > > +	"nnp_transition"
> > > > > > > >  };
> > > > > > > >  
> > > > > > > >  int selinux_policycap_netpeer;
> > > > > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > > > > >  int selinux_policycap_extsockclass;
> > > > > > > >  int selinux_policycap_alwaysnetwork;
> > > > > > > >  int selinux_policycap_cgroupseclabel;
> > > > > > > > +int selinux_policycap_nnptransition;
> > > > > > > >  
> > > > > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > > > > >  
> > > > > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > > > > security_load_policycaps(void)
> > > > > > > >  	selinux_policycap_cgroupseclabel =
> > > > > > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > > > > > >  				POLICYDB_CAPABILITY_CGROUP
> > > > > > > > SECL
> > > > > > > > ABEL);
> > > > > > > > +	selinux_policycap_nnptransition =
> > > > > > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > > > > > +				POLICYDB_CAPABILITY_NNPTRA
> > > > > > > > NSIT
> > > > > > > > ION);
> > > > > > > >  
> > > > > > > >  	for (i = 0; i <
> > > > > > > > ARRAY_SIZE(selinux_policycap_names);
> > > > > > > > i++)
> > > > > > > >  		pr_info("SELinux:  policy capability
> > > > > > > > %s=%d\n",
> > > > > > 
> > > > > > -- 
> > > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > > > > 6B02
> > > > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
> > > > > > C7B6
> > > > > > B02
> > > > > > Dominick Grift
> > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 22095 bytes --]

On Wed, Jul 12, 2017 at 03:38:28PM +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote:
> > > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote:
> > > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote:
> > > > > > > > > As systemd ramps up enabling NoNewPrivileges (either
> > > > > > > > > explicitly
> > > > > > > > > in
> > > > > > > > > service unit files or as a side effect of other security-
> > > > > > > > > related
> > > > > > > > > settings in service unit files), we're increasingly running
> > > > > > > > > afoul of
> > > > > > > > > its interactions with SELinux.
> > > > > > > > > 
> > > > > > > > > The end result is bad for the security of both SELinux-
> > > > > > > > > disabled 
> > > > > > > > > and
> > > > > > > > > SELinux-enabled systems.  Packagers have to turn off these
> > > > > > > > > options in the unit files to preserve SELinux domain
> > > > > > > > > transitions.  For
> > > > > > > > > users who choose to disable SELinux, this means that they
> > > > > > > > > miss
> > > > > > > > > out on
> > > > > > > > > at least having the systemd-supported protections.  For
> > > > > > > > > users
> > > > > > > > > who
> > > > > > > > > keep
> > > > > > > > > SELinux enabled, they may still be missing out on some
> > > > > > > > > protections
> > > > > > > > > because it isn't necessarily guaranteed that the SELinux
> > > > > > > > > policy
> > > > > > > > > for
> > > > > > > > > that service provides the same protections in all cases.
> > > > > > > > > 
> > > > > > > > > Our options seem to be:
> > > > > > > > > 
> > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to
> > > > > > > > > remove
> > > > > > > > > default protection settings from upstream package unit
> > > > > > > > > files in
> > > > > > > > > order
> > > > > > > > > to have them work with SELinux (and not just
> > > > > > > > > NoNewPrivileges=
> > > > > > > > > itself; increasingly systemd is enabling NNP as a side
> > > > > > > > > effect
> > > > > > > > > of
> > > > > > > > > other
> > > > > > > > > unit file options, even seemingly unrelated ones like
> > > > > > > > > PrivateDevices).
> > > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users
> > > > > > > > > may
> > > > > > > > > lose
> > > > > > > > > (depending on whether SELinux policy provides equivalent or
> > > > > > > > > better guarantees).
> > > > > > > > > 
> > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux-
> > > > > > > > > enabled
> > > > > > > > > systems.  Unit files can be left unmodified from
> > > > > > > > > upstream.  SELinux-
> > > > > > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > > > > > 
> > > > > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > > > > transitions
> > > > > > > > > under
> > > > > > > > > NNP.
> > > > > > > > > Unit files can be left unmodified from upstream. SELinux-
> > > > > > > > > disabled
> > > > > > > > > users
> > > > > > > > > win.  SELinux-enabled users get to benefit from systemd-
> > > > > > > > > provided
> > > > > > > > > protections.  However, this option is impractical to
> > > > > > > > > implement
> > > > > > > > > in
> > > > > > > > > policy
> > > > > > > > > currently, since typebounds requires us to ensure that each
> > > > > > > > > domain is
> > > > > > > > > allowed everything all of its descendant domains are
> > > > > > > > > allowed,
> > > > > > > > > and
> > > > > > > > > this
> > > > > > > > > has to be repeated for the entire chain of domain
> > > > > > > > > transitions.  There
> > > > > > > > > is
> > > > > > > > > no way to clone all allow rules from children to the parent
> > > > > > > > > in
> > > > > > > > > policy
> > > > > > > > > currently, and it is doubtful that doing so would be
> > > > > > > > > desirable
> > > > > > > > > even
> > > > > > > > > if
> > > > > > > > > it were practical, as it requires leaking permissions to
> > > > > > > > > objects and
> > > > > > > > > operations into parent domains that could weaken their own
> > > > > > > > > security
> > > > > > > > > in
> > > > > > > > > order to allow them to the children (e.g. if a child
> > > > > > > > > requires
> > > > > > > > > execmem
> > > > > > > > > permission, then so does the parent; if a child requires
> > > > > > > > > read
> > > > > > > > > to a
> > > > > > > > > symbolic
> > > > > > > > > link or temporary file that it can write, then so does the
> > > > > > > > > parent,
> > > > > > > > > ...).
> > > > > > > > > 
> > > > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't
> > > > > > > > > have
> > > > > > > > > to
> > > > > > > > > make a choice between them. Introduce a new policy
> > > > > > > > > capability
> > > > > > > > > that
> > > > > > > > > causes the ability to transition under NNP to be based on a
> > > > > > > > > new
> > > > > > > > > permission
> > > > > > > > > check between the old and new contexts rather than
> > > > > > > > > typebounds.  Domain
> > > > > > > > > transitions can then be allowed in policy without requiring
> > > > > > > > > the
> > > > > > > > > parent
> > > > > > > > > to be a strict superset of all of its children.  The
> > > > > > > > > rationale
> > > > > > > > > for
> > > > > > > > > this
> > > > > > > > > divergence from NNP behavior for capabilities is that
> > > > > > > > > SELinux
> > > > > > > > > permissions
> > > > > > > > > are substantially broader than just capabilities (they
> > > > > > > > > express
> > > > > > > > > a full
> > > > > > > > > access matrix, not just privileges) and can only be used to
> > > > > > > > > further
> > > > > > > > > restrict capabilities, not grant them beyond what is
> > > > > > > > > already
> > > > > > > > > permitted.
> > > > > > > > > Unit files can be left unmodified from upstream.  SELinux-
> > > > > > > > > disabled
> > > > > > > > > users
> > > > > > > > > win.  SELinux-enabled users can benefit from systemd-
> > > > > > > > > provided
> > > > > > > > > protections
> > > > > > > > > and policy won't need to radically change.
> > > > > > > > > 
> > > > > > > > > This change takes the last approach above, as it seems to
> > > > > > > > > be
> > > > > > > > > the
> > > > > > > > > best option.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > > > > ---
> > > > > > > > >  security/selinux/hooks.c            | 41
> > > > > > > > > ++++++++++++++++++++++++---
> > > > > > > > > ----------
> > > > > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > > > > >  security/selinux/include/security.h |  2 ++
> > > > > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/security/selinux/hooks.c
> > > > > > > > > b/security/selinux/hooks.c
> > > > > > > > > index 3a06afb..f0c11c2 100644
> > > > > > > > > --- a/security/selinux/hooks.c
> > > > > > > > > +++ b/security/selinux/hooks.c
> > > > > > > > > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const
> > > > > > > > > struct
> > > > > > > > > linux_binprm *bprm,
> > > > > > > > >  		return 0; /* No change in credentials */
> > > > > > > > >  
> > > > > > > > >  	/*
> > > > > > > > > -	 * The only transitions we permit under NNP or
> > > > > > > > > nosuid
> > > > > > > > > -	 * are transitions to bounded SIDs, i.e. SIDs that
> > > > > > > > > are
> > > > > > > > > -	 * guaranteed to only be allowed a subset of the
> > > > > > > > > permissions
> > > > > > > > > -	 * of the current SID.
> > > > > > > > > +	 * If the policy enables the nnp_transition policy
> > > > > > > > > capability,
> > > > > > > > > +	 * then we permit transitions under NNP or nosuid
> > > > > > > > > if
> > > > > > > > > the
> > > > > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > > > > permission
> > > > > > > > > between
> > > > > > > > > +	 * the old and new contexts.
> > > > > > > > >  	 */
> > > > > > > > > -	rc = security_bounded_transition(old_tsec->sid,
> > > > > > > > > new_tsec-
> > > > > > > > > > sid);
> > > > > > > > > 
> > > > > > > > > -	if (rc) {
> > > > > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > > > > +		rc = avc_has_perm(old_tsec->sid, new_tsec-
> > > > > > > > > > sid,
> > > > > > > > > 
> > > > > > > > > +				  SECCLASS_PROCESS,
> > > > > > > > > +				  PROCESS__NNP_TRANSITION,
> > > > > > > > > NULL);
> > > > > > > > > +		if (!rc)
> > > > > > > > > +			return 0;
> > > > > > > > > +	} else {
> > > > > > > > >  		/*
> > > > > > > > > -		 * On failure, preserve the errno values
> > > > > > > > > for
> > > > > > > > > NNP vs
> > > > > > > > > nosuid.
> > > > > > > > > -		 * NNP:  Operation not permitted for
> > > > > > > > > caller.
> > > > > > > > > -		 * nosuid:  Permission denied to file.
> > > > > > > > > +		 * Otherwise, the only transitions we
> > > > > > > > > permit
> > > > > > > > > under
> > > > > > > > > NNP or nosuid
> > > > > > > > > +		 * are transitions to bounded SIDs, i.e.
> > > > > > > > > SIDs
> > > > > > > > > that
> > > > > > > > > are
> > > > > > > > > +		 * guaranteed to only be allowed a subset
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > permissions
> > > > > > > > > +		 * of the current SID.
> > > > > > > > >  		 */
> > > > > > > > > -		if (nnp)
> > > > > > > > > -			return -EPERM;
> > > > > > > > > -		else
> > > > > > > > > -			return -EACCES;
> > > > > > > > > +		rc = security_bounded_transition(old_tsec-
> > > > > > > > > > sid,
> > > > > > > > > 
> > > > > > > > > new_tsec->sid);
> > > > > > > > > +		if (!rc)
> > > > > > > > > +			return 0;
> > > > > > > > 
> > > > > > > > NB: As currently written, this logic means that if you enable
> > > > > > > > the
> > > > > > > > new
> > > > > > > > policy capability, the only way to allow a transition under
> > > > > > > > NNP
> > > > > > > > is by
> > > > > > > > allowing nnp_transition permission between the old and new
> > > > > > > > domains. The
> > > > > > > > alternative would be to fall back to checking for a bounded
> > > > > > > > SID
> > > > > > > > if
> > > > > > > > nnp_transition permission is not allowed. The former approach
> > > > > > > > has
> > > > > > > > the
> > > > > > > > advantage of being simpler (only a single check with a single
> > > > > > > > audit
> > > > > > > > message), but means that you can't mix usage of bounded SIDs
> > > > > > > > and
> > > > > > > > nnp_transition permission as a means of allowing a
> > > > > > > > transitions
> > > > > > > > under
> > > > > > > > NNP within the same policy.  The latter approach provides
> > > > > > > > more
> > > > > > > > flexibility / compatibility but will end up producing two
> > > > > > > > audit
> > > > > > > > messages in the case where the transition is denied by both
> > > > > > > > checks: an
> > > > > > > > AVC message for the permission denial and a SELINUX_ERR
> > > > > > > > message
> > > > > > > > for the
> > > > > > > > security_bounded_transition failure, which might be confusing
> > > > > > > > to
> > > > > > > > users
> > > > > > > > (but probably not; they'll likely just feed the AVC through
> > > > > > > > audit2allow
> > > > > > > > and be done with it).  Thoughts?
> > > > > > > 
> > > > > > > I think the current implementation is fine if i understand
> > > > > > > correctly:
> > > > > > > 
> > > > > > > 1. With the policy capability disabled the behavior doesnt
> > > > > > > change,
> > > > > > > so if you dont want the current behavior (type_bounds) then
> > > > > > > just to
> > > > > > > enable the polcap
> > > > > > > 2. If you enable the policy capability then you decided to
> > > > > > > leverage
> > > > > > > nnp_transition instead of the current behavior
> > > > > > > 
> > > > > > > Theres plenty flexibility with this approach i would argue
> > > > > > 
> > > > > > Hmm. that came out wrong:
> > > > > > 
> > > > > > 1. without nnptransition polcap: everything stays the same
> > > > > > 2. with nnptransition polcap: you choose nnp_transition over
> > > > > > current
> > > > > > type_bounds behavior
> > > > > 
> > > > > Yes, that's correct. It is somewhat limiting in that if you want to
> > > > > leverage nnp_transition at all, you have to give up using
> > > > > typebounds
> > > > > entirely for allowing NNP transitions.  So, let's say there is an
> > > > > existing policy module that defines a typebounds in order to allow
> > > > > a
> > > > > NNP transition, and then another policy module decides to enable
> > > > > the
> > > > > policy capability and leverage nnp_transition permission to allow
> > > > > another NNP transition that wouldn't work under typebounds.  The
> > > > > first
> > > > > one will break under the former approach, while it would keep
> > > > > working
> > > > > under the latter approach. Not sure if that's a real concern or
> > > > > just a
> > > > > contrived one.  Let's say someone writes a third party policy
> > > > > module
> > > > > using typebounds for this purpose on Fedora today, and then updates
> > > > > to
> > > > > a new version of Fedora that enables the policy capability and
> > > > > leverages nnp_transition in its policy to allow such
> > > > > transitions.  Now
> > > > > that third party policy module will stop working (it would need to
> > > > > be
> > > > > changed to allow nnp_transition explicitly).
> > > > 
> > > > Would this affect the requirement of typebounds by for example
> > > > mod_selinux? I think that apache module also requires typebounds but
> > > > not for NNP AFAIK (that stuff predates it i believe)
> > > 
> > > No, this doesn't affect that.  That's a security_bounded_transition()
> > > check in selinux_setprocattr() for writes to /proc/self/attr/current if
> > > the process is multi-threaded.
> > > 
> > > > I prefer this implementation if this implementation is reasonably
> > > > possible. I dont believe that there are any third party modules that
> > > > support NNP (its too un-usable and hard to write)
> > > > 
> > > > I wont be leveraging nnp_transition or type_bounds for NNP BTW. I
> > > > will just contrinue removing the NNP= for systemd service units.
> > > 
> > > Note that it isn't sufficient to just remove NoNewPrivileges= from the
> > > unit file; you also have to remove any other options that implicitly
> > > enable NNP, which seems to be growing.  For example, any of the
> > > following will now enable NNP too as a side effect:
> > > SystemCallFilter=, SystemCallArchitectures=, RestrictAddressFamilies=,
> > > RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
> > > ProtectKernelModules=, MemoryDenyWriteExecute=, or RestrictRealtime= 
> > 
> > Are you sure because if that was the case I probably would have noticed?
> 
> Hmm.. man systemd.exec does say that its implied. It is strange that i haven't encountered it.
> 
> Why would nnp have to be implied for for example ProtectKernelTunables?
> 
> This makes things really ugly ...

I am not seeying this in systemd 233. for example systemd-logind has a few of the above mentioned, yet i have no type bounds and there arent any selinux_err or anything:

CapabilityBoundingSet=CAP_SYS_ADMIN
PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
ProtectSystem=yes
ProtectHome=yes
ProtectControlGroups=yes
ProtectKernelTunables=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_UNIX
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount @obsolete @raw-io

> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > >  	}
> > > > > > > > > -	return 0;
> > > > > > > > > +
> > > > > > > > > +	/*
> > > > > > > > > +	 * On failure, preserve the errno values for NNP
> > > > > > > > > vs
> > > > > > > > > nosuid.
> > > > > > > > > +	 * NNP:  Operation not permitted for caller.
> > > > > > > > > +	 * nosuid:  Permission denied to file.
> > > > > > > > > +	 */
> > > > > > > > > +	if (nnp)
> > > > > > > > > +		return -EPERM;
> > > > > > > > > +	return -EACCES;
> > > > > > > > >  }
> > > > > > > > >  
> > > > > > > > >  static int selinux_bprm_set_creds(struct linux_binprm
> > > > > > > > > *bprm)
> > > > > > > > > diff --git a/security/selinux/include/classmap.h
> > > > > > > > > b/security/selinux/include/classmap.h
> > > > > > > > > index b9fe343..7fde56d 100644
> > > > > > > > > --- a/security/selinux/include/classmap.h
> > > > > > > > > +++ b/security/selinux/include/classmap.h
> > > > > > > > > @@ -47,7 +47,7 @@ struct security_class_mapping
> > > > > > > > > secclass_map[]
> > > > > > > > > = {
> > > > > > > > >  	    "getattr", "setexec", "setfscreate",
> > > > > > > > > "noatsecure",
> > > > > > > > > "siginh",
> > > > > > > > >  	    "setrlimit", "rlimitinh", "dyntransition",
> > > > > > > > > "setcurrent",
> > > > > > > > >  	    "execmem", "execstack", "execheap",
> > > > > > > > > "setkeycreate",
> > > > > > > > > -	    "setsockcreate", "getrlimit", NULL } },
> > > > > > > > > +	    "setsockcreate", "getrlimit",
> > > > > > > > > "nnp_transition",
> > > > > > > > > NULL }
> > > > > > > > > },
> > > > > > > > >  	{ "system",
> > > > > > > > >  	  { "ipc_info", "syslog_read", "syslog_mod",
> > > > > > > > >  	    "syslog_console", "module_request",
> > > > > > > > > "module_load",
> > > > > > > > > NULL
> > > > > > > > > } },
> > > > > > > > > diff --git a/security/selinux/include/security.h
> > > > > > > > > b/security/selinux/include/security.h
> > > > > > > > > index e91f08c..88efb1b 100644
> > > > > > > > > --- a/security/selinux/include/security.h
> > > > > > > > > +++ b/security/selinux/include/security.h
> > > > > > > > > @@ -73,6 +73,7 @@ enum {
> > > > > > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > > > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > > > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > > > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > > > > > >  };
> > > > > > > > >  #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX
> > > > > > > > > -
> > > > > > > > > 1)
> > > > > > > > > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > > > > > > > >  extern int selinux_policycap_extsockclass;
> > > > > > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > > > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > > > > > +extern int selinux_policycap_nnptransition;
> > > > > > > > >  
> > > > > > > > >  /*
> > > > > > > > >   * type_datum properties
> > > > > > > > > diff --git a/security/selinux/ss/services.c
> > > > > > > > > b/security/selinux/ss/services.c
> > > > > > > > > index 2f02fa6..2faf47a 100644
> > > > > > > > > --- a/security/selinux/ss/services.c
> > > > > > > > > +++ b/security/selinux/ss/services.c
> > > > > > > > > @@ -76,7 +76,8 @@ char
> > > > > > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > > > > > > > >  	"open_perms",
> > > > > > > > >  	"extended_socket_class",
> > > > > > > > >  	"always_check_network",
> > > > > > > > > -	"cgroup_seclabel"
> > > > > > > > > +	"cgroup_seclabel",
> > > > > > > > > +	"nnp_transition"
> > > > > > > > >  };
> > > > > > > > >  
> > > > > > > > >  int selinux_policycap_netpeer;
> > > > > > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > > > > > >  int selinux_policycap_extsockclass;
> > > > > > > > >  int selinux_policycap_alwaysnetwork;
> > > > > > > > >  int selinux_policycap_cgroupseclabel;
> > > > > > > > > +int selinux_policycap_nnptransition;
> > > > > > > > >  
> > > > > > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > > > > > >  
> > > > > > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > > > > > security_load_policycaps(void)
> > > > > > > > >  	selinux_policycap_cgroupseclabel =
> > > > > > > > >  		ebitmap_get_bit(&policydb.policycaps,
> > > > > > > > >  				POLICYDB_CAPABILITY_CGROUP
> > > > > > > > > SECL
> > > > > > > > > ABEL);
> > > > > > > > > +	selinux_policycap_nnptransition =
> > > > > > > > > +		ebitmap_get_bit(&policydb.policycaps,
> > > > > > > > > +				POLICYDB_CAPABILITY_NNPTRA
> > > > > > > > > NSIT
> > > > > > > > > ION);
> > > > > > > > >  
> > > > > > > > >  	for (i = 0; i <
> > > > > > > > > ARRAY_SIZE(selinux_policycap_names);
> > > > > > > > > i++)
> > > > > > > > >  		pr_info("SELinux:  policy capability
> > > > > > > > > %s=%d\n",
> > > > > > > 
> > > > > > > -- 
> > > > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > > > > > 6B02
> > > > > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2
> > > > > > > C7B6
> > > > > > > B02
> > > > > > > Dominick Grift
> > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > > > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Wed, 2017-07-12 at 15:38 +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift
> > > > > > wrote:
> > > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley
> > > > > > > > wrote:
> > > > > > > > > As systemd ramps up enabling NoNewPrivileges (either
> > > > > > > > > explicitly
> > > > > > > > > in
> > > > > > > > > service unit files or as a side effect of other
> > > > > > > > > security-
> > > > > > > > > related
> > > > > > > > > settings in service unit files), we're increasingly
> > > > > > > > > running
> > > > > > > > > afoul of
> > > > > > > > > its interactions with SELinux.
> > > > > > > > > 
> > > > > > > > > The end result is bad for the security of both
> > > > > > > > > SELinux-
> > > > > > > > > disabled 
> > > > > > > > > and
> > > > > > > > > SELinux-enabled systems.  Packagers have to turn off
> > > > > > > > > these
> > > > > > > > > options in the unit files to preserve SELinux domain
> > > > > > > > > transitions.  For
> > > > > > > > > users who choose to disable SELinux, this means that
> > > > > > > > > they
> > > > > > > > > miss
> > > > > > > > > out on
> > > > > > > > > at least having the systemd-supported
> > > > > > > > > protections.  For
> > > > > > > > > users
> > > > > > > > > who
> > > > > > > > > keep
> > > > > > > > > SELinux enabled, they may still be missing out on
> > > > > > > > > some
> > > > > > > > > protections
> > > > > > > > > because it isn't necessarily guaranteed that the
> > > > > > > > > SELinux
> > > > > > > > > policy
> > > > > > > > > for
> > > > > > > > > that service provides the same protections in all
> > > > > > > > > cases.
> > > > > > > > > 
> > > > > > > > > Our options seem to be:
> > > > > > > > > 
> > > > > > > > > 1) Just keep on the way we are now, i.e. packagers
> > > > > > > > > have to
> > > > > > > > > remove
> > > > > > > > > default protection settings from upstream package
> > > > > > > > > unit
> > > > > > > > > files in
> > > > > > > > > order
> > > > > > > > > to have them work with SELinux (and not just
> > > > > > > > > NoNewPrivileges=
> > > > > > > > > itself; increasingly systemd is enabling NNP as a
> > > > > > > > > side
> > > > > > > > > effect
> > > > > > > > > of
> > > > > > > > > other
> > > > > > > > > unit file options, even seemingly unrelated ones like
> > > > > > > > > PrivateDevices).
> > > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled 
> > > > > > > > > users
> > > > > > > > > may
> > > > > > > > > lose
> > > > > > > > > (depending on whether SELinux policy provides
> > > > > > > > > equivalent or
> > > > > > > > > better guarantees).
> > > > > > > > > 
> > > > > > > > > 2) Change systemd to automatically disable NNP on
> > > > > > > > > SELinux-
> > > > > > > > > enabled
> > > > > > > > > systems.  Unit files can be left unmodified from
> > > > > > > > > upstream.  SELinux-
> > > > > > > > > disabled users win.  SELinux-enabled users may lose.
> > > > > > > > > 
> > > > > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > > > > transitions
> > > > > > > > > under
> > > > > > > > > NNP.
> > > > > > > > > Unit files can be left unmodified from upstream.
> > > > > > > > > SELinux-
> > > > > > > > > disabled
> > > > > > > > > users
> > > > > > > > > win.  SELinux-enabled users get to benefit from
> > > > > > > > > systemd-
> > > > > > > > > provided
> > > > > > > > > protections.  However, this option is impractical to
> > > > > > > > > implement
> > > > > > > > > in
> > > > > > > > > policy
> > > > > > > > > currently, since typebounds requires us to ensure
> > > > > > > > > that each
> > > > > > > > > domain is
> > > > > > > > > allowed everything all of its descendant domains are
> > > > > > > > > allowed,
> > > > > > > > > and
> > > > > > > > > this
> > > > > > > > > has to be repeated for the entire chain of domain
> > > > > > > > > transitions.  There
> > > > > > > > > is
> > > > > > > > > no way to clone all allow rules from children to the
> > > > > > > > > parent
> > > > > > > > > in
> > > > > > > > > policy
> > > > > > > > > currently, and it is doubtful that doing so would be
> > > > > > > > > desirable
> > > > > > > > > even
> > > > > > > > > if
> > > > > > > > > it were practical, as it requires leaking permissions
> > > > > > > > > to
> > > > > > > > > objects and
> > > > > > > > > operations into parent domains that could weaken
> > > > > > > > > their own
> > > > > > > > > security
> > > > > > > > > in
> > > > > > > > > order to allow them to the children (e.g. if a child
> > > > > > > > > requires
> > > > > > > > > execmem
> > > > > > > > > permission, then so does the parent; if a child
> > > > > > > > > requires
> > > > > > > > > read
> > > > > > > > > to a
> > > > > > > > > symbolic
> > > > > > > > > link or temporary file that it can write, then so
> > > > > > > > > does the
> > > > > > > > > parent,
> > > > > > > > > ...).
> > > > > > > > > 
> > > > > > > > > 4) Decouple NNP from SELinux transitions, so that we
> > > > > > > > > don't
> > > > > > > > > have
> > > > > > > > > to
> > > > > > > > > make a choice between them. Introduce a new policy
> > > > > > > > > capability
> > > > > > > > > that
> > > > > > > > > causes the ability to transition under NNP to be
> > > > > > > > > based on a
> > > > > > > > > new
> > > > > > > > > permission
> > > > > > > > > check between the old and new contexts rather than
> > > > > > > > > typebounds.  Domain
> > > > > > > > > transitions can then be allowed in policy without
> > > > > > > > > requiring
> > > > > > > > > the
> > > > > > > > > parent
> > > > > > > > > to be a strict superset of all of its children.  The
> > > > > > > > > rationale
> > > > > > > > > for
> > > > > > > > > this
> > > > > > > > > divergence from NNP behavior for capabilities is that
> > > > > > > > > SELinux
> > > > > > > > > permissions
> > > > > > > > > are substantially broader than just capabilities
> > > > > > > > > (they
> > > > > > > > > express
> > > > > > > > > a full
> > > > > > > > > access matrix, not just privileges) and can only be
> > > > > > > > > used to
> > > > > > > > > further
> > > > > > > > > restrict capabilities, not grant them beyond what is
> > > > > > > > > already
> > > > > > > > > permitted.
> > > > > > > > > Unit files can be left unmodified from
> > > > > > > > > upstream.  SELinux-
> > > > > > > > > disabled
> > > > > > > > > users
> > > > > > > > > win.  SELinux-enabled users can benefit from systemd-
> > > > > > > > > provided
> > > > > > > > > protections
> > > > > > > > > and policy won't need to radically change.
> > > > > > > > > 
> > > > > > > > > This change takes the last approach above, as it
> > > > > > > > > seems to
> > > > > > > > > be
> > > > > > > > > the
> > > > > > > > > best option.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > > > > ---
> > > > > > > > >  security/selinux/hooks.c            | 41
> > > > > > > > > ++++++++++++++++++++++++---
> > > > > > > > > ----------
> > > > > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > > > > >  security/selinux/include/security.h |  2 ++
> > > > > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/security/selinux/hooks.c
> > > > > > > > > b/security/selinux/hooks.c
> > > > > > > > > index 3a06afb..f0c11c2 100644
> > > > > > > > > --- a/security/selinux/hooks.c
> > > > > > > > > +++ b/security/selinux/hooks.c
> > > > > > > > > @@ -2326,24 +2326,37 @@ static int
> > > > > > > > > check_nnp_nosuid(const
> > > > > > > > > struct
> > > > > > > > > linux_binprm *bprm,
> > > > > > > > >  		return 0; /* No change in
> > > > > > > > > credentials */
> > > > > > > > >  
> > > > > > > > >  	/*
> > > > > > > > > -	 * The only transitions we permit under NNP
> > > > > > > > > or
> > > > > > > > > nosuid
> > > > > > > > > -	 * are transitions to bounded SIDs, i.e.
> > > > > > > > > SIDs that
> > > > > > > > > are
> > > > > > > > > -	 * guaranteed to only be allowed a subset of
> > > > > > > > > the
> > > > > > > > > permissions
> > > > > > > > > -	 * of the current SID.
> > > > > > > > > +	 * If the policy enables the nnp_transition
> > > > > > > > > policy
> > > > > > > > > capability,
> > > > > > > > > +	 * then we permit transitions under NNP or
> > > > > > > > > nosuid
> > > > > > > > > if
> > > > > > > > > the
> > > > > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > > > > permission
> > > > > > > > > between
> > > > > > > > > +	 * the old and new contexts.
> > > > > > > > >  	 */
> > > > > > > > > -	rc = security_bounded_transition(old_tsec-
> > > > > > > > > >sid,
> > > > > > > > > new_tsec-
> > > > > > > > > > sid);
> > > > > > > > > 
> > > > > > > > > -	if (rc) {
> > > > > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > > > > +		rc = avc_has_perm(old_tsec->sid,
> > > > > > > > > new_tsec-
> > > > > > > > > > sid,
> > > > > > > > > 
> > > > > > > > > +				  SECCLASS_PROCESS,
> > > > > > > > > +				  PROCESS__NNP_TRANS
> > > > > > > > > ITION,
> > > > > > > > > NULL);
> > > > > > > > > +		if (!rc)
> > > > > > > > > +			return 0;
> > > > > > > > > +	} else {
> > > > > > > > >  		/*
> > > > > > > > > -		 * On failure, preserve the errno
> > > > > > > > > values
> > > > > > > > > for
> > > > > > > > > NNP vs
> > > > > > > > > nosuid.
> > > > > > > > > -		 * NNP:  Operation not permitted for
> > > > > > > > > caller.
> > > > > > > > > -		 * nosuid:  Permission denied to
> > > > > > > > > file.
> > > > > > > > > +		 * Otherwise, the only transitions
> > > > > > > > > we
> > > > > > > > > permit
> > > > > > > > > under
> > > > > > > > > NNP or nosuid
> > > > > > > > > +		 * are transitions to bounded SIDs,
> > > > > > > > > i.e.
> > > > > > > > > SIDs
> > > > > > > > > that
> > > > > > > > > are
> > > > > > > > > +		 * guaranteed to only be allowed a
> > > > > > > > > subset
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > permissions
> > > > > > > > > +		 * of the current SID.
> > > > > > > > >  		 */
> > > > > > > > > -		if (nnp)
> > > > > > > > > -			return -EPERM;
> > > > > > > > > -		else
> > > > > > > > > -			return -EACCES;
> > > > > > > > > +		rc =
> > > > > > > > > security_bounded_transition(old_tsec-
> > > > > > > > > > sid,
> > > > > > > > > 
> > > > > > > > > new_tsec->sid);
> > > > > > > > > +		if (!rc)
> > > > > > > > > +			return 0;
> > > > > > > > 
> > > > > > > > NB: As currently written, this logic means that if you
> > > > > > > > enable
> > > > > > > > the
> > > > > > > > new
> > > > > > > > policy capability, the only way to allow a transition
> > > > > > > > under
> > > > > > > > NNP
> > > > > > > > is by
> > > > > > > > allowing nnp_transition permission between the old and
> > > > > > > > new
> > > > > > > > domains. The
> > > > > > > > alternative would be to fall back to checking for a
> > > > > > > > bounded
> > > > > > > > SID
> > > > > > > > if
> > > > > > > > nnp_transition permission is not allowed. The former
> > > > > > > > approach
> > > > > > > > has
> > > > > > > > the
> > > > > > > > advantage of being simpler (only a single check with a
> > > > > > > > single
> > > > > > > > audit
> > > > > > > > message), but means that you can't mix usage of bounded
> > > > > > > > SIDs
> > > > > > > > and
> > > > > > > > nnp_transition permission as a means of allowing a
> > > > > > > > transitions
> > > > > > > > under
> > > > > > > > NNP within the same policy.  The latter approach
> > > > > > > > provides
> > > > > > > > more
> > > > > > > > flexibility / compatibility but will end up producing
> > > > > > > > two
> > > > > > > > audit
> > > > > > > > messages in the case where the transition is denied by
> > > > > > > > both
> > > > > > > > checks: an
> > > > > > > > AVC message for the permission denial and a SELINUX_ERR
> > > > > > > > message
> > > > > > > > for the
> > > > > > > > security_bounded_transition failure, which might be
> > > > > > > > confusing
> > > > > > > > to
> > > > > > > > users
> > > > > > > > (but probably not; they'll likely just feed the AVC
> > > > > > > > through
> > > > > > > > audit2allow
> > > > > > > > and be done with it).  Thoughts?
> > > > > > > 
> > > > > > > I think the current implementation is fine if i
> > > > > > > understand
> > > > > > > correctly:
> > > > > > > 
> > > > > > > 1. With the policy capability disabled the behavior
> > > > > > > doesnt
> > > > > > > change,
> > > > > > > so if you dont want the current behavior (type_bounds)
> > > > > > > then
> > > > > > > just to
> > > > > > > enable the polcap
> > > > > > > 2. If you enable the policy capability then you decided
> > > > > > > to
> > > > > > > leverage
> > > > > > > nnp_transition instead of the current behavior
> > > > > > > 
> > > > > > > Theres plenty flexibility with this approach i would
> > > > > > > argue
> > > > > > 
> > > > > > Hmm. that came out wrong:
> > > > > > 
> > > > > > 1. without nnptransition polcap: everything stays the same
> > > > > > 2. with nnptransition polcap: you choose nnp_transition
> > > > > > over
> > > > > > current
> > > > > > type_bounds behavior
> > > > > 
> > > > > Yes, that's correct. It is somewhat limiting in that if you
> > > > > want to
> > > > > leverage nnp_transition at all, you have to give up using
> > > > > typebounds
> > > > > entirely for allowing NNP transitions.  So, let's say there
> > > > > is an
> > > > > existing policy module that defines a typebounds in order to
> > > > > allow
> > > > > a
> > > > > NNP transition, and then another policy module decides to
> > > > > enable
> > > > > the
> > > > > policy capability and leverage nnp_transition permission to
> > > > > allow
> > > > > another NNP transition that wouldn't work under
> > > > > typebounds.  The
> > > > > first
> > > > > one will break under the former approach, while it would keep
> > > > > working
> > > > > under the latter approach. Not sure if that's a real concern
> > > > > or
> > > > > just a
> > > > > contrived one.  Let's say someone writes a third party policy
> > > > > module
> > > > > using typebounds for this purpose on Fedora today, and then
> > > > > updates
> > > > > to
> > > > > a new version of Fedora that enables the policy capability
> > > > > and
> > > > > leverages nnp_transition in its policy to allow such
> > > > > transitions.  Now
> > > > > that third party policy module will stop working (it would
> > > > > need to
> > > > > be
> > > > > changed to allow nnp_transition explicitly).
> > > > 
> > > > Would this affect the requirement of typebounds by for example
> > > > mod_selinux? I think that apache module also requires
> > > > typebounds but
> > > > not for NNP AFAIK (that stuff predates it i believe)
> > > 
> > > No, this doesn't affect that.  That's a
> > > security_bounded_transition()
> > > check in selinux_setprocattr() for writes to
> > > /proc/self/attr/current if
> > > the process is multi-threaded.
> > > 
> > > > I prefer this implementation if this implementation is
> > > > reasonably
> > > > possible. I dont believe that there are any third party modules
> > > > that
> > > > support NNP (its too un-usable and hard to write)
> > > > 
> > > > I wont be leveraging nnp_transition or type_bounds for NNP BTW.
> > > > I
> > > > will just contrinue removing the NNP= for systemd service
> > > > units.
> > > 
> > > Note that it isn't sufficient to just remove NoNewPrivileges=
> > > from the
> > > unit file; you also have to remove any other options that
> > > implicitly
> > > enable NNP, which seems to be growing.  For example, any of the
> > > following will now enable NNP too as a side effect:
> > > SystemCallFilter=, SystemCallArchitectures=,
> > > RestrictAddressFamilies=,
> > > RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
> > > ProtectKernelModules=, MemoryDenyWriteExecute=, or
> > > RestrictRealtime= 
> > 
> > Are you sure because if that was the case I probably would have
> > noticed?
> 
> Hmm.. man systemd.exec does say that its implied. It is strange that
> i haven't encountered it.
> 
> Why would nnp have to be implied for for example
> ProtectKernelTunables?
> 
> This makes things really ugly ...

That's why I'm trying to resolve it on the SELinux side of things,
because I don't think it is workable to just disable all of these
options in unit files.  And I don't have any control over systemd.

Looks like systemd only enables NNP if one of those options is enabled
_and_ the process lacks CAP_SYS_ADMIN.  So you'll encounter it with
unit files that are configured to run as non-root or without
CAP_SYS_ADMIN.

I ran into this when someone raised a problem with radicale not
transitioning on the fedora selinux list and it turned out to be due to
PrivateDevices=true in combination with User=radicale in the unit file.

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Wed, 2017-07-12 at 15:42 +0200, Dominick Grift wrote:
> On Wed, Jul 12, 2017 at 03:38:28PM +0200, Dominick Grift wrote:
> > On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote:
> > > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote:
> > > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote:
> > > > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote:
> > > > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift
> > > > > > > wrote:
> > > > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen
> > > > > > > > Smalley
> > > > > > > > wrote:
> > > > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley
> > > > > > > > > wrote:
> > > > > > > > > > As systemd ramps up enabling NoNewPrivileges
> > > > > > > > > > (either
> > > > > > > > > > explicitly
> > > > > > > > > > in
> > > > > > > > > > service unit files or as a side effect of other
> > > > > > > > > > security-
> > > > > > > > > > related
> > > > > > > > > > settings in service unit files), we're increasingly
> > > > > > > > > > running
> > > > > > > > > > afoul of
> > > > > > > > > > its interactions with SELinux.
> > > > > > > > > > 
> > > > > > > > > > The end result is bad for the security of both
> > > > > > > > > > SELinux-
> > > > > > > > > > disabled 
> > > > > > > > > > and
> > > > > > > > > > SELinux-enabled systems.  Packagers have to turn
> > > > > > > > > > off these
> > > > > > > > > > options in the unit files to preserve SELinux
> > > > > > > > > > domain
> > > > > > > > > > transitions.  For
> > > > > > > > > > users who choose to disable SELinux, this means
> > > > > > > > > > that they
> > > > > > > > > > miss
> > > > > > > > > > out on
> > > > > > > > > > at least having the systemd-supported
> > > > > > > > > > protections.  For
> > > > > > > > > > users
> > > > > > > > > > who
> > > > > > > > > > keep
> > > > > > > > > > SELinux enabled, they may still be missing out on
> > > > > > > > > > some
> > > > > > > > > > protections
> > > > > > > > > > because it isn't necessarily guaranteed that the
> > > > > > > > > > SELinux
> > > > > > > > > > policy
> > > > > > > > > > for
> > > > > > > > > > that service provides the same protections in all
> > > > > > > > > > cases.
> > > > > > > > > > 
> > > > > > > > > > Our options seem to be:
> > > > > > > > > > 
> > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers
> > > > > > > > > > have to
> > > > > > > > > > remove
> > > > > > > > > > default protection settings from upstream package
> > > > > > > > > > unit
> > > > > > > > > > files in
> > > > > > > > > > order
> > > > > > > > > > to have them work with SELinux (and not just
> > > > > > > > > > NoNewPrivileges=
> > > > > > > > > > itself; increasingly systemd is enabling NNP as a
> > > > > > > > > > side
> > > > > > > > > > effect
> > > > > > > > > > of
> > > > > > > > > > other
> > > > > > > > > > unit file options, even seemingly unrelated ones
> > > > > > > > > > like
> > > > > > > > > > PrivateDevices).
> > > > > > > > > > SELinux-disabled users lose entirely, SELinux-
> > > > > > > > > > enabled users
> > > > > > > > > > may
> > > > > > > > > > lose
> > > > > > > > > > (depending on whether SELinux policy provides
> > > > > > > > > > equivalent or
> > > > > > > > > > better guarantees).
> > > > > > > > > > 
> > > > > > > > > > 2) Change systemd to automatically disable NNP on
> > > > > > > > > > SELinux-
> > > > > > > > > > enabled
> > > > > > > > > > systems.  Unit files can be left unmodified from
> > > > > > > > > > upstream.  SELinux-
> > > > > > > > > > disabled users win.  SELinux-enabled users may
> > > > > > > > > > lose.
> > > > > > > > > > 
> > > > > > > > > > 3) Try to use typebounds, since we allow bounded
> > > > > > > > > > transitions
> > > > > > > > > > under
> > > > > > > > > > NNP.
> > > > > > > > > > Unit files can be left unmodified from upstream.
> > > > > > > > > > SELinux-
> > > > > > > > > > disabled
> > > > > > > > > > users
> > > > > > > > > > win.  SELinux-enabled users get to benefit from
> > > > > > > > > > systemd-
> > > > > > > > > > provided
> > > > > > > > > > protections.  However, this option is impractical
> > > > > > > > > > to
> > > > > > > > > > implement
> > > > > > > > > > in
> > > > > > > > > > policy
> > > > > > > > > > currently, since typebounds requires us to ensure
> > > > > > > > > > that each
> > > > > > > > > > domain is
> > > > > > > > > > allowed everything all of its descendant domains
> > > > > > > > > > are
> > > > > > > > > > allowed,
> > > > > > > > > > and
> > > > > > > > > > this
> > > > > > > > > > has to be repeated for the entire chain of domain
> > > > > > > > > > transitions.  There
> > > > > > > > > > is
> > > > > > > > > > no way to clone all allow rules from children to
> > > > > > > > > > the parent
> > > > > > > > > > in
> > > > > > > > > > policy
> > > > > > > > > > currently, and it is doubtful that doing so would
> > > > > > > > > > be
> > > > > > > > > > desirable
> > > > > > > > > > even
> > > > > > > > > > if
> > > > > > > > > > it were practical, as it requires leaking
> > > > > > > > > > permissions to
> > > > > > > > > > objects and
> > > > > > > > > > operations into parent domains that could weaken
> > > > > > > > > > their own
> > > > > > > > > > security
> > > > > > > > > > in
> > > > > > > > > > order to allow them to the children (e.g. if a
> > > > > > > > > > child
> > > > > > > > > > requires
> > > > > > > > > > execmem
> > > > > > > > > > permission, then so does the parent; if a child
> > > > > > > > > > requires
> > > > > > > > > > read
> > > > > > > > > > to a
> > > > > > > > > > symbolic
> > > > > > > > > > link or temporary file that it can write, then so
> > > > > > > > > > does the
> > > > > > > > > > parent,
> > > > > > > > > > ...).
> > > > > > > > > > 
> > > > > > > > > > 4) Decouple NNP from SELinux transitions, so that
> > > > > > > > > > we don't
> > > > > > > > > > have
> > > > > > > > > > to
> > > > > > > > > > make a choice between them. Introduce a new policy
> > > > > > > > > > capability
> > > > > > > > > > that
> > > > > > > > > > causes the ability to transition under NNP to be
> > > > > > > > > > based on a
> > > > > > > > > > new
> > > > > > > > > > permission
> > > > > > > > > > check between the old and new contexts rather than
> > > > > > > > > > typebounds.  Domain
> > > > > > > > > > transitions can then be allowed in policy without
> > > > > > > > > > requiring
> > > > > > > > > > the
> > > > > > > > > > parent
> > > > > > > > > > to be a strict superset of all of its
> > > > > > > > > > children.  The
> > > > > > > > > > rationale
> > > > > > > > > > for
> > > > > > > > > > this
> > > > > > > > > > divergence from NNP behavior for capabilities is
> > > > > > > > > > that
> > > > > > > > > > SELinux
> > > > > > > > > > permissions
> > > > > > > > > > are substantially broader than just capabilities
> > > > > > > > > > (they
> > > > > > > > > > express
> > > > > > > > > > a full
> > > > > > > > > > access matrix, not just privileges) and can only be
> > > > > > > > > > used to
> > > > > > > > > > further
> > > > > > > > > > restrict capabilities, not grant them beyond what
> > > > > > > > > > is
> > > > > > > > > > already
> > > > > > > > > > permitted.
> > > > > > > > > > Unit files can be left unmodified from
> > > > > > > > > > upstream.  SELinux-
> > > > > > > > > > disabled
> > > > > > > > > > users
> > > > > > > > > > win.  SELinux-enabled users can benefit from
> > > > > > > > > > systemd-
> > > > > > > > > > provided
> > > > > > > > > > protections
> > > > > > > > > > and policy won't need to radically change.
> > > > > > > > > > 
> > > > > > > > > > This change takes the last approach above, as it
> > > > > > > > > > seems to
> > > > > > > > > > be
> > > > > > > > > > the
> > > > > > > > > > best option.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> > > > > > > > > > ---
> > > > > > > > > >  security/selinux/hooks.c            | 41
> > > > > > > > > > ++++++++++++++++++++++++---
> > > > > > > > > > ----------
> > > > > > > > > >  security/selinux/include/classmap.h |  2 +-
> > > > > > > > > >  security/selinux/include/security.h |  2 ++
> > > > > > > > > >  security/selinux/ss/services.c      |  7 ++++++-
> > > > > > > > > >  4 files changed, 36 insertions(+), 16 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/security/selinux/hooks.c
> > > > > > > > > > b/security/selinux/hooks.c
> > > > > > > > > > index 3a06afb..f0c11c2 100644
> > > > > > > > > > --- a/security/selinux/hooks.c
> > > > > > > > > > +++ b/security/selinux/hooks.c
> > > > > > > > > > @@ -2326,24 +2326,37 @@ static int
> > > > > > > > > > check_nnp_nosuid(const
> > > > > > > > > > struct
> > > > > > > > > > linux_binprm *bprm,
> > > > > > > > > >  		return 0; /* No change in
> > > > > > > > > > credentials */
> > > > > > > > > >  
> > > > > > > > > >  	/*
> > > > > > > > > > -	 * The only transitions we permit under
> > > > > > > > > > NNP or
> > > > > > > > > > nosuid
> > > > > > > > > > -	 * are transitions to bounded SIDs, i.e.
> > > > > > > > > > SIDs that
> > > > > > > > > > are
> > > > > > > > > > -	 * guaranteed to only be allowed a subset
> > > > > > > > > > of the
> > > > > > > > > > permissions
> > > > > > > > > > -	 * of the current SID.
> > > > > > > > > > +	 * If the policy enables the
> > > > > > > > > > nnp_transition policy
> > > > > > > > > > capability,
> > > > > > > > > > +	 * then we permit transitions under NNP or
> > > > > > > > > > nosuid
> > > > > > > > > > if
> > > > > > > > > > the
> > > > > > > > > > +	 * policy explicitly allows nnp_transition
> > > > > > > > > > permission
> > > > > > > > > > between
> > > > > > > > > > +	 * the old and new contexts.
> > > > > > > > > >  	 */
> > > > > > > > > > -	rc = security_bounded_transition(old_tsec-
> > > > > > > > > > >sid,
> > > > > > > > > > new_tsec-
> > > > > > > > > > > sid);
> > > > > > > > > > 
> > > > > > > > > > -	if (rc) {
> > > > > > > > > > +	if (selinux_policycap_nnptransition) {
> > > > > > > > > > +		rc = avc_has_perm(old_tsec->sid,
> > > > > > > > > > new_tsec-
> > > > > > > > > > > sid,
> > > > > > > > > > 
> > > > > > > > > > +				  SECCLASS_PROCESS
> > > > > > > > > > ,
> > > > > > > > > > +				  PROCESS__NNP_TRA
> > > > > > > > > > NSITION,
> > > > > > > > > > NULL);
> > > > > > > > > > +		if (!rc)
> > > > > > > > > > +			return 0;
> > > > > > > > > > +	} else {
> > > > > > > > > >  		/*
> > > > > > > > > > -		 * On failure, preserve the errno
> > > > > > > > > > values
> > > > > > > > > > for
> > > > > > > > > > NNP vs
> > > > > > > > > > nosuid.
> > > > > > > > > > -		 * NNP:  Operation not permitted
> > > > > > > > > > for
> > > > > > > > > > caller.
> > > > > > > > > > -		 * nosuid:  Permission denied to
> > > > > > > > > > file.
> > > > > > > > > > +		 * Otherwise, the only transitions
> > > > > > > > > > we
> > > > > > > > > > permit
> > > > > > > > > > under
> > > > > > > > > > NNP or nosuid
> > > > > > > > > > +		 * are transitions to bounded
> > > > > > > > > > SIDs, i.e.
> > > > > > > > > > SIDs
> > > > > > > > > > that
> > > > > > > > > > are
> > > > > > > > > > +		 * guaranteed to only be allowed a
> > > > > > > > > > subset
> > > > > > > > > > of
> > > > > > > > > > the
> > > > > > > > > > permissions
> > > > > > > > > > +		 * of the current SID.
> > > > > > > > > >  		 */
> > > > > > > > > > -		if (nnp)
> > > > > > > > > > -			return -EPERM;
> > > > > > > > > > -		else
> > > > > > > > > > -			return -EACCES;
> > > > > > > > > > +		rc =
> > > > > > > > > > security_bounded_transition(old_tsec-
> > > > > > > > > > > sid,
> > > > > > > > > > 
> > > > > > > > > > new_tsec->sid);
> > > > > > > > > > +		if (!rc)
> > > > > > > > > > +			return 0;
> > > > > > > > > 
> > > > > > > > > NB: As currently written, this logic means that if
> > > > > > > > > you enable
> > > > > > > > > the
> > > > > > > > > new
> > > > > > > > > policy capability, the only way to allow a transition
> > > > > > > > > under
> > > > > > > > > NNP
> > > > > > > > > is by
> > > > > > > > > allowing nnp_transition permission between the old
> > > > > > > > > and new
> > > > > > > > > domains. The
> > > > > > > > > alternative would be to fall back to checking for a
> > > > > > > > > bounded
> > > > > > > > > SID
> > > > > > > > > if
> > > > > > > > > nnp_transition permission is not allowed. The former
> > > > > > > > > approach
> > > > > > > > > has
> > > > > > > > > the
> > > > > > > > > advantage of being simpler (only a single check with
> > > > > > > > > a single
> > > > > > > > > audit
> > > > > > > > > message), but means that you can't mix usage of
> > > > > > > > > bounded SIDs
> > > > > > > > > and
> > > > > > > > > nnp_transition permission as a means of allowing a
> > > > > > > > > transitions
> > > > > > > > > under
> > > > > > > > > NNP within the same policy.  The latter approach
> > > > > > > > > provides
> > > > > > > > > more
> > > > > > > > > flexibility / compatibility but will end up producing
> > > > > > > > > two
> > > > > > > > > audit
> > > > > > > > > messages in the case where the transition is denied
> > > > > > > > > by both
> > > > > > > > > checks: an
> > > > > > > > > AVC message for the permission denial and a
> > > > > > > > > SELINUX_ERR
> > > > > > > > > message
> > > > > > > > > for the
> > > > > > > > > security_bounded_transition failure, which might be
> > > > > > > > > confusing
> > > > > > > > > to
> > > > > > > > > users
> > > > > > > > > (but probably not; they'll likely just feed the AVC
> > > > > > > > > through
> > > > > > > > > audit2allow
> > > > > > > > > and be done with it).  Thoughts?
> > > > > > > > 
> > > > > > > > I think the current implementation is fine if i
> > > > > > > > understand
> > > > > > > > correctly:
> > > > > > > > 
> > > > > > > > 1. With the policy capability disabled the behavior
> > > > > > > > doesnt
> > > > > > > > change,
> > > > > > > > so if you dont want the current behavior (type_bounds)
> > > > > > > > then
> > > > > > > > just to
> > > > > > > > enable the polcap
> > > > > > > > 2. If you enable the policy capability then you decided
> > > > > > > > to
> > > > > > > > leverage
> > > > > > > > nnp_transition instead of the current behavior
> > > > > > > > 
> > > > > > > > Theres plenty flexibility with this approach i would
> > > > > > > > argue
> > > > > > > 
> > > > > > > Hmm. that came out wrong:
> > > > > > > 
> > > > > > > 1. without nnptransition polcap: everything stays the
> > > > > > > same
> > > > > > > 2. with nnptransition polcap: you choose nnp_transition
> > > > > > > over
> > > > > > > current
> > > > > > > type_bounds behavior
> > > > > > 
> > > > > > Yes, that's correct. It is somewhat limiting in that if you
> > > > > > want to
> > > > > > leverage nnp_transition at all, you have to give up using
> > > > > > typebounds
> > > > > > entirely for allowing NNP transitions.  So, let's say there
> > > > > > is an
> > > > > > existing policy module that defines a typebounds in order
> > > > > > to allow
> > > > > > a
> > > > > > NNP transition, and then another policy module decides to
> > > > > > enable
> > > > > > the
> > > > > > policy capability and leverage nnp_transition permission to
> > > > > > allow
> > > > > > another NNP transition that wouldn't work under
> > > > > > typebounds.  The
> > > > > > first
> > > > > > one will break under the former approach, while it would
> > > > > > keep
> > > > > > working
> > > > > > under the latter approach. Not sure if that's a real
> > > > > > concern or
> > > > > > just a
> > > > > > contrived one.  Let's say someone writes a third party
> > > > > > policy
> > > > > > module
> > > > > > using typebounds for this purpose on Fedora today, and then
> > > > > > updates
> > > > > > to
> > > > > > a new version of Fedora that enables the policy capability
> > > > > > and
> > > > > > leverages nnp_transition in its policy to allow such
> > > > > > transitions.  Now
> > > > > > that third party policy module will stop working (it would
> > > > > > need to
> > > > > > be
> > > > > > changed to allow nnp_transition explicitly).
> > > > > 
> > > > > Would this affect the requirement of typebounds by for
> > > > > example
> > > > > mod_selinux? I think that apache module also requires
> > > > > typebounds but
> > > > > not for NNP AFAIK (that stuff predates it i believe)
> > > > 
> > > > No, this doesn't affect that.  That's a
> > > > security_bounded_transition()
> > > > check in selinux_setprocattr() for writes to
> > > > /proc/self/attr/current if
> > > > the process is multi-threaded.
> > > > 
> > > > > I prefer this implementation if this implementation is
> > > > > reasonably
> > > > > possible. I dont believe that there are any third party
> > > > > modules that
> > > > > support NNP (its too un-usable and hard to write)
> > > > > 
> > > > > I wont be leveraging nnp_transition or type_bounds for NNP
> > > > > BTW. I
> > > > > will just contrinue removing the NNP= for systemd service
> > > > > units.
> > > > 
> > > > Note that it isn't sufficient to just remove NoNewPrivileges=
> > > > from the
> > > > unit file; you also have to remove any other options that
> > > > implicitly
> > > > enable NNP, which seems to be growing.  For example, any of the
> > > > following will now enable NNP too as a side effect:
> > > > SystemCallFilter=, SystemCallArchitectures=,
> > > > RestrictAddressFamilies=,
> > > > RestrictNamespaces=, PrivateDevices=, ProtectKernelTunables=,
> > > > ProtectKernelModules=, MemoryDenyWriteExecute=, or
> > > > RestrictRealtime= 
> > > 
> > > Are you sure because if that was the case I probably would have
> > > noticed?
> > 
> > Hmm.. man systemd.exec does say that its implied. It is strange
> > that i haven't encountered it.
> > 
> > Why would nnp have to be implied for for example
> > ProtectKernelTunables?
> > 
> > This makes things really ugly ...
> 
> I am not seeying this in systemd 233. for example systemd-logind has
> a few of the above mentioned, yet i have no type bounds and there
> arent any selinux_err or anything:
> 
> CapabilityBoundingSet=CAP_SYS_ADMIN

They don't enable NNP if the process has CAP_SYS_ADMIN.  Comment in the
source code says: "if we are privileged, we don't need NNP".

> PrivateTmp=yes
> PrivateDevices=yes
> PrivateNetwork=yes
> ProtectSystem=yes
> ProtectHome=yes
> ProtectControlGroups=yes
> ProtectKernelTunables=yes
> MemoryDenyWriteExecute=yes
> RestrictRealtime=yes
> RestrictAddressFamilies=AF_UNIX
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module
> @mount @obsolete @raw-io
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > >  	}
> > > > > > > > > > -	return 0;
> > > > > > > > > > +
> > > > > > > > > > +	/*
> > > > > > > > > > +	 * On failure, preserve the errno values
> > > > > > > > > > for NNP
> > > > > > > > > > vs
> > > > > > > > > > nosuid.
> > > > > > > > > > +	 * NNP:  Operation not permitted for
> > > > > > > > > > caller.
> > > > > > > > > > +	 * nosuid:  Permission denied to file.
> > > > > > > > > > +	 */
> > > > > > > > > > +	if (nnp)
> > > > > > > > > > +		return -EPERM;
> > > > > > > > > > +	return -EACCES;
> > > > > > > > > >  }
> > > > > > > > > >  
> > > > > > > > > >  static int selinux_bprm_set_creds(struct
> > > > > > > > > > linux_binprm
> > > > > > > > > > *bprm)
> > > > > > > > > > diff --git a/security/selinux/include/classmap.h
> > > > > > > > > > b/security/selinux/include/classmap.h
> > > > > > > > > > index b9fe343..7fde56d 100644
> > > > > > > > > > --- a/security/selinux/include/classmap.h
> > > > > > > > > > +++ b/security/selinux/include/classmap.h
> > > > > > > > > > @@ -47,7 +47,7 @@ struct security_class_mapping
> > > > > > > > > > secclass_map[]
> > > > > > > > > > = {
> > > > > > > > > >  	    "getattr", "setexec", "setfscreate",
> > > > > > > > > > "noatsecure",
> > > > > > > > > > "siginh",
> > > > > > > > > >  	    "setrlimit", "rlimitinh",
> > > > > > > > > > "dyntransition",
> > > > > > > > > > "setcurrent",
> > > > > > > > > >  	    "execmem", "execstack", "execheap",
> > > > > > > > > > "setkeycreate",
> > > > > > > > > > -	    "setsockcreate", "getrlimit", NULL }
> > > > > > > > > > },
> > > > > > > > > > +	    "setsockcreate", "getrlimit",
> > > > > > > > > > "nnp_transition",
> > > > > > > > > > NULL }
> > > > > > > > > > },
> > > > > > > > > >  	{ "system",
> > > > > > > > > >  	  { "ipc_info", "syslog_read",
> > > > > > > > > > "syslog_mod",
> > > > > > > > > >  	    "syslog_console", "module_request",
> > > > > > > > > > "module_load",
> > > > > > > > > > NULL
> > > > > > > > > > } },
> > > > > > > > > > diff --git a/security/selinux/include/security.h
> > > > > > > > > > b/security/selinux/include/security.h
> > > > > > > > > > index e91f08c..88efb1b 100644
> > > > > > > > > > --- a/security/selinux/include/security.h
> > > > > > > > > > +++ b/security/selinux/include/security.h
> > > > > > > > > > @@ -73,6 +73,7 @@ enum {
> > > > > > > > > >  	POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > > > > > > > > >  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > > > > > > > > >  	POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > > > > > > > > > +	POLICYDB_CAPABILITY_NNPTRANSITION,
> > > > > > > > > >  	__POLICYDB_CAPABILITY_MAX
> > > > > > > > > >  };
> > > > > > > > > >  #define POLICYDB_CAPABILITY_MAX
> > > > > > > > > > (__POLICYDB_CAPABILITY_MAX
> > > > > > > > > > -
> > > > > > > > > > 1)
> > > > > > > > > > @@ -84,6 +85,7 @@ extern int
> > > > > > > > > > selinux_policycap_openperm;
> > > > > > > > > >  extern int selinux_policycap_extsockclass;
> > > > > > > > > >  extern int selinux_policycap_alwaysnetwork;
> > > > > > > > > >  extern int selinux_policycap_cgroupseclabel;
> > > > > > > > > > +extern int selinux_policycap_nnptransition;
> > > > > > > > > >  
> > > > > > > > > >  /*
> > > > > > > > > >   * type_datum properties
> > > > > > > > > > diff --git a/security/selinux/ss/services.c
> > > > > > > > > > b/security/selinux/ss/services.c
> > > > > > > > > > index 2f02fa6..2faf47a 100644
> > > > > > > > > > --- a/security/selinux/ss/services.c
> > > > > > > > > > +++ b/security/selinux/ss/services.c
> > > > > > > > > > @@ -76,7 +76,8 @@ char
> > > > > > > > > > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX]
> > > > > > > > > > = {
> > > > > > > > > >  	"open_perms",
> > > > > > > > > >  	"extended_socket_class",
> > > > > > > > > >  	"always_check_network",
> > > > > > > > > > -	"cgroup_seclabel"
> > > > > > > > > > +	"cgroup_seclabel",
> > > > > > > > > > +	"nnp_transition"
> > > > > > > > > >  };
> > > > > > > > > >  
> > > > > > > > > >  int selinux_policycap_netpeer;
> > > > > > > > > > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > > > > > > > > >  int selinux_policycap_extsockclass;
> > > > > > > > > >  int selinux_policycap_alwaysnetwork;
> > > > > > > > > >  int selinux_policycap_cgroupseclabel;
> > > > > > > > > > +int selinux_policycap_nnptransition;
> > > > > > > > > >  
> > > > > > > > > >  static DEFINE_RWLOCK(policy_rwlock);
> > > > > > > > > >  
> > > > > > > > > > @@ -2009,6 +2011,9 @@ static void
> > > > > > > > > > security_load_policycaps(void)
> > > > > > > > > >  	selinux_policycap_cgroupseclabel =
> > > > > > > > > >  		ebitmap_get_bit(&policydb.policyca
> > > > > > > > > > ps,
> > > > > > > > > >  				POLICYDB_CAPABILIT
> > > > > > > > > > Y_CGROUP
> > > > > > > > > > SECL
> > > > > > > > > > ABEL);
> > > > > > > > > > +	selinux_policycap_nnptransition =
> > > > > > > > > > +		ebitmap_get_bit(&policydb.policyca
> > > > > > > > > > ps,
> > > > > > > > > > +				POLICYDB_CAPABILIT
> > > > > > > > > > Y_NNPTRA
> > > > > > > > > > NSIT
> > > > > > > > > > ION);
> > > > > > > > > >  
> > > > > > > > > >  	for (i = 0; i <
> > > > > > > > > > ARRAY_SIZE(selinux_policycap_names);
> > > > > > > > > > i++)
> > > > > > > > > >  		pr_info("SELinux:  policy
> > > > > > > > > > capability
> > > > > > > > > > %s=%d\n",
> > > > > > > > 
> > > > > > > > -- 
> > > > > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C
> > > > > > > > 5F1D 2C7B
> > > > > > > > 6B02
> > > > > > > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3
> > > > > > > > B6C5F1D2
> > > > > > > > C7B6
> > > > > > > > B02
> > > > > > > > Dominick Grift
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > 
> > > 
> > > -- 
> > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > > 6B02
> > > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7
> > > B6B02
> > > Dominick Grift
> > 
> > 
> > 
> > -- 
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> > 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6
> > B02
> > Dominick Grift
> 
> 
> 

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Paul Moore]

On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
>> On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>> > As systemd ramps up enabling NoNewPrivileges (either explicitly in
>> > service unit files or as a side effect of other security-related
>> > settings in service unit files), we're increasingly running afoul
>> > of
>> > its interactions with SELinux...
>>
>> We already talked about this in the other thread so I'll refrain from
>> repeating myself.
>>
>> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> > index 3a06afb..f0c11c2 100644
>> > --- a/security/selinux/hooks.c
>> > +++ b/security/selinux/hooks.c
>> > @@ -2326,24 +2326,37 @@ static int check_nnp_nosuid(const struct
>> > linux_binprm *bprm,
>> >                 return 0; /* No change in credentials */
>> >
>> >         /*
>> > -        * The only transitions we permit under NNP or nosuid
>> > -        * are transitions to bounded SIDs, i.e. SIDs that are
>> > -        * guaranteed to only be allowed a subset of the
>> > permissions
>> > -        * of the current SID.
>> > +        * If the policy enables the nnp_transition policy
>> > capability,
>> > +        * then we permit transitions under NNP or nosuid if the
>> > +        * policy explicitly allows nnp_transition permission
>> > between
>> > +        * the old and new contexts.
>> >          */
>> > -       rc = security_bounded_transition(old_tsec->sid, new_tsec-
>> > >sid);
>> > -       if (rc) {
>> > +       if (selinux_policycap_nnptransition) {
>> > +               rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
>> > +                                 SECCLASS_PROCESS,
>> > +                                 PROCESS__NNP_TRANSITION, NULL);
>> > +               if (!rc)
>> > +                       return 0;
>>
>> This is interesting, we had been talking about domain transitions
>> under NNP, but we never really discussed transitions under nosuid
>> mounts, and the motivation for this patch appears to be entirely
>> around NNP alone.
>
> Yes, I decided to keep NNP and nosuid handling consistent.  Similar
> arguments apply; the current restriction on SELinux transitions on
> nosuid mounts forces users to make a choice between SELinux transitions
> and nosuid mounts, which can leave them less protected.  That has been
> a common issue e.g. for httpd transitions on cgi scripts and the like.

I'm not arguing that decoupling the NNP/nosuid state and SELinux
domain transitions is a bad idea, it's a good idea, I'm just thinking
that providing some additional granularity by splitting NNP and nosuid
might be a good thing.  However, the permission limitation clouds that
a bit; more below.

>> I think the policycap/permission approach is reasonable, but I wonder
>> if we should separate this into two permissions, e.g. process {
>> nnp_transition nosuid_transition }, especially since such a change in
>> the future would likely require another policycap?
>
> I was hoping to avoid that and keep the nnp/nosuid handling consistent.
>  Also, we are out of process permissions after nnp_transition, so we
> can't do that without adding a process2 or similar class. Possibly we
> could name the capability and permission more generally to make it
> clearer that it affect both, but not sure what to suggest there
> (nnpnosuid_transition?).

While I think splitting the NNP/nosuid transition restrictions might
be a good idea under the new policy capability, I'm not sure it is
worth the cost of a "process2" object class.

With that in mind, let's do two things with this patch:

* Mention the nosuid restrictions in the patch description.  It
doesn't need much text, but something would be good so we have
documentation in the git log.

* Let's pick a new permission name that is not specific to NNP or
nosuid.  IMHO, nnpnosuid_transition is ... less than good.
Unfortunately, I'm not sure I'm much better at picking names; how
about "protected_transition"?  "restricted_transition"?
"enable_transition"?  "override_transition"?

-- 
paul moore
www.paul-moore.com

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Chris PeBenito]

On 07/12/2017 05:38 PM, Paul Moore wrote:
> On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
>>> On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa.gov>
>>> wrote:

> While I think splitting the NNP/nosuid transition restrictions might
> be a good idea under the new policy capability, I'm not sure it is
> worth the cost of a "process2" object class.
>
> With that in mind, let's do two things with this patch:
>
> * Mention the nosuid restrictions in the patch description.  It
> doesn't need much text, but something would be good so we have
> documentation in the git log.
>
> * Let's pick a new permission name that is not specific to NNP or
> nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> Unfortunately, I'm not sure I'm much better at picking names; how
> about "protected_transition"?  "restricted_transition"?
> "enable_transition"?  "override_transition"?

I vote for nnp_transition anyway.  "No New Privileges" encompasses 
nosuid in my mind.  If the two perms had been separated I would have 
been inclined to allow both every time one of them was needed, to make 
sure no one was surprised by the behavior difference.


-- 
Chris PeBenito

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> On 07/12/2017 05:38 PM, Paul Moore wrote:
> > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.nsa.gov
> > > wrote:
> > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa
> > > > .gov>
> > > > wrote:
> > While I think splitting the NNP/nosuid transition restrictions
> > might
> > be a good idea under the new policy capability, I'm not sure it is
> > worth the cost of a "process2" object class.
> > 
> > With that in mind, let's do two things with this patch:
> > 
> > * Mention the nosuid restrictions in the patch description.  It
> > doesn't need much text, but something would be good so we have
> > documentation in the git log.
> > 
> > * Let's pick a new permission name that is not specific to NNP or
> > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > Unfortunately, I'm not sure I'm much better at picking names; how
> > about "protected_transition"?  "restricted_transition"?
> > "enable_transition"?  "override_transition"?
> 
> I vote for nnp_transition anyway.  "No New Privileges" encompasses 
> nosuid in my mind.  If the two perms had been separated I would have 
> been inclined to allow both every time one of them was needed, to
> make 
> sure no one was surprised by the behavior difference.

I agree; I'll keep it as nnp_transition and just document it in the
patch description.

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Paul Moore]

On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
>> On 07/12/2017 05:38 PM, Paul Moore wrote:
>> > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.nsa.gov
>> > > wrote:
>> > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
>> > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho.nsa
>> > > > .gov>
>> > > > wrote:
>> > While I think splitting the NNP/nosuid transition restrictions
>> > might
>> > be a good idea under the new policy capability, I'm not sure it is
>> > worth the cost of a "process2" object class.
>> >
>> > With that in mind, let's do two things with this patch:
>> >
>> > * Mention the nosuid restrictions in the patch description.  It
>> > doesn't need much text, but something would be good so we have
>> > documentation in the git log.
>> >
>> > * Let's pick a new permission name that is not specific to NNP or
>> > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
>> > Unfortunately, I'm not sure I'm much better at picking names; how
>> > about "protected_transition"?  "restricted_transition"?
>> > "enable_transition"?  "override_transition"?
>>
>> I vote for nnp_transition anyway.  "No New Privileges" encompasses
>> nosuid in my mind.  If the two perms had been separated I would have
>> been inclined to allow both every time one of them was needed, to
>> make
>> sure no one was surprised by the behavior difference.
>
> I agree; I'll keep it as nnp_transition and just document it in the
> patch description.

Sorry to be a stubborn about this, but nnp_transition makes little
sense for the nosuid restriction.  Like it or not, NNP has a concrete
meaning which is distinct from nosuid mounts.  We don't have to pick
any of the permission names I tossed out, none of those were very
good, but I would like to see something that takes both NNP and nosuid
into account, or preferably something that doesn't use either name
explicitly but still conveys the meaning.

-- 
paul moore
www.paul-moore.com

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.nsa
> > > > .gov
> > > > > wrote:
> > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tycho
> > > > > > .nsa
> > > > > > .gov>
> > > > > > wrote:
> > > > 
> > > > While I think splitting the NNP/nosuid transition restrictions
> > > > might
> > > > be a good idea under the new policy capability, I'm not sure it
> > > > is
> > > > worth the cost of a "process2" object class.
> > > > 
> > > > With that in mind, let's do two things with this patch:
> > > > 
> > > > * Mention the nosuid restrictions in the patch description.  It
> > > > doesn't need much text, but something would be good so we have
> > > > documentation in the git log.
> > > > 
> > > > * Let's pick a new permission name that is not specific to NNP
> > > > or
> > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > how
> > > > about "protected_transition"?  "restricted_transition"?
> > > > "enable_transition"?  "override_transition"?
> > > 
> > > I vote for nnp_transition anyway.  "No New Privileges"
> > > encompasses
> > > nosuid in my mind.  If the two perms had been separated I would
> > > have
> > > been inclined to allow both every time one of them was needed, to
> > > make
> > > sure no one was surprised by the behavior difference.
> > 
> > I agree; I'll keep it as nnp_transition and just document it in the
> > patch description.
> 
> Sorry to be a stubborn about this, but nnp_transition makes little
> sense for the nosuid restriction.  Like it or not, NNP has a concrete
> meaning which is distinct from nosuid mounts.  We don't have to pick
> any of the permission names I tossed out, none of those were very
> good, but I would like to see something that takes both NNP and
> nosuid
> into account, or preferably something that doesn't use either name
> explicitly but still conveys the meaning.

NNP is essentially a superset of nosuid; it applies to all execve()
calls by the process and its descendants rather than only to execve()
calls on specially marked filesystems.  So I viewed it as the more
general term.

If that's not viable, I can't think of anything clearer or better than
nnp_nosuid_transition.  That clearly links it to what it means (allow a
SELinux domain transition under NNP or nosuid).  It is somewhat ugly
and verbose but it is clear in what it means, which I think is more
important. All of your suggestions IMHO were less clear since they had
no clear linkage to either NNP or nosuid, and I couldn't tell from
reading the permission name what it meant.  The SELinux domain
transition isn't protected, it isn't restricted, it isn't clear what
enable_transition means versus the regular transition or dyntransition
permissions, and we aren't overriding a transition but rather allowing
one under NNP/nosuid.

The only other alternative I see is to introduce a process2 class and
use separate nnp_transition and nosuid_transition permissions (but in
practice I expect them to be both allowed or denied together).  Note
that this will require two avtab and AVC entries for every domain pair
(if we allow whichever one ends up going in the process2 class), so
that has an impact on policy and AVC size.  Don't really see that as
worthwhile.

Other approach would be to make the nosuid transition checks file-based 
instead so that it would go in the file class (while the nnp one would
remain in the process class), but I don't think that's really what we
want either.  Difference between "Can domain D1 transition under nosuid
 to D2?" and "Can domain D1 transition under nosuid when executing file
with type T1?".

On a separate note, I plan to cc luto on the next version of the patch
as I suspect he will have concerns about relaxing this constraint on
NNP and this likely requires updating Documentation/prctl/no_new_privs*
and the man pages that describe NNP behavior.

The other model would be to figure out a way to make the typebounds
logic work cleanly in a manner that preserves the desired NNP/nosuid
invariant _and_ doesn't require leaking unnecessary accesses into the
ancestor domains that make them less secure, plus CIL support for
automatically propagating permissions in the desired way.  But I
haven't yet come up with a way to do that.  We can do it in some cases
by creating typebounds between the object types, e.g.:
typebounds parent_t child_t;
allow child_t self:process execmem;
allow child_t child_exec_t:file entrypoint;
allow child_t child_tmp_t:file create;
can be allowed via:
allow parent_t child_t:process execmem; # an otherwise nonsensical rule
typebounds parent_exec_t child_exec_t;
typebounds parent_tmp_t child_tmp_t;
but this breaks down when there isn't an equivalent type and permission
set already allowed to the parent for every type allowed to the child.

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa.gov
> > >
> > wrote:
> > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.n
> > > > > sa
> > > > > .gov
> > > > > > wrote:
> > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tyc
> > > > > > > ho
> > > > > > > .nsa
> > > > > > > .gov>
> > > > > > > wrote:
> > > > > 
> > > > > While I think splitting the NNP/nosuid transition
> > > > > restrictions
> > > > > might
> > > > > be a good idea under the new policy capability, I'm not sure
> > > > > it
> > > > > is
> > > > > worth the cost of a "process2" object class.
> > > > > 
> > > > > With that in mind, let's do two things with this patch:
> > > > > 
> > > > > * Mention the nosuid restrictions in the patch
> > > > > description.  It
> > > > > doesn't need much text, but something would be good so we
> > > > > have
> > > > > documentation in the git log.
> > > > > 
> > > > > * Let's pick a new permission name that is not specific to
> > > > > NNP
> > > > > or
> > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > > how
> > > > > about "protected_transition"?  "restricted_transition"?
> > > > > "enable_transition"?  "override_transition"?
> > > > 
> > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > encompasses
> > > > nosuid in my mind.  If the two perms had been separated I would
> > > > have
> > > > been inclined to allow both every time one of them was needed,
> > > > to
> > > > make
> > > > sure no one was surprised by the behavior difference.
> > > 
> > > I agree; I'll keep it as nnp_transition and just document it in
> > > the
> > > patch description.
> > 
> > Sorry to be a stubborn about this, but nnp_transition makes little
> > sense for the nosuid restriction.  Like it or not, NNP has a
> > concrete
> > meaning which is distinct from nosuid mounts.  We don't have to
> > pick
> > any of the permission names I tossed out, none of those were very
> > good, but I would like to see something that takes both NNP and
> > nosuid
> > into account, or preferably something that doesn't use either name
> > explicitly but still conveys the meaning.
> 
> NNP is essentially a superset of nosuid; it applies to all execve()
> calls by the process and its descendants rather than only to execve()
> calls on specially marked filesystems.  So I viewed it as the more
> general term.
> 
> If that's not viable, I can't think of anything clearer or better
> than
> nnp_nosuid_transition.  That clearly links it to what it means (allow
> a
> SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> and verbose but it is clear in what it means, which I think is more
> important. All of your suggestions IMHO were less clear since they
> had
> no clear linkage to either NNP or nosuid, and I couldn't tell from
> reading the permission name what it meant.  The SELinux domain
> transition isn't protected, it isn't restricted, it isn't clear what
> enable_transition means versus the regular transition or
> dyntransition
> permissions, and we aren't overriding a transition but rather
> allowing
> one under NNP/nosuid.
> 
> The only other alternative I see is to introduce a process2 class and
> use separate nnp_transition and nosuid_transition permissions (but in
> practice I expect them to be both allowed or denied together).  Note
> that this will require two avtab and AVC entries for every domain
> pair
> (if we allow whichever one ends up going in the process2 class), so
> that has an impact on policy and AVC size.  Don't really see that as
> worthwhile.
> 
> Other approach would be to make the nosuid transition checks file-
> based 
> instead so that it would go in the file class (while the nnp one
> would
> remain in the process class), but I don't think that's really what we
> want either.  Difference between "Can domain D1 transition under
> nosuid
>  to D2?" and "Can domain D1 transition under nosuid when executing
> file
> with type T1?".

Just to be clear, we would also be separately checking regular
transition permission between the old and new contexts on these
transitions, so you would need both:
allow D1 D2:process transition;
allow D1 T1:file nosuid_transition;
if we took the latter approach.

So we wouldn't lose entirely on a domain-to-domain check, but it would
no longer be domain-to-domain for the nosuid part.

Whereas with original approach, we end up requiring:
allow D1 D2:process transition;
allow D1 D2:process nnp_nosuid_transition; # or whatever permission name is used

> 
> On a separate note, I plan to cc luto on the next version of the
> patch
> as I suspect he will have concerns about relaxing this constraint on
> NNP and this likely requires updating
> Documentation/prctl/no_new_privs*
> and the man pages that describe NNP behavior.
> 
> The other model would be to figure out a way to make the typebounds
> logic work cleanly in a manner that preserves the desired NNP/nosuid
> invariant _and_ doesn't require leaking unnecessary accesses into the
> ancestor domains that make them less secure, plus CIL support for
> automatically propagating permissions in the desired way.  But I
> haven't yet come up with a way to do that.  We can do it in some
> cases
> by creating typebounds between the object types, e.g.:
> typebounds parent_t child_t;
> allow child_t self:process execmem;
> allow child_t child_exec_t:file entrypoint;
> allow child_t child_tmp_t:file create;
> can be allowed via:
> allow parent_t child_t:process execmem; # an otherwise nonsensical
> rule
> typebounds parent_exec_t child_exec_t;
> typebounds parent_tmp_t child_tmp_t;
> but this breaks down when there isn't an equivalent type and
> permission
> set already allowed to the parent for every type allowed to the
> child.

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 7430 bytes --]

On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa.gov
> > > >
> > > wrote:
> > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tycho.n
> > > > > > sa
> > > > > > .gov
> > > > > > > wrote:
> > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds@tyc
> > > > > > > > ho
> > > > > > > > .nsa
> > > > > > > > .gov>
> > > > > > > > wrote:
> > > > > > 
> > > > > > While I think splitting the NNP/nosuid transition
> > > > > > restrictions
> > > > > > might
> > > > > > be a good idea under the new policy capability, I'm not sure
> > > > > > it
> > > > > > is
> > > > > > worth the cost of a "process2" object class.
> > > > > > 
> > > > > > With that in mind, let's do two things with this patch:
> > > > > > 
> > > > > > * Mention the nosuid restrictions in the patch
> > > > > > description.  It
> > > > > > doesn't need much text, but something would be good so we
> > > > > > have
> > > > > > documentation in the git log.
> > > > > > 
> > > > > > * Let's pick a new permission name that is not specific to
> > > > > > NNP
> > > > > > or
> > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than good.
> > > > > > Unfortunately, I'm not sure I'm much better at picking names;
> > > > > > how
> > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > "enable_transition"?  "override_transition"?
> > > > > 
> > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > encompasses
> > > > > nosuid in my mind.  If the two perms had been separated I would
> > > > > have
> > > > > been inclined to allow both every time one of them was needed,
> > > > > to
> > > > > make
> > > > > sure no one was surprised by the behavior difference.
> > > > 
> > > > I agree; I'll keep it as nnp_transition and just document it in
> > > > the
> > > > patch description.
> > > 
> > > Sorry to be a stubborn about this, but nnp_transition makes little
> > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > concrete
> > > meaning which is distinct from nosuid mounts.  We don't have to
> > > pick
> > > any of the permission names I tossed out, none of those were very
> > > good, but I would like to see something that takes both NNP and
> > > nosuid
> > > into account, or preferably something that doesn't use either name
> > > explicitly but still conveys the meaning.
> > 
> > NNP is essentially a superset of nosuid; it applies to all execve()
> > calls by the process and its descendants rather than only to execve()
> > calls on specially marked filesystems.  So I viewed it as the more
> > general term.
> > 
> > If that's not viable, I can't think of anything clearer or better
> > than
> > nnp_nosuid_transition.  That clearly links it to what it means (allow
> > a
> > SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> > and verbose but it is clear in what it means, which I think is more
> > important. All of your suggestions IMHO were less clear since they
> > had
> > no clear linkage to either NNP or nosuid, and I couldn't tell from
> > reading the permission name what it meant.  The SELinux domain
> > transition isn't protected, it isn't restricted, it isn't clear what
> > enable_transition means versus the regular transition or
> > dyntransition
> > permissions, and we aren't overriding a transition but rather
> > allowing
> > one under NNP/nosuid.
> > 
> > The only other alternative I see is to introduce a process2 class and
> > use separate nnp_transition and nosuid_transition permissions (but in
> > practice I expect them to be both allowed or denied together).  Note
> > that this will require two avtab and AVC entries for every domain
> > pair
> > (if we allow whichever one ends up going in the process2 class), so
> > that has an impact on policy and AVC size.  Don't really see that as
> > worthwhile.
> > 
> > Other approach would be to make the nosuid transition checks file-
> > based 
> > instead so that it would go in the file class (while the nnp one
> > would
> > remain in the process class), but I don't think that's really what we
> > want either.  Difference between "Can domain D1 transition under
> > nosuid
> >  to D2?" and "Can domain D1 transition under nosuid when executing
> > file
> > with type T1?".
> 
> Just to be clear, we would also be separately checking regular
> transition permission between the old and new contexts on these
> transitions, so you would need both:
> allow D1 D2:process transition;
> allow D1 T1:file nosuid_transition;
> if we took the latter approach.
> 
> So we wouldn't lose entirely on a domain-to-domain check, but it would
> no longer be domain-to-domain for the nosuid part.
> 
> Whereas with original approach, we end up requiring:
> allow D1 D2:process transition;
> allow D1 D2:process nnp_nosuid_transition; # or whatever permission name is used

I don't know if i understand all the ins-and-outs of the matter but i think i do like the idea of differentiating between nosuid_transition and nnp_transition
It provides more flexibility because i might not want to allow one or the other automatically.

I do not think it its a good idea to allow a process to transiton on nosuid mounted filesystems just because i am forced to allow it nnp.

So since the stuff is ugly one way or another might as well make it consistent with SELinux flexibility goals

Just my preference but I dont have a really strong opinion on the matter

> 
> > 
> > On a separate note, I plan to cc luto on the next version of the
> > patch
> > as I suspect he will have concerns about relaxing this constraint on
> > NNP and this likely requires updating
> > Documentation/prctl/no_new_privs*
> > and the man pages that describe NNP behavior.
> > 
> > The other model would be to figure out a way to make the typebounds
> > logic work cleanly in a manner that preserves the desired NNP/nosuid
> > invariant _and_ doesn't require leaking unnecessary accesses into the
> > ancestor domains that make them less secure, plus CIL support for
> > automatically propagating permissions in the desired way.  But I
> > haven't yet come up with a way to do that.  We can do it in some
> > cases
> > by creating typebounds between the object types, e.g.:
> > typebounds parent_t child_t;
> > allow child_t self:process execmem;
> > allow child_t child_exec_t:file entrypoint;
> > allow child_t child_tmp_t:file create;
> > can be allowed via:
> > allow parent_t child_t:process execmem; # an otherwise nonsensical
> > rule
> > typebounds parent_exec_t child_exec_t;
> > typebounds parent_tmp_t child_tmp_t;
> > but this breaks down when there isn't an equivalent type and
> > permission
> > set already allowed to the parent for every type allowed to the
> > child.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa
> > > > .gov
> > > > > 
> > > > 
> > > > wrote:
> > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tyc
> > > > > > > ho.n
> > > > > > > sa
> > > > > > > .gov
> > > > > > > > wrote:
> > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds
> > > > > > > > > @tyc
> > > > > > > > > ho
> > > > > > > > > .nsa
> > > > > > > > > .gov>
> > > > > > > > > wrote:
> > > > > > > 
> > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > restrictions
> > > > > > > might
> > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > sure
> > > > > > > it
> > > > > > > is
> > > > > > > worth the cost of a "process2" object class.
> > > > > > > 
> > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > 
> > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > description.  It
> > > > > > > doesn't need much text, but something would be good so we
> > > > > > > have
> > > > > > > documentation in the git log.
> > > > > > > 
> > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > to
> > > > > > > NNP
> > > > > > > or
> > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > good.
> > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > names;
> > > > > > > how
> > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > "enable_transition"?  "override_transition"?
> > > > > > 
> > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > encompasses
> > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > would
> > > > > > have
> > > > > > been inclined to allow both every time one of them was
> > > > > > needed,
> > > > > > to
> > > > > > make
> > > > > > sure no one was surprised by the behavior difference.
> > > > > 
> > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > in
> > > > > the
> > > > > patch description.
> > > > 
> > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > little
> > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > concrete
> > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > pick
> > > > any of the permission names I tossed out, none of those were
> > > > very
> > > > good, but I would like to see something that takes both NNP and
> > > > nosuid
> > > > into account, or preferably something that doesn't use either
> > > > name
> > > > explicitly but still conveys the meaning.
> > > 
> > > NNP is essentially a superset of nosuid; it applies to all
> > > execve()
> > > calls by the process and its descendants rather than only to
> > > execve()
> > > calls on specially marked filesystems.  So I viewed it as the
> > > more
> > > general term.
> > > 
> > > If that's not viable, I can't think of anything clearer or better
> > > than
> > > nnp_nosuid_transition.  That clearly links it to what it means
> > > (allow
> > > a
> > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > ugly
> > > and verbose but it is clear in what it means, which I think is
> > > more
> > > important. All of your suggestions IMHO were less clear since
> > > they
> > > had
> > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > from
> > > reading the permission name what it meant.  The SELinux domain
> > > transition isn't protected, it isn't restricted, it isn't clear
> > > what
> > > enable_transition means versus the regular transition or
> > > dyntransition
> > > permissions, and we aren't overriding a transition but rather
> > > allowing
> > > one under NNP/nosuid.
> > > 
> > > The only other alternative I see is to introduce a process2 class
> > > and
> > > use separate nnp_transition and nosuid_transition permissions
> > > (but in
> > > practice I expect them to be both allowed or denied
> > > together).  Note
> > > that this will require two avtab and AVC entries for every domain
> > > pair
> > > (if we allow whichever one ends up going in the process2 class),
> > > so
> > > that has an impact on policy and AVC size.  Don't really see that
> > > as
> > > worthwhile.
> > > 
> > > Other approach would be to make the nosuid transition checks
> > > file-
> > > based 
> > > instead so that it would go in the file class (while the nnp one
> > > would
> > > remain in the process class), but I don't think that's really
> > > what we
> > > want either.  Difference between "Can domain D1 transition under
> > > nosuid
> > >  to D2?" and "Can domain D1 transition under nosuid when
> > > executing
> > > file
> > > with type T1?".
> > 
> > Just to be clear, we would also be separately checking regular
> > transition permission between the old and new contexts on these
> > transitions, so you would need both:
> > allow D1 D2:process transition;
> > allow D1 T1:file nosuid_transition;
> > if we took the latter approach.
> > 
> > So we wouldn't lose entirely on a domain-to-domain check, but it
> > would
> > no longer be domain-to-domain for the nosuid part.
> > 
> > Whereas with original approach, we end up requiring:
> > allow D1 D2:process transition;
> > allow D1 D2:process nnp_nosuid_transition; # or whatever permission
> > name is used
> 
> I don't know if i understand all the ins-and-outs of the matter but i
> think i do like the idea of differentiating between nosuid_transition
> and nnp_transition
> It provides more flexibility because i might not want to allow one or
> the other automatically.
> 
> I do not think it its a good idea to allow a process to transiton on
> nosuid mounted filesystems just because i am forced to allow it nnp.

Can you provide a real use case where you would need to distinguish
them?

Currently we handle them the same way (i.e. we don't allow transitions
unless bounded for both).  The current patch preserves that
consistency, and just provides a way to allow transitions without
bounds for both.  Of course, you still have to be allowed the usual
permissions in order to perform the transition at all (Can the caller
execute the file? Can the callee be entered (entrypoint) by the file?
Can the caller transition to the callee?) in addition to the new
permission check (Can the caller transition under NNP/nosuid to the
callee?).

We can't distinguish them on a domain-to-domain basis without
introducing a new process2 class, and so far no one has been excited
about that.

> So since the stuff is ugly one way or another might as well make it
> consistent with SELinux flexibility goals
> 
> Just my preference but I dont have a really strong opinion on the
> matter
> 
> > 
> > > 
> > > On a separate note, I plan to cc luto on the next version of the
> > > patch
> > > as I suspect he will have concerns about relaxing this constraint
> > > on
> > > NNP and this likely requires updating
> > > Documentation/prctl/no_new_privs*
> > > and the man pages that describe NNP behavior.
> > > 
> > > The other model would be to figure out a way to make the
> > > typebounds
> > > logic work cleanly in a manner that preserves the desired
> > > NNP/nosuid
> > > invariant _and_ doesn't require leaking unnecessary accesses into
> > > the
> > > ancestor domains that make them less secure, plus CIL support for
> > > automatically propagating permissions in the desired way.  But I
> > > haven't yet come up with a way to do that.  We can do it in some
> > > cases
> > > by creating typebounds between the object types, e.g.:
> > > typebounds parent_t child_t;
> > > allow child_t self:process execmem;
> > > allow child_t child_exec_t:file entrypoint;
> > > allow child_t child_tmp_t:file create;
> > > can be allowed via:
> > > allow parent_t child_t:process execmem; # an otherwise
> > > nonsensical
> > > rule
> > > typebounds parent_exec_t child_exec_t;
> > > typebounds parent_tmp_t child_tmp_t;
> > > but this breaks down when there isn't an equivalent type and
> > > permission
> > > set already allowed to the parent for every type allowed to the
> > > child.
> 
> 

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 9912 bytes --]

On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa
> > > > > .gov
> > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tyc
> > > > > > > > ho.n
> > > > > > > > sa
> > > > > > > > .gov
> > > > > > > > > wrote:
> > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds
> > > > > > > > > > @tyc
> > > > > > > > > > ho
> > > > > > > > > > .nsa
> > > > > > > > > > .gov>
> > > > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > restrictions
> > > > > > > > might
> > > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > > sure
> > > > > > > > it
> > > > > > > > is
> > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > 
> > > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > > 
> > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > description.  It
> > > > > > > > doesn't need much text, but something would be good so we
> > > > > > > > have
> > > > > > > > documentation in the git log.
> > > > > > > > 
> > > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > > to
> > > > > > > > NNP
> > > > > > > > or
> > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > good.
> > > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > > names;
> > > > > > > > how
> > > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > 
> > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > encompasses
> > > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > > would
> > > > > > > have
> > > > > > > been inclined to allow both every time one of them was
> > > > > > > needed,
> > > > > > > to
> > > > > > > make
> > > > > > > sure no one was surprised by the behavior difference.
> > > > > > 
> > > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > > in
> > > > > > the
> > > > > > patch description.
> > > > > 
> > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > little
> > > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > > concrete
> > > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > > pick
> > > > > any of the permission names I tossed out, none of those were
> > > > > very
> > > > > good, but I would like to see something that takes both NNP and
> > > > > nosuid
> > > > > into account, or preferably something that doesn't use either
> > > > > name
> > > > > explicitly but still conveys the meaning.
> > > > 
> > > > NNP is essentially a superset of nosuid; it applies to all
> > > > execve()
> > > > calls by the process and its descendants rather than only to
> > > > execve()
> > > > calls on specially marked filesystems.  So I viewed it as the
> > > > more
> > > > general term.
> > > > 
> > > > If that's not viable, I can't think of anything clearer or better
> > > > than
> > > > nnp_nosuid_transition.  That clearly links it to what it means
> > > > (allow
> > > > a
> > > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > > ugly
> > > > and verbose but it is clear in what it means, which I think is
> > > > more
> > > > important. All of your suggestions IMHO were less clear since
> > > > they
> > > > had
> > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > from
> > > > reading the permission name what it meant.  The SELinux domain
> > > > transition isn't protected, it isn't restricted, it isn't clear
> > > > what
> > > > enable_transition means versus the regular transition or
> > > > dyntransition
> > > > permissions, and we aren't overriding a transition but rather
> > > > allowing
> > > > one under NNP/nosuid.
> > > > 
> > > > The only other alternative I see is to introduce a process2 class
> > > > and
> > > > use separate nnp_transition and nosuid_transition permissions
> > > > (but in
> > > > practice I expect them to be both allowed or denied
> > > > together).  Note
> > > > that this will require two avtab and AVC entries for every domain
> > > > pair
> > > > (if we allow whichever one ends up going in the process2 class),
> > > > so
> > > > that has an impact on policy and AVC size.  Don't really see that
> > > > as
> > > > worthwhile.
> > > > 
> > > > Other approach would be to make the nosuid transition checks
> > > > file-
> > > > based 
> > > > instead so that it would go in the file class (while the nnp one
> > > > would
> > > > remain in the process class), but I don't think that's really
> > > > what we
> > > > want either.  Difference between "Can domain D1 transition under
> > > > nosuid
> > > >  to D2?" and "Can domain D1 transition under nosuid when
> > > > executing
> > > > file
> > > > with type T1?".
> > > 
> > > Just to be clear, we would also be separately checking regular
> > > transition permission between the old and new contexts on these
> > > transitions, so you would need both:
> > > allow D1 D2:process transition;
> > > allow D1 T1:file nosuid_transition;
> > > if we took the latter approach.
> > > 
> > > So we wouldn't lose entirely on a domain-to-domain check, but it
> > > would
> > > no longer be domain-to-domain for the nosuid part.
> > > 
> > > Whereas with original approach, we end up requiring:
> > > allow D1 D2:process transition;
> > > allow D1 D2:process nnp_nosuid_transition; # or whatever permission
> > > name is used
> > 
> > I don't know if i understand all the ins-and-outs of the matter but i
> > think i do like the idea of differentiating between nosuid_transition
> > and nnp_transition
> > It provides more flexibility because i might not want to allow one or
> > the other automatically.
> > 
> > I do not think it its a good idea to allow a process to transiton on
> > nosuid mounted filesystems just because i am forced to allow it nnp.
> 
> Can you provide a real use case where you would need to distinguish
> them?

Nope I cannot, but its easy to merge the two permissions in policy, and thereby preserving flexibility. It will be hard to deal with a case that might arise that was not foreseen if we cover both scenarios with a single permission.

> 
> Currently we handle them the same way (i.e. we don't allow transitions
> unless bounded for both).  The current patch preserves that
> consistency, and just provides a way to allow transitions without
> bounds for both.  Of course, you still have to be allowed the usual
> permissions in order to perform the transition at all (Can the caller
> execute the file? Can the callee be entered (entrypoint) by the file?
> Can the caller transition to the callee?) in addition to the new
> permission check (Can the caller transition under NNP/nosuid to the
> callee?).
> 
> We can't distinguish them on a domain-to-domain basis without
> introducing a new process2 class, and so far no one has been excited
> about that.

Why is that? Eventually that is going to happen anyway. Besides we also have a capability2 and its not like that's a big deal is it?

But again, its not that big of a deal for me.

> 
> > So since the stuff is ugly one way or another might as well make it
> > consistent with SELinux flexibility goals
> > 
> > Just my preference but I dont have a really strong opinion on the
> > matter
> > 
> > > 
> > > > 
> > > > On a separate note, I plan to cc luto on the next version of the
> > > > patch
> > > > as I suspect he will have concerns about relaxing this constraint
> > > > on
> > > > NNP and this likely requires updating
> > > > Documentation/prctl/no_new_privs*
> > > > and the man pages that describe NNP behavior.
> > > > 
> > > > The other model would be to figure out a way to make the
> > > > typebounds
> > > > logic work cleanly in a manner that preserves the desired
> > > > NNP/nosuid
> > > > invariant _and_ doesn't require leaking unnecessary accesses into
> > > > the
> > > > ancestor domains that make them less secure, plus CIL support for
> > > > automatically propagating permissions in the desired way.  But I
> > > > haven't yet come up with a way to do that.  We can do it in some
> > > > cases
> > > > by creating typebounds between the object types, e.g.:
> > > > typebounds parent_t child_t;
> > > > allow child_t self:process execmem;
> > > > allow child_t child_exec_t:file entrypoint;
> > > > allow child_t child_tmp_t:file create;
> > > > can be allowed via:
> > > > allow parent_t child_t:process execmem; # an otherwise
> > > > nonsensical
> > > > rule
> > > > typebounds parent_exec_t child_exec_t;
> > > > typebounds parent_tmp_t child_tmp_t;
> > > > but this breaks down when there isn't an equivalent type and
> > > > permission
> > > > set already allowed to the parent for every type allowed to the
> > > > child.
> > 
> > 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 10911 bytes --]

On Thu, Jul 13, 2017 at 08:16:14PM +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho.nsa
> > > > > > .gov
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tyc
> > > > > > > > > ho.n
> > > > > > > > > sa
> > > > > > > > > .gov
> > > > > > > > > > wrote:
> > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote:
> > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley <sds
> > > > > > > > > > > @tyc
> > > > > > > > > > > ho
> > > > > > > > > > > .nsa
> > > > > > > > > > > .gov>
> > > > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > restrictions
> > > > > > > > > might
> > > > > > > > > be a good idea under the new policy capability, I'm not
> > > > > > > > > sure
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > 
> > > > > > > > > With that in mind, let's do two things with this patch:
> > > > > > > > > 
> > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > description.  It
> > > > > > > > > doesn't need much text, but something would be good so we
> > > > > > > > > have
> > > > > > > > > documentation in the git log.
> > > > > > > > > 
> > > > > > > > > * Let's pick a new permission name that is not specific
> > > > > > > > > to
> > > > > > > > > NNP
> > > > > > > > > or
> > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > good.
> > > > > > > > > Unfortunately, I'm not sure I'm much better at picking
> > > > > > > > > names;
> > > > > > > > > how
> > > > > > > > > about "protected_transition"?  "restricted_transition"?
> > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > 
> > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > encompasses
> > > > > > > > nosuid in my mind.  If the two perms had been separated I
> > > > > > > > would
> > > > > > > > have
> > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > needed,
> > > > > > > > to
> > > > > > > > make
> > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > 
> > > > > > > I agree; I'll keep it as nnp_transition and just document it
> > > > > > > in
> > > > > > > the
> > > > > > > patch description.
> > > > > > 
> > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > little
> > > > > > sense for the nosuid restriction.  Like it or not, NNP has a
> > > > > > concrete
> > > > > > meaning which is distinct from nosuid mounts.  We don't have to
> > > > > > pick
> > > > > > any of the permission names I tossed out, none of those were
> > > > > > very
> > > > > > good, but I would like to see something that takes both NNP and
> > > > > > nosuid
> > > > > > into account, or preferably something that doesn't use either
> > > > > > name
> > > > > > explicitly but still conveys the meaning.
> > > > > 
> > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > execve()
> > > > > calls by the process and its descendants rather than only to
> > > > > execve()
> > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > more
> > > > > general term.
> > > > > 
> > > > > If that's not viable, I can't think of anything clearer or better
> > > > > than
> > > > > nnp_nosuid_transition.  That clearly links it to what it means
> > > > > (allow
> > > > > a
> > > > > SELinux domain transition under NNP or nosuid).  It is somewhat
> > > > > ugly
> > > > > and verbose but it is clear in what it means, which I think is
> > > > > more
> > > > > important. All of your suggestions IMHO were less clear since
> > > > > they
> > > > > had
> > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > from
> > > > > reading the permission name what it meant.  The SELinux domain
> > > > > transition isn't protected, it isn't restricted, it isn't clear
> > > > > what
> > > > > enable_transition means versus the regular transition or
> > > > > dyntransition
> > > > > permissions, and we aren't overriding a transition but rather
> > > > > allowing
> > > > > one under NNP/nosuid.
> > > > > 
> > > > > The only other alternative I see is to introduce a process2 class
> > > > > and
> > > > > use separate nnp_transition and nosuid_transition permissions
> > > > > (but in
> > > > > practice I expect them to be both allowed or denied
> > > > > together).  Note
> > > > > that this will require two avtab and AVC entries for every domain
> > > > > pair
> > > > > (if we allow whichever one ends up going in the process2 class),
> > > > > so
> > > > > that has an impact on policy and AVC size.  Don't really see that
> > > > > as
> > > > > worthwhile.
> > > > > 
> > > > > Other approach would be to make the nosuid transition checks
> > > > > file-
> > > > > based 
> > > > > instead so that it would go in the file class (while the nnp one
> > > > > would
> > > > > remain in the process class), but I don't think that's really
> > > > > what we
> > > > > want either.  Difference between "Can domain D1 transition under
> > > > > nosuid
> > > > >  to D2?" and "Can domain D1 transition under nosuid when
> > > > > executing
> > > > > file
> > > > > with type T1?".
> > > > 
> > > > Just to be clear, we would also be separately checking regular
> > > > transition permission between the old and new contexts on these
> > > > transitions, so you would need both:
> > > > allow D1 D2:process transition;
> > > > allow D1 T1:file nosuid_transition;
> > > > if we took the latter approach.
> > > > 
> > > > So we wouldn't lose entirely on a domain-to-domain check, but it
> > > > would
> > > > no longer be domain-to-domain for the nosuid part.
> > > > 
> > > > Whereas with original approach, we end up requiring:
> > > > allow D1 D2:process transition;
> > > > allow D1 D2:process nnp_nosuid_transition; # or whatever permission
> > > > name is used
> > > 
> > > I don't know if i understand all the ins-and-outs of the matter but i
> > > think i do like the idea of differentiating between nosuid_transition
> > > and nnp_transition
> > > It provides more flexibility because i might not want to allow one or
> > > the other automatically.
> > > 
> > > I do not think it its a good idea to allow a process to transiton on
> > > nosuid mounted filesystems just because i am forced to allow it nnp.
> > 
> > Can you provide a real use case where you would need to distinguish
> > them?
> 
> Nope I cannot, but its easy to merge the two permissions in policy, and thereby preserving flexibility. It will be hard to deal with a case that might arise that was not foreseen if we cover both scenarios with a single permission.

Not sure if its very comparible but take for example kernel module loading where we have system sys_module and module_load for init_module (and file module_load for finit_module)
That is also not particularly pretty but its something that can be taken care of easily in policy

> 
> > 
> > Currently we handle them the same way (i.e. we don't allow transitions
> > unless bounded for both).  The current patch preserves that
> > consistency, and just provides a way to allow transitions without
> > bounds for both.  Of course, you still have to be allowed the usual
> > permissions in order to perform the transition at all (Can the caller
> > execute the file? Can the callee be entered (entrypoint) by the file?
> > Can the caller transition to the callee?) in addition to the new
> > permission check (Can the caller transition under NNP/nosuid to the
> > callee?).
> > 
> > We can't distinguish them on a domain-to-domain basis without
> > introducing a new process2 class, and so far no one has been excited
> > about that.
> 
> Why is that? Eventually that is going to happen anyway. Besides we also have a capability2 and its not like that's a big deal is it?
> 
> But again, its not that big of a deal for me.
> 
> > 
> > > So since the stuff is ugly one way or another might as well make it
> > > consistent with SELinux flexibility goals
> > > 
> > > Just my preference but I dont have a really strong opinion on the
> > > matter
> > > 
> > > > 
> > > > > 
> > > > > On a separate note, I plan to cc luto on the next version of the
> > > > > patch
> > > > > as I suspect he will have concerns about relaxing this constraint
> > > > > on
> > > > > NNP and this likely requires updating
> > > > > Documentation/prctl/no_new_privs*
> > > > > and the man pages that describe NNP behavior.
> > > > > 
> > > > > The other model would be to figure out a way to make the
> > > > > typebounds
> > > > > logic work cleanly in a manner that preserves the desired
> > > > > NNP/nosuid
> > > > > invariant _and_ doesn't require leaking unnecessary accesses into
> > > > > the
> > > > > ancestor domains that make them less secure, plus CIL support for
> > > > > automatically propagating permissions in the desired way.  But I
> > > > > haven't yet come up with a way to do that.  We can do it in some
> > > > > cases
> > > > > by creating typebounds between the object types, e.g.:
> > > > > typebounds parent_t child_t;
> > > > > allow child_t self:process execmem;
> > > > > allow child_t child_exec_t:file entrypoint;
> > > > > allow child_t child_tmp_t:file create;
> > > > > can be allowed via:
> > > > > allow parent_t child_t:process execmem; # an otherwise
> > > > > nonsensical
> > > > > rule
> > > > > typebounds parent_exec_t child_exec_t;
> > > > > typebounds parent_tmp_t child_tmp_t;
> > > > > but this breaks down when there isn't an equivalent type and
> > > > > permission
> > > > > set already allowed to the parent for every type allowed to the
> > > > > child.
> > > 
> > > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 12140 bytes --]

On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho
> > > > > > > .nsa
> > > > > > > .gov
> > > > > > > > 
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds
> > > > > > > > > > @tyc
> > > > > > > > > > ho.n
> > > > > > > > > > sa
> > > > > > > > > > .gov
> > > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > > > <sds
> > > > > > > > > > > > @tyc
> > > > > > > > > > > > ho
> > > > > > > > > > > > .nsa
> > > > > > > > > > > > .gov>
> > > > > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > > restrictions
> > > > > > > > > > might
> > > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > > not
> > > > > > > > > > sure
> > > > > > > > > > it
> > > > > > > > > > is
> > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > 
> > > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > > patch:
> > > > > > > > > > 
> > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > description.  It
> > > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > > so we
> > > > > > > > > > have
> > > > > > > > > > documentation in the git log.
> > > > > > > > > > 
> > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > specific
> > > > > > > > > > to
> > > > > > > > > > NNP
> > > > > > > > > > or
> > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > > good.
> > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > picking
> > > > > > > > > > names;
> > > > > > > > > > how
> > > > > > > > > > about
> > > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > 
> > > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > > encompasses
> > > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > > I
> > > > > > > > > would
> > > > > > > > > have
> > > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > > needed,
> > > > > > > > > to
> > > > > > > > > make
> > > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > > 
> > > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > > it
> > > > > > > > in
> > > > > > > > the
> > > > > > > > patch description.
> > > > > > > 
> > > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > > little
> > > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > > a
> > > > > > > concrete
> > > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > > have to
> > > > > > > pick
> > > > > > > any of the permission names I tossed out, none of those
> > > > > > > were
> > > > > > > very
> > > > > > > good, but I would like to see something that takes both NNP
> > > > > > > and
> > > > > > > nosuid
> > > > > > > into account, or preferably something that doesn't use
> > > > > > > either
> > > > > > > name
> > > > > > > explicitly but still conveys the meaning.
> > > > > > 
> > > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > > execve()
> > > > > > calls by the process and its descendants rather than only to
> > > > > > execve()
> > > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > > more
> > > > > > general term.
> > > > > > 
> > > > > > If that's not viable, I can't think of anything clearer or
> > > > > > better
> > > > > > than
> > > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > > means
> > > > > > (allow
> > > > > > a
> > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > somewhat
> > > > > > ugly
> > > > > > and verbose but it is clear in what it means, which I think
> > > > > > is
> > > > > > more
> > > > > > important. All of your suggestions IMHO were less clear since
> > > > > > they
> > > > > > had
> > > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > > from
> > > > > > reading the permission name what it meant.  The SELinux
> > > > > > domain
> > > > > > transition isn't protected, it isn't restricted, it isn't
> > > > > > clear
> > > > > > what
> > > > > > enable_transition means versus the regular transition or
> > > > > > dyntransition
> > > > > > permissions, and we aren't overriding a transition but rather
> > > > > > allowing
> > > > > > one under NNP/nosuid.
> > > > > > 
> > > > > > The only other alternative I see is to introduce a process2
> > > > > > class
> > > > > > and
> > > > > > use separate nnp_transition and nosuid_transition permissions
> > > > > > (but in
> > > > > > practice I expect them to be both allowed or denied
> > > > > > together).  Note
> > > > > > that this will require two avtab and AVC entries for every
> > > > > > domain
> > > > > > pair
> > > > > > (if we allow whichever one ends up going in the process2
> > > > > > class),
> > > > > > so
> > > > > > that has an impact on policy and AVC size.  Don't really see
> > > > > > that
> > > > > > as
> > > > > > worthwhile.
> > > > > > 
> > > > > > Other approach would be to make the nosuid transition checks
> > > > > > file-
> > > > > > based 
> > > > > > instead so that it would go in the file class (while the nnp
> > > > > > one
> > > > > > would
> > > > > > remain in the process class), but I don't think that's really
> > > > > > what we
> > > > > > want either.  Difference between "Can domain D1 transition
> > > > > > under
> > > > > > nosuid
> > > > > >  to D2?" and "Can domain D1 transition under nosuid when
> > > > > > executing
> > > > > > file
> > > > > > with type T1?".
> > > > > 
> > > > > Just to be clear, we would also be separately checking regular
> > > > > transition permission between the old and new contexts on these
> > > > > transitions, so you would need both:
> > > > > allow D1 D2:process transition;
> > > > > allow D1 T1:file nosuid_transition;
> > > > > if we took the latter approach.
> > > > > 
> > > > > So we wouldn't lose entirely on a domain-to-domain check, but
> > > > > it
> > > > > would
> > > > > no longer be domain-to-domain for the nosuid part.
> > > > > 
> > > > > Whereas with original approach, we end up requiring:
> > > > > allow D1 D2:process transition;
> > > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > > permission
> > > > > name is used
> > > > 
> > > > I don't know if i understand all the ins-and-outs of the matter
> > > > but i
> > > > think i do like the idea of differentiating between
> > > > nosuid_transition
> > > > and nnp_transition
> > > > It provides more flexibility because i might not want to allow
> > > > one or
> > > > the other automatically.
> > > > 
> > > > I do not think it its a good idea to allow a process to transiton
> > > > on
> > > > nosuid mounted filesystems just because i am forced to allow it
> > > > nnp.
> > > 
> > > Can you provide a real use case where you would need to distinguish
> > > them?
> > 
> > Nope I cannot, but its easy to merge the two permissions in policy,
> > and thereby preserving flexibility. It will be hard to deal with a
> > case that might arise that was not foreseen if we cover both
> > scenarios with a single permission.
> > 
> > > 
> > > Currently we handle them the same way (i.e. we don't allow
> > > transitions
> > > unless bounded for both).  The current patch preserves that
> > > consistency, and just provides a way to allow transitions without
> > > bounds for both.  Of course, you still have to be allowed the usual
> > > permissions in order to perform the transition at all (Can the
> > > caller
> > > execute the file? Can the callee be entered (entrypoint) by the
> > > file?
> > > Can the caller transition to the callee?) in addition to the new
> > > permission check (Can the caller transition under NNP/nosuid to the
> > > callee?).
> > > 
> > > We can't distinguish them on a domain-to-domain basis without
> > > introducing a new process2 class, and so far no one has been
> > > excited
> > > about that.
> > 
> > Why is that? Eventually that is going to happen anyway. Besides we
> > also have a capability2 and its not like that's a big deal is it?
> 
> Adding it is fine if we have a genuine need for it, but it doesn't come
> for free. It is potentially an extra avtab entry (policy rule) for
> every allowed domain transition in the policy.  There are far fewer
> capability2 rules in comparison, since those are always domain-self and
>  to date the need for those capabilities has also been relatively
> sparse.

Okay i rest my case, just making sure that this is thought over carefully

> 
> > But again, its not that big of a deal for me.
> > 
> > > 
> > > > So since the stuff is ugly one way or another might as well make
> > > > it
> > > > consistent with SELinux flexibility goals
> > > > 
> > > > Just my preference but I dont have a really strong opinion on the
> > > > matter
> > > > 
> > > > > 
> > > > > > 
> > > > > > On a separate note, I plan to cc luto on the next version of
> > > > > > the
> > > > > > patch
> > > > > > as I suspect he will have concerns about relaxing this
> > > > > > constraint
> > > > > > on
> > > > > > NNP and this likely requires updating
> > > > > > Documentation/prctl/no_new_privs*
> > > > > > and the man pages that describe NNP behavior.
> > > > > > 
> > > > > > The other model would be to figure out a way to make the
> > > > > > typebounds
> > > > > > logic work cleanly in a manner that preserves the desired
> > > > > > NNP/nosuid
> > > > > > invariant _and_ doesn't require leaking unnecessary accesses
> > > > > > into
> > > > > > the
> > > > > > ancestor domains that make them less secure, plus CIL support
> > > > > > for
> > > > > > automatically propagating permissions in the desired
> > > > > > way.  But I
> > > > > > haven't yet come up with a way to do that.  We can do it in
> > > > > > some
> > > > > > cases
> > > > > > by creating typebounds between the object types, e.g.:
> > > > > > typebounds parent_t child_t;
> > > > > > allow child_t self:process execmem;
> > > > > > allow child_t child_exec_t:file entrypoint;
> > > > > > allow child_t child_tmp_t:file create;
> > > > > > can be allowed via:
> > > > > > allow parent_t child_t:process execmem; # an otherwise
> > > > > > nonsensical
> > > > > > rule
> > > > > > typebounds parent_exec_t child_exec_t;
> > > > > > typebounds parent_tmp_t child_tmp_t;
> > > > > > but this breaks down when there isn't an equivalent type and
> > > > > > permission
> > > > > > set already allowed to the parent for every type allowed to
> > > > > > the
> > > > > > child.
> > > > 
> > > > 
> > 
> > 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho
> > > > > > .nsa
> > > > > > .gov
> > > > > > > 
> > > > > > 
> > > > > > wrote:
> > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds
> > > > > > > > > @tyc
> > > > > > > > > ho.n
> > > > > > > > > sa
> > > > > > > > > .gov
> > > > > > > > > > wrote:
> > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > wrote:
> > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > > <sds
> > > > > > > > > > > @tyc
> > > > > > > > > > > ho
> > > > > > > > > > > .nsa
> > > > > > > > > > > .gov>
> > > > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > restrictions
> > > > > > > > > might
> > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > not
> > > > > > > > > sure
> > > > > > > > > it
> > > > > > > > > is
> > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > 
> > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > patch:
> > > > > > > > > 
> > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > description.  It
> > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > so we
> > > > > > > > > have
> > > > > > > > > documentation in the git log.
> > > > > > > > > 
> > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > specific
> > > > > > > > > to
> > > > > > > > > NNP
> > > > > > > > > or
> > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > good.
> > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > picking
> > > > > > > > > names;
> > > > > > > > > how
> > > > > > > > > about
> > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > 
> > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > encompasses
> > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > I
> > > > > > > > would
> > > > > > > > have
> > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > needed,
> > > > > > > > to
> > > > > > > > make
> > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > 
> > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > it
> > > > > > > in
> > > > > > > the
> > > > > > > patch description.
> > > > > > 
> > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > little
> > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > a
> > > > > > concrete
> > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > have to
> > > > > > pick
> > > > > > any of the permission names I tossed out, none of those
> > > > > > were
> > > > > > very
> > > > > > good, but I would like to see something that takes both NNP
> > > > > > and
> > > > > > nosuid
> > > > > > into account, or preferably something that doesn't use
> > > > > > either
> > > > > > name
> > > > > > explicitly but still conveys the meaning.
> > > > > 
> > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > execve()
> > > > > calls by the process and its descendants rather than only to
> > > > > execve()
> > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > more
> > > > > general term.
> > > > > 
> > > > > If that's not viable, I can't think of anything clearer or
> > > > > better
> > > > > than
> > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > means
> > > > > (allow
> > > > > a
> > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > somewhat
> > > > > ugly
> > > > > and verbose but it is clear in what it means, which I think
> > > > > is
> > > > > more
> > > > > important. All of your suggestions IMHO were less clear since
> > > > > they
> > > > > had
> > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > from
> > > > > reading the permission name what it meant.  The SELinux
> > > > > domain
> > > > > transition isn't protected, it isn't restricted, it isn't
> > > > > clear
> > > > > what
> > > > > enable_transition means versus the regular transition or
> > > > > dyntransition
> > > > > permissions, and we aren't overriding a transition but rather
> > > > > allowing
> > > > > one under NNP/nosuid.
> > > > > 
> > > > > The only other alternative I see is to introduce a process2
> > > > > class
> > > > > and
> > > > > use separate nnp_transition and nosuid_transition permissions
> > > > > (but in
> > > > > practice I expect them to be both allowed or denied
> > > > > together).  Note
> > > > > that this will require two avtab and AVC entries for every
> > > > > domain
> > > > > pair
> > > > > (if we allow whichever one ends up going in the process2
> > > > > class),
> > > > > so
> > > > > that has an impact on policy and AVC size.  Don't really see
> > > > > that
> > > > > as
> > > > > worthwhile.
> > > > > 
> > > > > Other approach would be to make the nosuid transition checks
> > > > > file-
> > > > > based 
> > > > > instead so that it would go in the file class (while the nnp
> > > > > one
> > > > > would
> > > > > remain in the process class), but I don't think that's really
> > > > > what we
> > > > > want either.  Difference between "Can domain D1 transition
> > > > > under
> > > > > nosuid
> > > > >  to D2?" and "Can domain D1 transition under nosuid when
> > > > > executing
> > > > > file
> > > > > with type T1?".
> > > > 
> > > > Just to be clear, we would also be separately checking regular
> > > > transition permission between the old and new contexts on these
> > > > transitions, so you would need both:
> > > > allow D1 D2:process transition;
> > > > allow D1 T1:file nosuid_transition;
> > > > if we took the latter approach.
> > > > 
> > > > So we wouldn't lose entirely on a domain-to-domain check, but
> > > > it
> > > > would
> > > > no longer be domain-to-domain for the nosuid part.
> > > > 
> > > > Whereas with original approach, we end up requiring:
> > > > allow D1 D2:process transition;
> > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > permission
> > > > name is used
> > > 
> > > I don't know if i understand all the ins-and-outs of the matter
> > > but i
> > > think i do like the idea of differentiating between
> > > nosuid_transition
> > > and nnp_transition
> > > It provides more flexibility because i might not want to allow
> > > one or
> > > the other automatically.
> > > 
> > > I do not think it its a good idea to allow a process to transiton
> > > on
> > > nosuid mounted filesystems just because i am forced to allow it
> > > nnp.
> > 
> > Can you provide a real use case where you would need to distinguish
> > them?
> 
> Nope I cannot, but its easy to merge the two permissions in policy,
> and thereby preserving flexibility. It will be hard to deal with a
> case that might arise that was not foreseen if we cover both
> scenarios with a single permission.
> 
> > 
> > Currently we handle them the same way (i.e. we don't allow
> > transitions
> > unless bounded for both).  The current patch preserves that
> > consistency, and just provides a way to allow transitions without
> > bounds for both.  Of course, you still have to be allowed the usual
> > permissions in order to perform the transition at all (Can the
> > caller
> > execute the file? Can the callee be entered (entrypoint) by the
> > file?
> > Can the caller transition to the callee?) in addition to the new
> > permission check (Can the caller transition under NNP/nosuid to the
> > callee?).
> > 
> > We can't distinguish them on a domain-to-domain basis without
> > introducing a new process2 class, and so far no one has been
> > excited
> > about that.
> 
> Why is that? Eventually that is going to happen anyway. Besides we
> also have a capability2 and its not like that's a big deal is it?

Adding it is fine if we have a genuine need for it, but it doesn't come
for free. It is potentially an extra avtab entry (policy rule) for
every allowed domain transition in the policy.  There are far fewer
capability2 rules in comparison, since those are always domain-self and
 to date the need for those capabilities has also been relatively
sparse.

> But again, its not that big of a deal for me.
> 
> > 
> > > So since the stuff is ugly one way or another might as well make
> > > it
> > > consistent with SELinux flexibility goals
> > > 
> > > Just my preference but I dont have a really strong opinion on the
> > > matter
> > > 
> > > > 
> > > > > 
> > > > > On a separate note, I plan to cc luto on the next version of
> > > > > the
> > > > > patch
> > > > > as I suspect he will have concerns about relaxing this
> > > > > constraint
> > > > > on
> > > > > NNP and this likely requires updating
> > > > > Documentation/prctl/no_new_privs*
> > > > > and the man pages that describe NNP behavior.
> > > > > 
> > > > > The other model would be to figure out a way to make the
> > > > > typebounds
> > > > > logic work cleanly in a manner that preserves the desired
> > > > > NNP/nosuid
> > > > > invariant _and_ doesn't require leaking unnecessary accesses
> > > > > into
> > > > > the
> > > > > ancestor domains that make them less secure, plus CIL support
> > > > > for
> > > > > automatically propagating permissions in the desired
> > > > > way.  But I
> > > > > haven't yet come up with a way to do that.  We can do it in
> > > > > some
> > > > > cases
> > > > > by creating typebounds between the object types, e.g.:
> > > > > typebounds parent_t child_t;
> > > > > allow child_t self:process execmem;
> > > > > allow child_t child_exec_t:file entrypoint;
> > > > > allow child_t child_tmp_t:file create;
> > > > > can be allowed via:
> > > > > allow parent_t child_t:process execmem; # an otherwise
> > > > > nonsensical
> > > > > rule
> > > > > typebounds parent_exec_t child_exec_t;
> > > > > typebounds parent_tmp_t child_tmp_t;
> > > > > but this breaks down when there isn't an equivalent type and
> > > > > permission
> > > > > set already allowed to the parent for every type allowed to
> > > > > the
> > > > > child.
> > > 
> > > 
> 
> 

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 13270 bytes --]

On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho
> > > > > > > > .nsa
> > > > > > > > .gov
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote:
> > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds
> > > > > > > > > > > @tyc
> > > > > > > > > > > ho.n
> > > > > > > > > > > sa
> > > > > > > > > > > .gov
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley
> > > > > > > > > > > > > <sds
> > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > ho
> > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > While I think splitting the NNP/nosuid transition
> > > > > > > > > > > restrictions
> > > > > > > > > > > might
> > > > > > > > > > > be a good idea under the new policy capability, I'm
> > > > > > > > > > > not
> > > > > > > > > > > sure
> > > > > > > > > > > it
> > > > > > > > > > > is
> > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > 
> > > > > > > > > > > With that in mind, let's do two things with this
> > > > > > > > > > > patch:
> > > > > > > > > > > 
> > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > description.  It
> > > > > > > > > > > doesn't need much text, but something would be good
> > > > > > > > > > > so we
> > > > > > > > > > > have
> > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > 
> > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > specific
> > > > > > > > > > > to
> > > > > > > > > > > NNP
> > > > > > > > > > > or
> > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less than
> > > > > > > > > > > good.
> > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > picking
> > > > > > > > > > > names;
> > > > > > > > > > > how
> > > > > > > > > > > about
> > > > > > > > > > > "protected_transition"?  "restricted_transition"?
> > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > 
> > > > > > > > > > I vote for nnp_transition anyway.  "No New Privileges"
> > > > > > > > > > encompasses
> > > > > > > > > > nosuid in my mind.  If the two perms had been separated
> > > > > > > > > > I
> > > > > > > > > > would
> > > > > > > > > > have
> > > > > > > > > > been inclined to allow both every time one of them was
> > > > > > > > > > needed,
> > > > > > > > > > to
> > > > > > > > > > make
> > > > > > > > > > sure no one was surprised by the behavior difference.
> > > > > > > > > 
> > > > > > > > > I agree; I'll keep it as nnp_transition and just document
> > > > > > > > > it
> > > > > > > > > in
> > > > > > > > > the
> > > > > > > > > patch description.
> > > > > > > > 
> > > > > > > > Sorry to be a stubborn about this, but nnp_transition makes
> > > > > > > > little
> > > > > > > > sense for the nosuid restriction.  Like it or not, NNP has
> > > > > > > > a
> > > > > > > > concrete
> > > > > > > > meaning which is distinct from nosuid mounts.  We don't
> > > > > > > > have to
> > > > > > > > pick
> > > > > > > > any of the permission names I tossed out, none of those
> > > > > > > > were
> > > > > > > > very
> > > > > > > > good, but I would like to see something that takes both NNP
> > > > > > > > and
> > > > > > > > nosuid
> > > > > > > > into account, or preferably something that doesn't use
> > > > > > > > either
> > > > > > > > name
> > > > > > > > explicitly but still conveys the meaning.
> > > > > > > 
> > > > > > > NNP is essentially a superset of nosuid; it applies to all
> > > > > > > execve()
> > > > > > > calls by the process and its descendants rather than only to
> > > > > > > execve()
> > > > > > > calls on specially marked filesystems.  So I viewed it as the
> > > > > > > more
> > > > > > > general term.
> > > > > > > 
> > > > > > > If that's not viable, I can't think of anything clearer or
> > > > > > > better
> > > > > > > than
> > > > > > > nnp_nosuid_transition.  That clearly links it to what it
> > > > > > > means
> > > > > > > (allow
> > > > > > > a
> > > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > > somewhat
> > > > > > > ugly
> > > > > > > and verbose but it is clear in what it means, which I think
> > > > > > > is
> > > > > > > more
> > > > > > > important. All of your suggestions IMHO were less clear since
> > > > > > > they
> > > > > > > had
> > > > > > > no clear linkage to either NNP or nosuid, and I couldn't tell
> > > > > > > from
> > > > > > > reading the permission name what it meant.  The SELinux
> > > > > > > domain
> > > > > > > transition isn't protected, it isn't restricted, it isn't
> > > > > > > clear
> > > > > > > what
> > > > > > > enable_transition means versus the regular transition or
> > > > > > > dyntransition
> > > > > > > permissions, and we aren't overriding a transition but rather
> > > > > > > allowing
> > > > > > > one under NNP/nosuid.
> > > > > > > 
> > > > > > > The only other alternative I see is to introduce a process2
> > > > > > > class
> > > > > > > and
> > > > > > > use separate nnp_transition and nosuid_transition permissions
> > > > > > > (but in
> > > > > > > practice I expect them to be both allowed or denied
> > > > > > > together).  Note
> > > > > > > that this will require two avtab and AVC entries for every
> > > > > > > domain
> > > > > > > pair
> > > > > > > (if we allow whichever one ends up going in the process2
> > > > > > > class),
> > > > > > > so
> > > > > > > that has an impact on policy and AVC size.  Don't really see
> > > > > > > that
> > > > > > > as
> > > > > > > worthwhile.
> > > > > > > 
> > > > > > > Other approach would be to make the nosuid transition checks
> > > > > > > file-
> > > > > > > based 
> > > > > > > instead so that it would go in the file class (while the nnp
> > > > > > > one
> > > > > > > would
> > > > > > > remain in the process class), but I don't think that's really
> > > > > > > what we
> > > > > > > want either.  Difference between "Can domain D1 transition
> > > > > > > under
> > > > > > > nosuid
> > > > > > >  to D2?" and "Can domain D1 transition under nosuid when
> > > > > > > executing
> > > > > > > file
> > > > > > > with type T1?".
> > > > > > 
> > > > > > Just to be clear, we would also be separately checking regular
> > > > > > transition permission between the old and new contexts on these
> > > > > > transitions, so you would need both:
> > > > > > allow D1 D2:process transition;
> > > > > > allow D1 T1:file nosuid_transition;
> > > > > > if we took the latter approach.
> > > > > > 
> > > > > > So we wouldn't lose entirely on a domain-to-domain check, but
> > > > > > it
> > > > > > would
> > > > > > no longer be domain-to-domain for the nosuid part.
> > > > > > 
> > > > > > Whereas with original approach, we end up requiring:
> > > > > > allow D1 D2:process transition;
> > > > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > > > permission
> > > > > > name is used
> > > > > 
> > > > > I don't know if i understand all the ins-and-outs of the matter
> > > > > but i
> > > > > think i do like the idea of differentiating between
> > > > > nosuid_transition
> > > > > and nnp_transition
> > > > > It provides more flexibility because i might not want to allow
> > > > > one or
> > > > > the other automatically.
> > > > > 
> > > > > I do not think it its a good idea to allow a process to transiton
> > > > > on
> > > > > nosuid mounted filesystems just because i am forced to allow it
> > > > > nnp.
> > > > 
> > > > Can you provide a real use case where you would need to distinguish
> > > > them?
> > > 
> > > Nope I cannot, but its easy to merge the two permissions in policy,
> > > and thereby preserving flexibility. It will be hard to deal with a
> > > case that might arise that was not foreseen if we cover both
> > > scenarios with a single permission.
> > > 
> > > > 
> > > > Currently we handle them the same way (i.e. we don't allow
> > > > transitions
> > > > unless bounded for both).  The current patch preserves that
> > > > consistency, and just provides a way to allow transitions without
> > > > bounds for both.  Of course, you still have to be allowed the usual
> > > > permissions in order to perform the transition at all (Can the
> > > > caller
> > > > execute the file? Can the callee be entered (entrypoint) by the
> > > > file?
> > > > Can the caller transition to the callee?) in addition to the new
> > > > permission check (Can the caller transition under NNP/nosuid to the
> > > > callee?).
> > > > 
> > > > We can't distinguish them on a domain-to-domain basis without
> > > > introducing a new process2 class, and so far no one has been
> > > > excited
> > > > about that.
> > > 
> > > Why is that? Eventually that is going to happen anyway. Besides we
> > > also have a capability2 and its not like that's a big deal is it?
> > 
> > Adding it is fine if we have a genuine need for it, but it doesn't come
> > for free. It is potentially an extra avtab entry (policy rule) for
> > every allowed domain transition in the policy.  There are far fewer
> > capability2 rules in comparison, since those are always domain-self and
> >  to date the need for those capabilities has also been relatively
> > sparse.
> 
> Okay i rest my case, just making sure that this is thought over carefully

Aw heck on more argument:

How about adding another policycap for that?
Also if were talking about excessive avtab entries. cap(2)?_userns seems pretty excessive to me (you pretty much end duplicating cap and cap2 equivalents for any process that needs to deal with userns)

> 
> > 
> > > But again, its not that big of a deal for me.
> > > 
> > > > 
> > > > > So since the stuff is ugly one way or another might as well make
> > > > > it
> > > > > consistent with SELinux flexibility goals
> > > > > 
> > > > > Just my preference but I dont have a really strong opinion on the
> > > > > matter
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > On a separate note, I plan to cc luto on the next version of
> > > > > > > the
> > > > > > > patch
> > > > > > > as I suspect he will have concerns about relaxing this
> > > > > > > constraint
> > > > > > > on
> > > > > > > NNP and this likely requires updating
> > > > > > > Documentation/prctl/no_new_privs*
> > > > > > > and the man pages that describe NNP behavior.
> > > > > > > 
> > > > > > > The other model would be to figure out a way to make the
> > > > > > > typebounds
> > > > > > > logic work cleanly in a manner that preserves the desired
> > > > > > > NNP/nosuid
> > > > > > > invariant _and_ doesn't require leaking unnecessary accesses
> > > > > > > into
> > > > > > > the
> > > > > > > ancestor domains that make them less secure, plus CIL support
> > > > > > > for
> > > > > > > automatically propagating permissions in the desired
> > > > > > > way.  But I
> > > > > > > haven't yet come up with a way to do that.  We can do it in
> > > > > > > some
> > > > > > > cases
> > > > > > > by creating typebounds between the object types, e.g.:
> > > > > > > typebounds parent_t child_t;
> > > > > > > allow child_t self:process execmem;
> > > > > > > allow child_t child_exec_t:file entrypoint;
> > > > > > > allow child_t child_tmp_t:file create;
> > > > > > > can be allowed via:
> > > > > > > allow parent_t child_t:process execmem; # an otherwise
> > > > > > > nonsensical
> > > > > > > rule
> > > > > > > typebounds parent_exec_t child_exec_t;
> > > > > > > typebounds parent_tmp_t child_tmp_t;
> > > > > > > but this breaks down when there isn't an equivalent type and
> > > > > > > permission
> > > > > > > set already allowed to the parent for every type allowed to
> > > > > > > the
> > > > > > > child.
> > > > > 
> > > > > 
> > > 
> > > 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Stephen Smalley]

On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > wrote:
> > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > wrote:
> > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds
> > > > > > > > > @tycho
> > > > > > > > > .nsa
> > > > > > > > > .gov
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > wrote:
> > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > Smalley <sds
> > > > > > > > > > > > @tyc
> > > > > > > > > > > > ho.n
> > > > > > > > > > > > sa
> > > > > > > > > > > > .gov
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > > <sds
> > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > transition
> > > > > > > > > > > > restrictions
> > > > > > > > > > > > might
> > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > I'm
> > > > > > > > > > > > not
> > > > > > > > > > > > sure
> > > > > > > > > > > > it
> > > > > > > > > > > > is
> > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > 
> > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > this
> > > > > > > > > > > > patch:
> > > > > > > > > > > > 
> > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > description.  It
> > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > good
> > > > > > > > > > > > so we
> > > > > > > > > > > > have
> > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > 
> > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > specific
> > > > > > > > > > > > to
> > > > > > > > > > > > NNP
> > > > > > > > > > > > or
> > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > than
> > > > > > > > > > > > good.
> > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > picking
> > > > > > > > > > > > names;
> > > > > > > > > > > > how
> > > > > > > > > > > > about
> > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > "?
> > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > 
> > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > Privileges"
> > > > > > > > > > > encompasses
> > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > separated
> > > > > > > > > > > I
> > > > > > > > > > > would
> > > > > > > > > > > have
> > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > them was
> > > > > > > > > > > needed,
> > > > > > > > > > > to
> > > > > > > > > > > make
> > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > difference.
> > > > > > > > > > 
> > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > document
> > > > > > > > > > it
> > > > > > > > > > in
> > > > > > > > > > the
> > > > > > > > > > patch description.
> > > > > > > > > 
> > > > > > > > > Sorry to be a stubborn about this, but nnp_transition
> > > > > > > > > makes
> > > > > > > > > little
> > > > > > > > > sense for the nosuid restriction.  Like it or not,
> > > > > > > > > NNP has
> > > > > > > > > a
> > > > > > > > > concrete
> > > > > > > > > meaning which is distinct from nosuid mounts.  We
> > > > > > > > > don't
> > > > > > > > > have to
> > > > > > > > > pick
> > > > > > > > > any of the permission names I tossed out, none of
> > > > > > > > > those
> > > > > > > > > were
> > > > > > > > > very
> > > > > > > > > good, but I would like to see something that takes
> > > > > > > > > both NNP
> > > > > > > > > and
> > > > > > > > > nosuid
> > > > > > > > > into account, or preferably something that doesn't
> > > > > > > > > use
> > > > > > > > > either
> > > > > > > > > name
> > > > > > > > > explicitly but still conveys the meaning.
> > > > > > > > 
> > > > > > > > NNP is essentially a superset of nosuid; it applies to
> > > > > > > > all
> > > > > > > > execve()
> > > > > > > > calls by the process and its descendants rather than
> > > > > > > > only to
> > > > > > > > execve()
> > > > > > > > calls on specially marked filesystems.  So I viewed it
> > > > > > > > as the
> > > > > > > > more
> > > > > > > > general term.
> > > > > > > > 
> > > > > > > > If that's not viable, I can't think of anything clearer
> > > > > > > > or
> > > > > > > > better
> > > > > > > > than
> > > > > > > > nnp_nosuid_transition.  That clearly links it to what
> > > > > > > > it
> > > > > > > > means
> > > > > > > > (allow
> > > > > > > > a
> > > > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > > > somewhat
> > > > > > > > ugly
> > > > > > > > and verbose but it is clear in what it means, which I
> > > > > > > > think
> > > > > > > > is
> > > > > > > > more
> > > > > > > > important. All of your suggestions IMHO were less clear
> > > > > > > > since
> > > > > > > > they
> > > > > > > > had
> > > > > > > > no clear linkage to either NNP or nosuid, and I
> > > > > > > > couldn't tell
> > > > > > > > from
> > > > > > > > reading the permission name what it meant.  The SELinux
> > > > > > > > domain
> > > > > > > > transition isn't protected, it isn't restricted, it
> > > > > > > > isn't
> > > > > > > > clear
> > > > > > > > what
> > > > > > > > enable_transition means versus the regular transition
> > > > > > > > or
> > > > > > > > dyntransition
> > > > > > > > permissions, and we aren't overriding a transition but
> > > > > > > > rather
> > > > > > > > allowing
> > > > > > > > one under NNP/nosuid.
> > > > > > > > 
> > > > > > > > The only other alternative I see is to introduce a
> > > > > > > > process2
> > > > > > > > class
> > > > > > > > and
> > > > > > > > use separate nnp_transition and nosuid_transition
> > > > > > > > permissions
> > > > > > > > (but in
> > > > > > > > practice I expect them to be both allowed or denied
> > > > > > > > together).  Note
> > > > > > > > that this will require two avtab and AVC entries for
> > > > > > > > every
> > > > > > > > domain
> > > > > > > > pair
> > > > > > > > (if we allow whichever one ends up going in the
> > > > > > > > process2
> > > > > > > > class),
> > > > > > > > so
> > > > > > > > that has an impact on policy and AVC size.  Don't
> > > > > > > > really see
> > > > > > > > that
> > > > > > > > as
> > > > > > > > worthwhile.
> > > > > > > > 
> > > > > > > > Other approach would be to make the nosuid transition
> > > > > > > > checks
> > > > > > > > file-
> > > > > > > > based 
> > > > > > > > instead so that it would go in the file class (while
> > > > > > > > the nnp
> > > > > > > > one
> > > > > > > > would
> > > > > > > > remain in the process class), but I don't think that's
> > > > > > > > really
> > > > > > > > what we
> > > > > > > > want either.  Difference between "Can domain D1
> > > > > > > > transition
> > > > > > > > under
> > > > > > > > nosuid
> > > > > > > >  to D2?" and "Can domain D1 transition under nosuid
> > > > > > > > when
> > > > > > > > executing
> > > > > > > > file
> > > > > > > > with type T1?".
> > > > > > > 
> > > > > > > Just to be clear, we would also be separately checking
> > > > > > > regular
> > > > > > > transition permission between the old and new contexts on
> > > > > > > these
> > > > > > > transitions, so you would need both:
> > > > > > > allow D1 D2:process transition;
> > > > > > > allow D1 T1:file nosuid_transition;
> > > > > > > if we took the latter approach.
> > > > > > > 
> > > > > > > So we wouldn't lose entirely on a domain-to-domain check,
> > > > > > > but
> > > > > > > it
> > > > > > > would
> > > > > > > no longer be domain-to-domain for the nosuid part.
> > > > > > > 
> > > > > > > Whereas with original approach, we end up requiring:
> > > > > > > allow D1 D2:process transition;
> > > > > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > > > > permission
> > > > > > > name is used
> > > > > > 
> > > > > > I don't know if i understand all the ins-and-outs of the
> > > > > > matter
> > > > > > but i
> > > > > > think i do like the idea of differentiating between
> > > > > > nosuid_transition
> > > > > > and nnp_transition
> > > > > > It provides more flexibility because i might not want to
> > > > > > allow
> > > > > > one or
> > > > > > the other automatically.
> > > > > > 
> > > > > > I do not think it its a good idea to allow a process to
> > > > > > transiton
> > > > > > on
> > > > > > nosuid mounted filesystems just because i am forced to
> > > > > > allow it
> > > > > > nnp.
> > > > > 
> > > > > Can you provide a real use case where you would need to
> > > > > distinguish
> > > > > them?
> > > > 
> > > > Nope I cannot, but its easy to merge the two permissions in
> > > > policy,
> > > > and thereby preserving flexibility. It will be hard to deal
> > > > with a
> > > > case that might arise that was not foreseen if we cover both
> > > > scenarios with a single permission.
> > > > 
> > > > > 
> > > > > Currently we handle them the same way (i.e. we don't allow
> > > > > transitions
> > > > > unless bounded for both).  The current patch preserves that
> > > > > consistency, and just provides a way to allow transitions
> > > > > without
> > > > > bounds for both.  Of course, you still have to be allowed the
> > > > > usual
> > > > > permissions in order to perform the transition at all (Can
> > > > > the
> > > > > caller
> > > > > execute the file? Can the callee be entered (entrypoint) by
> > > > > the
> > > > > file?
> > > > > Can the caller transition to the callee?) in addition to the
> > > > > new
> > > > > permission check (Can the caller transition under NNP/nosuid
> > > > > to the
> > > > > callee?).
> > > > > 
> > > > > We can't distinguish them on a domain-to-domain basis without
> > > > > introducing a new process2 class, and so far no one has been
> > > > > excited
> > > > > about that.
> > > > 
> > > > Why is that? Eventually that is going to happen anyway. Besides
> > > > we
> > > > also have a capability2 and its not like that's a big deal is
> > > > it?
> > > 
> > > Adding it is fine if we have a genuine need for it, but it
> > > doesn't come
> > > for free. It is potentially an extra avtab entry (policy rule)
> > > for
> > > every allowed domain transition in the policy.  There are far
> > > fewer
> > > capability2 rules in comparison, since those are always domain-
> > > self and
> > >  to date the need for those capabilities has also been relatively
> > > sparse.
> > 
> > Okay i rest my case, just making sure that this is thought over
> > carefully
> 
> Aw heck on more argument:
> 
> How about adding another policycap for that?

I doubt we want to require policy writers and analysts to have to check
a policy capability to determine whether nosuid transitions depend on
their own unique permission or the one shared with nnp transitions.
Complexity for no real gain.

> Also if were talking about excessive avtab entries. cap(2)?_userns
> seems pretty excessive to me (you pretty much end duplicating cap and
> cap2 equivalents for any process that needs to deal with userns)

They seem to be fairly sparsely used on Fedora so far compared to
capability/capability2:

$ sesearch -A -c cap_userns | wc -l
102
$ sesearch -A -c cap2_userns | wc -l
2
$ sesearch -A -c capability | wc -l
1156
$ sesearch -A -c capability2 | wc -l
148

Also, my hope would be that with cap_userns/cap2_userns, they can
remove a number of capability/capabilty2 rules that should no longer be
required for domains that only need capabilities within a non-init
userns.

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 14480 bytes --]

On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:
> On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > > wrote:
> > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds
> > > > > > > > > > @tycho
> > > > > > > > > > .nsa
> > > > > > > > > > .gov
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > > Smalley <sds
> > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > ho.n
> > > > > > > > > > > > > sa
> > > > > > > > > > > > > .gov
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > > > <sds
> > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > > transition
> > > > > > > > > > > > > restrictions
> > > > > > > > > > > > > might
> > > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > > I'm
> > > > > > > > > > > > > not
> > > > > > > > > > > > > sure
> > > > > > > > > > > > > it
> > > > > > > > > > > > > is
> > > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > > this
> > > > > > > > > > > > > patch:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > > description.  It
> > > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > > good
> > > > > > > > > > > > > so we
> > > > > > > > > > > > > have
> > > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > > specific
> > > > > > > > > > > > > to
> > > > > > > > > > > > > NNP
> > > > > > > > > > > > > or
> > > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > > than
> > > > > > > > > > > > > good.
> > > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > > picking
> > > > > > > > > > > > > names;
> > > > > > > > > > > > > how
> > > > > > > > > > > > > about
> > > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > > "?
> > > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > > 
> > > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > > Privileges"
> > > > > > > > > > > > encompasses
> > > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > > separated
> > > > > > > > > > > > I
> > > > > > > > > > > > would
> > > > > > > > > > > > have
> > > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > > them was
> > > > > > > > > > > > needed,
> > > > > > > > > > > > to
> > > > > > > > > > > > make
> > > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > > difference.
> > > > > > > > > > > 
> > > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > > document
> > > > > > > > > > > it
> > > > > > > > > > > in
> > > > > > > > > > > the
> > > > > > > > > > > patch description.
> > > > > > > > > > 
> > > > > > > > > > Sorry to be a stubborn about this, but nnp_transition
> > > > > > > > > > makes
> > > > > > > > > > little
> > > > > > > > > > sense for the nosuid restriction.  Like it or not,
> > > > > > > > > > NNP has
> > > > > > > > > > a
> > > > > > > > > > concrete
> > > > > > > > > > meaning which is distinct from nosuid mounts.  We
> > > > > > > > > > don't
> > > > > > > > > > have to
> > > > > > > > > > pick
> > > > > > > > > > any of the permission names I tossed out, none of
> > > > > > > > > > those
> > > > > > > > > > were
> > > > > > > > > > very
> > > > > > > > > > good, but I would like to see something that takes
> > > > > > > > > > both NNP
> > > > > > > > > > and
> > > > > > > > > > nosuid
> > > > > > > > > > into account, or preferably something that doesn't
> > > > > > > > > > use
> > > > > > > > > > either
> > > > > > > > > > name
> > > > > > > > > > explicitly but still conveys the meaning.
> > > > > > > > > 
> > > > > > > > > NNP is essentially a superset of nosuid; it applies to
> > > > > > > > > all
> > > > > > > > > execve()
> > > > > > > > > calls by the process and its descendants rather than
> > > > > > > > > only to
> > > > > > > > > execve()
> > > > > > > > > calls on specially marked filesystems.  So I viewed it
> > > > > > > > > as the
> > > > > > > > > more
> > > > > > > > > general term.
> > > > > > > > > 
> > > > > > > > > If that's not viable, I can't think of anything clearer
> > > > > > > > > or
> > > > > > > > > better
> > > > > > > > > than
> > > > > > > > > nnp_nosuid_transition.  That clearly links it to what
> > > > > > > > > it
> > > > > > > > > means
> > > > > > > > > (allow
> > > > > > > > > a
> > > > > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > > > > somewhat
> > > > > > > > > ugly
> > > > > > > > > and verbose but it is clear in what it means, which I
> > > > > > > > > think
> > > > > > > > > is
> > > > > > > > > more
> > > > > > > > > important. All of your suggestions IMHO were less clear
> > > > > > > > > since
> > > > > > > > > they
> > > > > > > > > had
> > > > > > > > > no clear linkage to either NNP or nosuid, and I
> > > > > > > > > couldn't tell
> > > > > > > > > from
> > > > > > > > > reading the permission name what it meant.  The SELinux
> > > > > > > > > domain
> > > > > > > > > transition isn't protected, it isn't restricted, it
> > > > > > > > > isn't
> > > > > > > > > clear
> > > > > > > > > what
> > > > > > > > > enable_transition means versus the regular transition
> > > > > > > > > or
> > > > > > > > > dyntransition
> > > > > > > > > permissions, and we aren't overriding a transition but
> > > > > > > > > rather
> > > > > > > > > allowing
> > > > > > > > > one under NNP/nosuid.
> > > > > > > > > 
> > > > > > > > > The only other alternative I see is to introduce a
> > > > > > > > > process2
> > > > > > > > > class
> > > > > > > > > and
> > > > > > > > > use separate nnp_transition and nosuid_transition
> > > > > > > > > permissions
> > > > > > > > > (but in
> > > > > > > > > practice I expect them to be both allowed or denied
> > > > > > > > > together).  Note
> > > > > > > > > that this will require two avtab and AVC entries for
> > > > > > > > > every
> > > > > > > > > domain
> > > > > > > > > pair
> > > > > > > > > (if we allow whichever one ends up going in the
> > > > > > > > > process2
> > > > > > > > > class),
> > > > > > > > > so
> > > > > > > > > that has an impact on policy and AVC size.  Don't
> > > > > > > > > really see
> > > > > > > > > that
> > > > > > > > > as
> > > > > > > > > worthwhile.
> > > > > > > > > 
> > > > > > > > > Other approach would be to make the nosuid transition
> > > > > > > > > checks
> > > > > > > > > file-
> > > > > > > > > based 
> > > > > > > > > instead so that it would go in the file class (while
> > > > > > > > > the nnp
> > > > > > > > > one
> > > > > > > > > would
> > > > > > > > > remain in the process class), but I don't think that's
> > > > > > > > > really
> > > > > > > > > what we
> > > > > > > > > want either.  Difference between "Can domain D1
> > > > > > > > > transition
> > > > > > > > > under
> > > > > > > > > nosuid
> > > > > > > > >  to D2?" and "Can domain D1 transition under nosuid
> > > > > > > > > when
> > > > > > > > > executing
> > > > > > > > > file
> > > > > > > > > with type T1?".
> > > > > > > > 
> > > > > > > > Just to be clear, we would also be separately checking
> > > > > > > > regular
> > > > > > > > transition permission between the old and new contexts on
> > > > > > > > these
> > > > > > > > transitions, so you would need both:
> > > > > > > > allow D1 D2:process transition;
> > > > > > > > allow D1 T1:file nosuid_transition;
> > > > > > > > if we took the latter approach.
> > > > > > > > 
> > > > > > > > So we wouldn't lose entirely on a domain-to-domain check,
> > > > > > > > but
> > > > > > > > it
> > > > > > > > would
> > > > > > > > no longer be domain-to-domain for the nosuid part.
> > > > > > > > 
> > > > > > > > Whereas with original approach, we end up requiring:
> > > > > > > > allow D1 D2:process transition;
> > > > > > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > > > > > permission
> > > > > > > > name is used
> > > > > > > 
> > > > > > > I don't know if i understand all the ins-and-outs of the
> > > > > > > matter
> > > > > > > but i
> > > > > > > think i do like the idea of differentiating between
> > > > > > > nosuid_transition
> > > > > > > and nnp_transition
> > > > > > > It provides more flexibility because i might not want to
> > > > > > > allow
> > > > > > > one or
> > > > > > > the other automatically.
> > > > > > > 
> > > > > > > I do not think it its a good idea to allow a process to
> > > > > > > transiton
> > > > > > > on
> > > > > > > nosuid mounted filesystems just because i am forced to
> > > > > > > allow it
> > > > > > > nnp.
> > > > > > 
> > > > > > Can you provide a real use case where you would need to
> > > > > > distinguish
> > > > > > them?
> > > > > 
> > > > > Nope I cannot, but its easy to merge the two permissions in
> > > > > policy,
> > > > > and thereby preserving flexibility. It will be hard to deal
> > > > > with a
> > > > > case that might arise that was not foreseen if we cover both
> > > > > scenarios with a single permission.
> > > > > 
> > > > > > 
> > > > > > Currently we handle them the same way (i.e. we don't allow
> > > > > > transitions
> > > > > > unless bounded for both).  The current patch preserves that
> > > > > > consistency, and just provides a way to allow transitions
> > > > > > without
> > > > > > bounds for both.  Of course, you still have to be allowed the
> > > > > > usual
> > > > > > permissions in order to perform the transition at all (Can
> > > > > > the
> > > > > > caller
> > > > > > execute the file? Can the callee be entered (entrypoint) by
> > > > > > the
> > > > > > file?
> > > > > > Can the caller transition to the callee?) in addition to the
> > > > > > new
> > > > > > permission check (Can the caller transition under NNP/nosuid
> > > > > > to the
> > > > > > callee?).
> > > > > > 
> > > > > > We can't distinguish them on a domain-to-domain basis without
> > > > > > introducing a new process2 class, and so far no one has been
> > > > > > excited
> > > > > > about that.
> > > > > 
> > > > > Why is that? Eventually that is going to happen anyway. Besides
> > > > > we
> > > > > also have a capability2 and its not like that's a big deal is
> > > > > it?
> > > > 
> > > > Adding it is fine if we have a genuine need for it, but it
> > > > doesn't come
> > > > for free. It is potentially an extra avtab entry (policy rule)
> > > > for
> > > > every allowed domain transition in the policy.  There are far
> > > > fewer
> > > > capability2 rules in comparison, since those are always domain-
> > > > self and
> > > >  to date the need for those capabilities has also been relatively
> > > > sparse.
> > > 
> > > Okay i rest my case, just making sure that this is thought over
> > > carefully
> > 
> > Aw heck on more argument:
> > 
> > How about adding another policycap for that?
> 
> I doubt we want to require policy writers and analysts to have to check
> a policy capability to determine whether nosuid transitions depend on
> their own unique permission or the one shared with nnp transitions.
> Complexity for no real gain.

Yes well "no real gain" I think basically were just saying: nosuid doesnt apply to selinux anymore

If i have an executable file type for a daemon that uses NNP and two executables one on a nosuid mounted slice and another one on a non-nosuid mounted partition, then basically from an selinux perspective the nosuid is meaningless.

You can argue that one can still use transition rules, but that doesnt fly in this case I think
 
> 
> > Also if were talking about excessive avtab entries. cap(2)?_userns
> > seems pretty excessive to me (you pretty much end duplicating cap and
> > cap2 equivalents for any process that needs to deal with userns)
> 
> They seem to be fairly sparsely used on Fedora so far compared to
> capability/capability2:
> 
> $ sesearch -A -c cap_userns | wc -l
> 102
> $ sesearch -A -c cap2_userns | wc -l
> 2
> $ sesearch -A -c capability | wc -l
> 1156
> $ sesearch -A -c capability2 | wc -l
> 148
> 
> Also, my hope would be that with cap_userns/cap2_userns, they can
> remove a number of capability/capabilty2 rules that should no longer be
> required for domains that only need capabilities within a non-init
> userns.
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Paul Moore]

On Thu, Jul 13, 2017 at 11:48 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
>> Sorry to be a stubborn about this, but nnp_transition makes little
>> sense for the nosuid restriction.  Like it or not, NNP has a concrete
>> meaning which is distinct from nosuid mounts.  We don't have to pick
>> any of the permission names I tossed out, none of those were very
>> good, but I would like to see something that takes both NNP and
>> nosuid
>> into account, or preferably something that doesn't use either name
>> explicitly but still conveys the meaning.
>
> NNP is essentially a superset of nosuid; it applies to all execve()
> calls by the process and its descendants rather than only to execve()
> calls on specially marked filesystems.  So I viewed it as the more
> general term.

While there is clearly similar intent behind the NNP and nosuid
restrictions, they are enabled differently and typically require
differing levels of privilege.  We currently treat them similarly from
a SELinux perspective, but from a user/admin perspective they are
quite different (as Dominick points out as well).

> If that's not viable, I can't think of anything clearer or better than
> nnp_nosuid_transition.  That clearly links it to what it means (allow a
> SELinux domain transition under NNP or nosuid).  It is somewhat ugly
> and verbose but it is clear in what it means, which I think is more
> important.

Yes, it's ugly, but probably the only option we are all likely to agree upon.

> All of your suggestions IMHO were less clear since they had
> no clear linkage to either NNP or nosuid, and I couldn't tell from
> reading the permission name what it meant.

As I said, I wasn't in love with those either, I was just trying to
kickstart some brainstorming on the permission name.

> The only other alternative I see is to introduce a process2 class and
> use separate nnp_transition and nosuid_transition permissions ...

As mentioned earlier, I don't think this is worthy of the process2 overhead.

> Other approach would be to make the nosuid transition checks file-based
> instead so that it would go in the file class (while the nnp one would
> remain in the process class), but I don't think that's really what we
> want either.  Difference between "Can domain D1 transition under nosuid
>  to D2?" and "Can domain D1 transition under nosuid when executing file
> with type T1?".

Not a fan of this option either.

> On a separate note, I plan to cc luto on the next version of the patch
> as I suspect he will have concerns about relaxing this constraint on
> NNP and this likely requires updating Documentation/prctl/no_new_privs*
> and the man pages that describe NNP behavior.

That makes sense (both CC'ing Andy and his expected concerns).

> The other model would be to figure out a way to make the typebounds
> logic work cleanly in a manner that preserves the desired NNP/nosuid
> invariant _and_ doesn't require leaking unnecessary accesses into the
> ancestor domains that make them less secure, plus CIL support for
> automatically propagating permissions in the desired way.

We talked about this in the other thread, this would obviously be my
preferred solution, but it doesn't appear practical at the moment.
The one positive with the proposed solution in this patch is that it
doesn't prevent us from later resolving this with a clever bounded
type solution in the future.

-- 
paul moore
www.paul-moore.com

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Chris PeBenito]

On 07/13/2017 04:11 PM, Dominick Grift wrote:
> On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:
>> On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
>>> On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
>>>> On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
>>>>> On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
>>>>>> On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
>>>>>> wrote:
>>>>>>> On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
>>>>>>>> On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
>>>>>>>> wrote:
>>>>>>>>> On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
>>>>>>>>>> On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
>>>>>>>>>>> On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds
>>>>>>>>>>> @tycho
>>>>>>>>>>> .nsa
>>>>>>>>>>> .gov
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 07/12/2017 05:38 PM, Paul Moore wrote:
>>>>>>>>>>>>>> On Wed, Jul 12, 2017 at 9:26 AM, Stephen
>>>>>>>>>>>>>> Smalley <sds
>>>>>>>>>>>>>> @tyc
>>>>>>>>>>>>>> ho.n
>>>>>>>>>>>>>> sa
>>>>>>>>>>>>>> .gov
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On Mon, Jul 10, 2017 at 4:25 PM, Stephen
>>>>>>>>>>>>>>>> Smalley
>>>>>>>>>>>>>>>> <sds
>>>>>>>>>>>>>>>> @tyc
>>>>>>>>>>>>>>>> ho
>>>>>>>>>>>>>>>> .nsa
>>>>>>>>>>>>>>>> .gov>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> While I think splitting the NNP/nosuid
>>>>>>>>>>>>>> transition
>>>>>>>>>>>>>> restrictions
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>> be a good idea under the new policy capability,
>>>>>>>>>>>>>> I'm
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> sure
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> worth the cost of a "process2" object class.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With that in mind, let's do two things with
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> patch:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Mention the nosuid restrictions in the patch
>>>>>>>>>>>>>> description.  It
>>>>>>>>>>>>>> doesn't need much text, but something would be
>>>>>>>>>>>>>> good
>>>>>>>>>>>>>> so we
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> documentation in the git log.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Let's pick a new permission name that is not
>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> NNP
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> nosuid.  IMHO, nnpnosuid_transition is ... less
>>>>>>>>>>>>>> than
>>>>>>>>>>>>>> good.
>>>>>>>>>>>>>> Unfortunately, I'm not sure I'm much better at
>>>>>>>>>>>>>> picking
>>>>>>>>>>>>>> names;
>>>>>>>>>>>>>> how
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> "protected_transition"?  "restricted_transition
>>>>>>>>>>>>>> "?
>>>>>>>>>>>>>> "enable_transition"?  "override_transition"?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I vote for nnp_transition anyway.  "No New
>>>>>>>>>>>>> Privileges"
>>>>>>>>>>>>> encompasses
>>>>>>>>>>>>> nosuid in my mind.  If the two perms had been
>>>>>>>>>>>>> separated
>>>>>>>>>>>>> I
>>>>>>>>>>>>> would
>>>>>>>>>>>>> have
>>>>>>>>>>>>> been inclined to allow both every time one of
>>>>>>>>>>>>> them was
>>>>>>>>>>>>> needed,
>>>>>>>>>>>>> to
>>>>>>>>>>>>> make
>>>>>>>>>>>>> sure no one was surprised by the behavior
>>>>>>>>>>>>> difference.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree; I'll keep it as nnp_transition and just
>>>>>>>>>>>> document
>>>>>>>>>>>> it
>>>>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>> patch description.
>>>>>>>>>>>
>>>>>>>>>>> Sorry to be a stubborn about this, but nnp_transition
>>>>>>>>>>> makes
>>>>>>>>>>> little
>>>>>>>>>>> sense for the nosuid restriction.  Like it or not,
>>>>>>>>>>> NNP has
>>>>>>>>>>> a
>>>>>>>>>>> concrete
>>>>>>>>>>> meaning which is distinct from nosuid mounts.  We
>>>>>>>>>>> don't
>>>>>>>>>>> have to
>>>>>>>>>>> pick
>>>>>>>>>>> any of the permission names I tossed out, none of
>>>>>>>>>>> those
>>>>>>>>>>> were
>>>>>>>>>>> very
>>>>>>>>>>> good, but I would like to see something that takes
>>>>>>>>>>> both NNP
>>>>>>>>>>> and
>>>>>>>>>>> nosuid
>>>>>>>>>>> into account, or preferably something that doesn't
>>>>>>>>>>> use
>>>>>>>>>>> either
>>>>>>>>>>> name
>>>>>>>>>>> explicitly but still conveys the meaning.
>>>>>>>>>>
>>>>>>>>>> NNP is essentially a superset of nosuid; it applies to
>>>>>>>>>> all
>>>>>>>>>> execve()
>>>>>>>>>> calls by the process and its descendants rather than
>>>>>>>>>> only to
>>>>>>>>>> execve()
>>>>>>>>>> calls on specially marked filesystems.  So I viewed it
>>>>>>>>>> as the
>>>>>>>>>> more
>>>>>>>>>> general term.
>>>>>>>>>>
>>>>>>>>>> If that's not viable, I can't think of anything clearer
>>>>>>>>>> or
>>>>>>>>>> better
>>>>>>>>>> than
>>>>>>>>>> nnp_nosuid_transition.  That clearly links it to what
>>>>>>>>>> it
>>>>>>>>>> means
>>>>>>>>>> (allow
>>>>>>>>>> a
>>>>>>>>>> SELinux domain transition under NNP or nosuid).  It is
>>>>>>>>>> somewhat
>>>>>>>>>> ugly
>>>>>>>>>> and verbose but it is clear in what it means, which I
>>>>>>>>>> think
>>>>>>>>>> is
>>>>>>>>>> more
>>>>>>>>>> important. All of your suggestions IMHO were less clear
>>>>>>>>>> since
>>>>>>>>>> they
>>>>>>>>>> had
>>>>>>>>>> no clear linkage to either NNP or nosuid, and I
>>>>>>>>>> couldn't tell
>>>>>>>>>> from
>>>>>>>>>> reading the permission name what it meant.  The SELinux
>>>>>>>>>> domain
>>>>>>>>>> transition isn't protected, it isn't restricted, it
>>>>>>>>>> isn't
>>>>>>>>>> clear
>>>>>>>>>> what
>>>>>>>>>> enable_transition means versus the regular transition
>>>>>>>>>> or
>>>>>>>>>> dyntransition
>>>>>>>>>> permissions, and we aren't overriding a transition but
>>>>>>>>>> rather
>>>>>>>>>> allowing
>>>>>>>>>> one under NNP/nosuid.
>>>>>>>>>>
>>>>>>>>>> The only other alternative I see is to introduce a
>>>>>>>>>> process2
>>>>>>>>>> class
>>>>>>>>>> and
>>>>>>>>>> use separate nnp_transition and nosuid_transition
>>>>>>>>>> permissions
>>>>>>>>>> (but in
>>>>>>>>>> practice I expect them to be both allowed or denied
>>>>>>>>>> together).  Note
>>>>>>>>>> that this will require two avtab and AVC entries for
>>>>>>>>>> every
>>>>>>>>>> domain
>>>>>>>>>> pair
>>>>>>>>>> (if we allow whichever one ends up going in the
>>>>>>>>>> process2
>>>>>>>>>> class),
>>>>>>>>>> so
>>>>>>>>>> that has an impact on policy and AVC size.  Don't
>>>>>>>>>> really see
>>>>>>>>>> that
>>>>>>>>>> as
>>>>>>>>>> worthwhile.
>>>>>>>>>>
>>>>>>>>>> Other approach would be to make the nosuid transition
>>>>>>>>>> checks
>>>>>>>>>> file-
>>>>>>>>>> based
>>>>>>>>>> instead so that it would go in the file class (while
>>>>>>>>>> the nnp
>>>>>>>>>> one
>>>>>>>>>> would
>>>>>>>>>> remain in the process class), but I don't think that's
>>>>>>>>>> really
>>>>>>>>>> what we
>>>>>>>>>> want either.  Difference between "Can domain D1
>>>>>>>>>> transition
>>>>>>>>>> under
>>>>>>>>>> nosuid
>>>>>>>>>>  to D2?" and "Can domain D1 transition under nosuid
>>>>>>>>>> when
>>>>>>>>>> executing
>>>>>>>>>> file
>>>>>>>>>> with type T1?".
>>>>>>>>>
>>>>>>>>> Just to be clear, we would also be separately checking
>>>>>>>>> regular
>>>>>>>>> transition permission between the old and new contexts on
>>>>>>>>> these
>>>>>>>>> transitions, so you would need both:
>>>>>>>>> allow D1 D2:process transition;
>>>>>>>>> allow D1 T1:file nosuid_transition;
>>>>>>>>> if we took the latter approach.
>>>>>>>>>
>>>>>>>>> So we wouldn't lose entirely on a domain-to-domain check,
>>>>>>>>> but
>>>>>>>>> it
>>>>>>>>> would
>>>>>>>>> no longer be domain-to-domain for the nosuid part.
>>>>>>>>>
>>>>>>>>> Whereas with original approach, we end up requiring:
>>>>>>>>> allow D1 D2:process transition;
>>>>>>>>> allow D1 D2:process nnp_nosuid_transition; # or whatever
>>>>>>>>> permission
>>>>>>>>> name is used
>>>>>>>>
>>>>>>>> I don't know if i understand all the ins-and-outs of the
>>>>>>>> matter
>>>>>>>> but i
>>>>>>>> think i do like the idea of differentiating between
>>>>>>>> nosuid_transition
>>>>>>>> and nnp_transition
>>>>>>>> It provides more flexibility because i might not want to
>>>>>>>> allow
>>>>>>>> one or
>>>>>>>> the other automatically.
>>>>>>>>
>>>>>>>> I do not think it its a good idea to allow a process to
>>>>>>>> transiton
>>>>>>>> on
>>>>>>>> nosuid mounted filesystems just because i am forced to
>>>>>>>> allow it
>>>>>>>> nnp.
>>>>>>>
>>>>>>> Can you provide a real use case where you would need to
>>>>>>> distinguish
>>>>>>> them?
>>>>>>
>>>>>> Nope I cannot, but its easy to merge the two permissions in
>>>>>> policy,
>>>>>> and thereby preserving flexibility. It will be hard to deal
>>>>>> with a
>>>>>> case that might arise that was not foreseen if we cover both
>>>>>> scenarios with a single permission.
>>>>>>
>>>>>>>
>>>>>>> Currently we handle them the same way (i.e. we don't allow
>>>>>>> transitions
>>>>>>> unless bounded for both).  The current patch preserves that
>>>>>>> consistency, and just provides a way to allow transitions
>>>>>>> without
>>>>>>> bounds for both.  Of course, you still have to be allowed the
>>>>>>> usual
>>>>>>> permissions in order to perform the transition at all (Can
>>>>>>> the
>>>>>>> caller
>>>>>>> execute the file? Can the callee be entered (entrypoint) by
>>>>>>> the
>>>>>>> file?
>>>>>>> Can the caller transition to the callee?) in addition to the
>>>>>>> new
>>>>>>> permission check (Can the caller transition under NNP/nosuid
>>>>>>> to the
>>>>>>> callee?).
>>>>>>>
>>>>>>> We can't distinguish them on a domain-to-domain basis without
>>>>>>> introducing a new process2 class, and so far no one has been
>>>>>>> excited
>>>>>>> about that.
>>>>>>
>>>>>> Why is that? Eventually that is going to happen anyway. Besides
>>>>>> we
>>>>>> also have a capability2 and its not like that's a big deal is
>>>>>> it?
>>>>>
>>>>> Adding it is fine if we have a genuine need for it, but it
>>>>> doesn't come
>>>>> for free. It is potentially an extra avtab entry (policy rule)
>>>>> for
>>>>> every allowed domain transition in the policy.  There are far
>>>>> fewer
>>>>> capability2 rules in comparison, since those are always domain-
>>>>> self and
>>>>>  to date the need for those capabilities has also been relatively
>>>>> sparse.
>>>>
>>>> Okay i rest my case, just making sure that this is thought over
>>>> carefully
>>>
>>> Aw heck on more argument:
>>>
>>> How about adding another policycap for that?
>>
>> I doubt we want to require policy writers and analysts to have to check
>> a policy capability to determine whether nosuid transitions depend on
>> their own unique permission or the one shared with nnp transitions.
>> Complexity for no real gain.
>
> Yes well "no real gain" I think basically were just saying: nosuid doesnt apply to selinux anymore
>
> If i have an executable file type for a daemon that uses NNP and two executables one on a nosuid mounted slice and another one on a non-nosuid mounted partition, then basically from an selinux perspective the nosuid is meaningless.

I don't think that situation can be addressed with your proposed change 
because the transition checks are between the two domains, not the 
source domain and the executable.


-- 
Chris PeBenito

Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 15730 bytes --]

On Thu, Jul 13, 2017 at 07:55:14PM -0400, Chris PeBenito wrote:
> On 07/13/2017 04:11 PM, Dominick Grift wrote:
> > On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote:
> > > > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote:
> > > > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote:
> > > > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote:
> > > > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley
> > > > > > > wrote:
> > > > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote:
> > > > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley
> > > > > > > > > wrote:
> > > > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote:
> > > > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote:
> > > > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds
> > > > > > > > > > > > @tycho
> > > > > > > > > > > > .nsa
> > > > > > > > > > > > .gov
> > > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote:
> > > > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen
> > > > > > > > > > > > > > > Smalley <sds
> > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > ho.n
> > > > > > > > > > > > > > > sa
> > > > > > > > > > > > > > > .gov
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen
> > > > > > > > > > > > > > > > > Smalley
> > > > > > > > > > > > > > > > > <sds
> > > > > > > > > > > > > > > > > @tyc
> > > > > > > > > > > > > > > > > ho
> > > > > > > > > > > > > > > > > .nsa
> > > > > > > > > > > > > > > > > .gov>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > While I think splitting the NNP/nosuid
> > > > > > > > > > > > > > > transition
> > > > > > > > > > > > > > > restrictions
> > > > > > > > > > > > > > > might
> > > > > > > > > > > > > > > be a good idea under the new policy capability,
> > > > > > > > > > > > > > > I'm
> > > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > sure
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > worth the cost of a "process2" object class.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > With that in mind, let's do two things with
> > > > > > > > > > > > > > > this
> > > > > > > > > > > > > > > patch:
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch
> > > > > > > > > > > > > > > description.  It
> > > > > > > > > > > > > > > doesn't need much text, but something would be
> > > > > > > > > > > > > > > good
> > > > > > > > > > > > > > > so we
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > documentation in the git log.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > * Let's pick a new permission name that is not
> > > > > > > > > > > > > > > specific
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > NNP
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > nosuid.  IMHO, nnpnosuid_transition is ... less
> > > > > > > > > > > > > > > than
> > > > > > > > > > > > > > > good.
> > > > > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at
> > > > > > > > > > > > > > > picking
> > > > > > > > > > > > > > > names;
> > > > > > > > > > > > > > > how
> > > > > > > > > > > > > > > about
> > > > > > > > > > > > > > > "protected_transition"?  "restricted_transition
> > > > > > > > > > > > > > > "?
> > > > > > > > > > > > > > > "enable_transition"?  "override_transition"?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I vote for nnp_transition anyway.  "No New
> > > > > > > > > > > > > > Privileges"
> > > > > > > > > > > > > > encompasses
> > > > > > > > > > > > > > nosuid in my mind.  If the two perms had been
> > > > > > > > > > > > > > separated
> > > > > > > > > > > > > > I
> > > > > > > > > > > > > > would
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > been inclined to allow both every time one of
> > > > > > > > > > > > > > them was
> > > > > > > > > > > > > > needed,
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > make
> > > > > > > > > > > > > > sure no one was surprised by the behavior
> > > > > > > > > > > > > > difference.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I agree; I'll keep it as nnp_transition and just
> > > > > > > > > > > > > document
> > > > > > > > > > > > > it
> > > > > > > > > > > > > in
> > > > > > > > > > > > > the
> > > > > > > > > > > > > patch description.
> > > > > > > > > > > > 
> > > > > > > > > > > > Sorry to be a stubborn about this, but nnp_transition
> > > > > > > > > > > > makes
> > > > > > > > > > > > little
> > > > > > > > > > > > sense for the nosuid restriction.  Like it or not,
> > > > > > > > > > > > NNP has
> > > > > > > > > > > > a
> > > > > > > > > > > > concrete
> > > > > > > > > > > > meaning which is distinct from nosuid mounts.  We
> > > > > > > > > > > > don't
> > > > > > > > > > > > have to
> > > > > > > > > > > > pick
> > > > > > > > > > > > any of the permission names I tossed out, none of
> > > > > > > > > > > > those
> > > > > > > > > > > > were
> > > > > > > > > > > > very
> > > > > > > > > > > > good, but I would like to see something that takes
> > > > > > > > > > > > both NNP
> > > > > > > > > > > > and
> > > > > > > > > > > > nosuid
> > > > > > > > > > > > into account, or preferably something that doesn't
> > > > > > > > > > > > use
> > > > > > > > > > > > either
> > > > > > > > > > > > name
> > > > > > > > > > > > explicitly but still conveys the meaning.
> > > > > > > > > > > 
> > > > > > > > > > > NNP is essentially a superset of nosuid; it applies to
> > > > > > > > > > > all
> > > > > > > > > > > execve()
> > > > > > > > > > > calls by the process and its descendants rather than
> > > > > > > > > > > only to
> > > > > > > > > > > execve()
> > > > > > > > > > > calls on specially marked filesystems.  So I viewed it
> > > > > > > > > > > as the
> > > > > > > > > > > more
> > > > > > > > > > > general term.
> > > > > > > > > > > 
> > > > > > > > > > > If that's not viable, I can't think of anything clearer
> > > > > > > > > > > or
> > > > > > > > > > > better
> > > > > > > > > > > than
> > > > > > > > > > > nnp_nosuid_transition.  That clearly links it to what
> > > > > > > > > > > it
> > > > > > > > > > > means
> > > > > > > > > > > (allow
> > > > > > > > > > > a
> > > > > > > > > > > SELinux domain transition under NNP or nosuid).  It is
> > > > > > > > > > > somewhat
> > > > > > > > > > > ugly
> > > > > > > > > > > and verbose but it is clear in what it means, which I
> > > > > > > > > > > think
> > > > > > > > > > > is
> > > > > > > > > > > more
> > > > > > > > > > > important. All of your suggestions IMHO were less clear
> > > > > > > > > > > since
> > > > > > > > > > > they
> > > > > > > > > > > had
> > > > > > > > > > > no clear linkage to either NNP or nosuid, and I
> > > > > > > > > > > couldn't tell
> > > > > > > > > > > from
> > > > > > > > > > > reading the permission name what it meant.  The SELinux
> > > > > > > > > > > domain
> > > > > > > > > > > transition isn't protected, it isn't restricted, it
> > > > > > > > > > > isn't
> > > > > > > > > > > clear
> > > > > > > > > > > what
> > > > > > > > > > > enable_transition means versus the regular transition
> > > > > > > > > > > or
> > > > > > > > > > > dyntransition
> > > > > > > > > > > permissions, and we aren't overriding a transition but
> > > > > > > > > > > rather
> > > > > > > > > > > allowing
> > > > > > > > > > > one under NNP/nosuid.
> > > > > > > > > > > 
> > > > > > > > > > > The only other alternative I see is to introduce a
> > > > > > > > > > > process2
> > > > > > > > > > > class
> > > > > > > > > > > and
> > > > > > > > > > > use separate nnp_transition and nosuid_transition
> > > > > > > > > > > permissions
> > > > > > > > > > > (but in
> > > > > > > > > > > practice I expect them to be both allowed or denied
> > > > > > > > > > > together).  Note
> > > > > > > > > > > that this will require two avtab and AVC entries for
> > > > > > > > > > > every
> > > > > > > > > > > domain
> > > > > > > > > > > pair
> > > > > > > > > > > (if we allow whichever one ends up going in the
> > > > > > > > > > > process2
> > > > > > > > > > > class),
> > > > > > > > > > > so
> > > > > > > > > > > that has an impact on policy and AVC size.  Don't
> > > > > > > > > > > really see
> > > > > > > > > > > that
> > > > > > > > > > > as
> > > > > > > > > > > worthwhile.
> > > > > > > > > > > 
> > > > > > > > > > > Other approach would be to make the nosuid transition
> > > > > > > > > > > checks
> > > > > > > > > > > file-
> > > > > > > > > > > based
> > > > > > > > > > > instead so that it would go in the file class (while
> > > > > > > > > > > the nnp
> > > > > > > > > > > one
> > > > > > > > > > > would
> > > > > > > > > > > remain in the process class), but I don't think that's
> > > > > > > > > > > really
> > > > > > > > > > > what we
> > > > > > > > > > > want either.  Difference between "Can domain D1
> > > > > > > > > > > transition
> > > > > > > > > > > under
> > > > > > > > > > > nosuid
> > > > > > > > > > >  to D2?" and "Can domain D1 transition under nosuid
> > > > > > > > > > > when
> > > > > > > > > > > executing
> > > > > > > > > > > file
> > > > > > > > > > > with type T1?".
> > > > > > > > > > 
> > > > > > > > > > Just to be clear, we would also be separately checking
> > > > > > > > > > regular
> > > > > > > > > > transition permission between the old and new contexts on
> > > > > > > > > > these
> > > > > > > > > > transitions, so you would need both:
> > > > > > > > > > allow D1 D2:process transition;
> > > > > > > > > > allow D1 T1:file nosuid_transition;
> > > > > > > > > > if we took the latter approach.
> > > > > > > > > > 
> > > > > > > > > > So we wouldn't lose entirely on a domain-to-domain check,
> > > > > > > > > > but
> > > > > > > > > > it
> > > > > > > > > > would
> > > > > > > > > > no longer be domain-to-domain for the nosuid part.
> > > > > > > > > > 
> > > > > > > > > > Whereas with original approach, we end up requiring:
> > > > > > > > > > allow D1 D2:process transition;
> > > > > > > > > > allow D1 D2:process nnp_nosuid_transition; # or whatever
> > > > > > > > > > permission
> > > > > > > > > > name is used
> > > > > > > > > 
> > > > > > > > > I don't know if i understand all the ins-and-outs of the
> > > > > > > > > matter
> > > > > > > > > but i
> > > > > > > > > think i do like the idea of differentiating between
> > > > > > > > > nosuid_transition
> > > > > > > > > and nnp_transition
> > > > > > > > > It provides more flexibility because i might not want to
> > > > > > > > > allow
> > > > > > > > > one or
> > > > > > > > > the other automatically.
> > > > > > > > > 
> > > > > > > > > I do not think it its a good idea to allow a process to
> > > > > > > > > transiton
> > > > > > > > > on
> > > > > > > > > nosuid mounted filesystems just because i am forced to
> > > > > > > > > allow it
> > > > > > > > > nnp.
> > > > > > > > 
> > > > > > > > Can you provide a real use case where you would need to
> > > > > > > > distinguish
> > > > > > > > them?
> > > > > > > 
> > > > > > > Nope I cannot, but its easy to merge the two permissions in
> > > > > > > policy,
> > > > > > > and thereby preserving flexibility. It will be hard to deal
> > > > > > > with a
> > > > > > > case that might arise that was not foreseen if we cover both
> > > > > > > scenarios with a single permission.
> > > > > > > 
> > > > > > > > 
> > > > > > > > Currently we handle them the same way (i.e. we don't allow
> > > > > > > > transitions
> > > > > > > > unless bounded for both).  The current patch preserves that
> > > > > > > > consistency, and just provides a way to allow transitions
> > > > > > > > without
> > > > > > > > bounds for both.  Of course, you still have to be allowed the
> > > > > > > > usual
> > > > > > > > permissions in order to perform the transition at all (Can
> > > > > > > > the
> > > > > > > > caller
> > > > > > > > execute the file? Can the callee be entered (entrypoint) by
> > > > > > > > the
> > > > > > > > file?
> > > > > > > > Can the caller transition to the callee?) in addition to the
> > > > > > > > new
> > > > > > > > permission check (Can the caller transition under NNP/nosuid
> > > > > > > > to the
> > > > > > > > callee?).
> > > > > > > > 
> > > > > > > > We can't distinguish them on a domain-to-domain basis without
> > > > > > > > introducing a new process2 class, and so far no one has been
> > > > > > > > excited
> > > > > > > > about that.
> > > > > > > 
> > > > > > > Why is that? Eventually that is going to happen anyway. Besides
> > > > > > > we
> > > > > > > also have a capability2 and its not like that's a big deal is
> > > > > > > it?
> > > > > > 
> > > > > > Adding it is fine if we have a genuine need for it, but it
> > > > > > doesn't come
> > > > > > for free. It is potentially an extra avtab entry (policy rule)
> > > > > > for
> > > > > > every allowed domain transition in the policy.  There are far
> > > > > > fewer
> > > > > > capability2 rules in comparison, since those are always domain-
> > > > > > self and
> > > > > >  to date the need for those capabilities has also been relatively
> > > > > > sparse.
> > > > > 
> > > > > Okay i rest my case, just making sure that this is thought over
> > > > > carefully
> > > > 
> > > > Aw heck on more argument:
> > > > 
> > > > How about adding another policycap for that?
> > > 
> > > I doubt we want to require policy writers and analysts to have to check
> > > a policy capability to determine whether nosuid transitions depend on
> > > their own unique permission or the one shared with nnp transitions.
> > > Complexity for no real gain.
> > 
> > Yes well "no real gain" I think basically were just saying: nosuid doesnt apply to selinux anymore
> > 
> > If i have an executable file type for a daemon that uses NNP and two executables one on a nosuid mounted slice and another one on a non-nosuid mounted partition, then basically from an selinux perspective the nosuid is meaningless.
> 
> I don't think that situation can be addressed with your proposed change
> because the transition checks are between the two domains, not the source
> domain and the executable.

Consider:

1. NNP flags are inherited (this is something I think we really need to take into account)
2. Take for example "fsutils_t" There are many executable files associated with the "fsutils_exec_t" domain entry file type. What if some of those are located on nosuid mounted filesystems and some are not?
3. What if any of the domains that needs to be able to run "fsutils" with a domain transition to "fsutils_t" inherited the NNP flag?

> 
> 
> -- 
> Chris PeBenito
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]