All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC][PATCH] selinux: support distinctions among all network address families
@ 2016-12-01 15:07 Stephen Smalley
  2016-12-01 15:57 ` Stephen Smalley
  2016-12-01 17:04 ` Guido Trentalancia
  0 siblings, 2 replies; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 15:07 UTC (permalink / raw)
  To: selinux; +Cc: paul, guido, Stephen Smalley

Extend SELinux to support distinctions among all network address families
implemented by the kernel by defining new socket security classes
and mapping to them. Otherwise, many sockets are mapped to the generic
socket class and are indistinguishable in policy.  This has come up
previously with regard to selectively allowing access to bluetooth sockets,
and more recently with regard to selectively allowing access to AF_ALG
sockets.  Guido Trentalancia submitted a patch that took a similar approach
to add only support for distinguishing AF_ALG sockets, but this generalizes
his approach to handle all address families implemented by the kernel.
Socket security classes were not defined for AF_* values that are reserved
but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ECONET,
AF_SNA, AF_WANPIPE.

Backward compatibility is provided by only enabling the finer-grained
socket classes if a new policy capability is set in the policy; older
policies will behave as before.  The legacy redhat1 policy capability
that was only ever used in testing within Fedora for ptrace_child
is reclaimed for this purpose; as far as I can tell, this policy
capability is not enabled in any supported distro policy.

Add a pair of conditional compilation guards to detect when new AF_* values
are added so that we can update SELinux accordingly rather than having to
belatedly update it long after new address families are introduced.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
---
 security/selinux/hooks.c            | 67 +++++++++++++++++++++++++++++++++++++
 security/selinux/include/classmap.h | 62 ++++++++++++++++++++++++++++++++++
 security/selinux/include/security.h |  3 +-
 security/selinux/selinuxfs.c        |  2 +-
 security/selinux/ss/services.c      |  3 ++
 5 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 98a2e92..1ee2172 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -1342,6 +1342,73 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
 		return SECCLASS_APPLETALK_SOCKET;
 	}
 
+	if (!selinux_policycap_extsockclass)
+		return SECCLASS_SOCKET;
+
+	switch (family) {
+	case PF_AX25:
+		return SECCLASS_AX25_SOCKET;
+	case PF_IPX:
+		return SECCLASS_IPX_SOCKET;
+	case PF_NETROM:
+		return SECCLASS_NETROM_SOCKET;
+	case PF_BRIDGE:
+		return SECCLASS_BRIDGE_SOCKET;
+	case PF_ATMPVC:
+		return SECCLASS_ATMPVC_SOCKET;
+	case PF_X25:
+		return SECCLASS_X25_SOCKET;
+	case PF_ROSE:
+		return SECCLASS_ROSE_SOCKET;
+	case PF_DECnet:
+		return SECCLASS_DECNET_SOCKET;
+	case PF_ATMSVC:
+		return SECCLASS_ATMSVC_SOCKET;
+	case PF_RDS:
+		return SECCLASS_RDS_SOCKET;
+	case PF_IRDA:
+		return SECCLASS_IRDA_SOCKET;
+	case PF_PPPOX:
+		return SECCLASS_PPPOX_SOCKET;
+	case PF_LLC:
+		return SECCLASS_LLC_SOCKET;
+	case PF_IB:
+		return SECCLASS_IB_SOCKET;
+	case PF_MPLS:
+		return SECCLASS_MPLS_SOCKET;
+	case PF_CAN:
+		return SECCLASS_CAN_SOCKET;
+	case PF_TIPC:
+		return SECCLASS_TIPC_SOCKET;
+	case PF_BLUETOOTH:
+		return SECCLASS_BLUETOOTH_SOCKET;
+	case PF_IUCV:
+		return SECCLASS_IUCV_SOCKET;
+	case PF_RXRPC:
+		return SECCLASS_RXRPC_SOCKET;
+	case PF_ISDN:
+		return SECCLASS_ISDN_SOCKET;
+	case PF_PHONET:
+		return SECCLASS_PHONET_SOCKET;
+	case PF_IEEE802154:
+		return SECCLASS_IEEE802154_SOCKET;
+	case PF_CAIF:
+		return SECCLASS_CAIF_SOCKET;
+	case PF_ALG:
+		return SECCLASS_ALG_SOCKET;
+	case PF_NFC:
+		return SECCLASS_NFC_SOCKET;
+	case PF_VSOCK:
+		return SECCLASS_VSOCK_SOCKET;
+	case PF_KCM:
+		return SECCLASS_KCM_SOCKET;
+	case PF_QIPCRTR:
+		return SECCLASS_QIPCRTR_SOCKET;
+#if PF_MAX > 43
+#error New address family defined, please update this function.
+#endif
+	}
+
 	return SECCLASS_SOCKET;
 }
 
diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
index e2d4ad3a..a11be76 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -169,5 +169,67 @@ struct security_class_mapping secclass_map[] = {
 	  { COMMON_CAP_PERMS, NULL } },
 	{ "cap2_userns",
 	  { COMMON_CAP2_PERMS, NULL } },
+	{ "ax25_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "ipx_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "netrom_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "bridge_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "atmpvc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "x25_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "rose_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "decnet_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "atmsvc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "rds_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "irda_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "pppox_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "llc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "ib_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "mpls_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "can_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "tipc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "bluetooth_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "iucv_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "rxrpc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "isdn_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "phonet_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "ieee802154_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "caif_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "alg_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "nfc_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "vsock_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "kcm_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
+	{ "qipcrtr_socket",
+	  { COMMON_SOCK_PERMS, NULL } },
 	{ NULL }
   };
+
+#if PF_MAX > 43
+#error New address family defined, please update secclass_map.
+#endif
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 308a286..beaa14b 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -69,7 +69,7 @@ extern int selinux_enabled;
 enum {
 	POLICYDB_CAPABILITY_NETPEER,
 	POLICYDB_CAPABILITY_OPENPERM,
-	POLICYDB_CAPABILITY_REDHAT1,
+	POLICYDB_CAPABILITY_EXTSOCKCLASS,
 	POLICYDB_CAPABILITY_ALWAYSNETWORK,
 	__POLICYDB_CAPABILITY_MAX
 };
@@ -77,6 +77,7 @@ enum {
 
 extern int selinux_policycap_netpeer;
 extern int selinux_policycap_openperm;
+extern int selinux_policycap_extsockclass;
 extern int selinux_policycap_alwaysnetwork;
 
 /*
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index cf9293e..0aac402 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -45,7 +45,7 @@
 static char *policycap_names[] = {
 	"network_peer_controls",
 	"open_perms",
-	"redhat1",
+	"extended_socket_class",
 	"always_check_network"
 };
 
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 082b20c..a70fcee 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -72,6 +72,7 @@
 
 int selinux_policycap_netpeer;
 int selinux_policycap_openperm;
+int selinux_policycap_extsockclass;
 int selinux_policycap_alwaysnetwork;
 
 static DEFINE_RWLOCK(policy_rwlock);
@@ -1988,6 +1989,8 @@ static void security_load_policycaps(void)
 						  POLICYDB_CAPABILITY_NETPEER);
 	selinux_policycap_openperm = ebitmap_get_bit(&policydb.policycaps,
 						  POLICYDB_CAPABILITY_OPENPERM);
+	selinux_policycap_extsockclass = ebitmap_get_bit(&policydb.policycaps,
+					  POLICYDB_CAPABILITY_EXTSOCKCLASS);
 	selinux_policycap_alwaysnetwork = ebitmap_get_bit(&policydb.policycaps,
 						  POLICYDB_CAPABILITY_ALWAYSNETWORK);
 }
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 15:07 [RFC][PATCH] selinux: support distinctions among all network address families Stephen Smalley
@ 2016-12-01 15:57 ` Stephen Smalley
  2016-12-01 16:26   ` Stephen Smalley
                     ` (2 more replies)
  2016-12-01 17:04 ` Guido Trentalancia
  1 sibling, 3 replies; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 15:57 UTC (permalink / raw)
  To: selinux; +Cc: paul, guido

On 12/01/2016 10:07 AM, Stephen Smalley wrote:
> Extend SELinux to support distinctions among all network address families
> implemented by the kernel by defining new socket security classes
> and mapping to them. Otherwise, many sockets are mapped to the generic
> socket class and are indistinguishable in policy.  This has come up
> previously with regard to selectively allowing access to bluetooth sockets,
> and more recently with regard to selectively allowing access to AF_ALG
> sockets.  Guido Trentalancia submitted a patch that took a similar approach
> to add only support for distinguishing AF_ALG sockets, but this generalizes
> his approach to handle all address families implemented by the kernel.
> Socket security classes were not defined for AF_* values that are reserved
> but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ECONET,
> AF_SNA, AF_WANPIPE.
> 
> Backward compatibility is provided by only enabling the finer-grained
> socket classes if a new policy capability is set in the policy; older
> policies will behave as before.  The legacy redhat1 policy capability
> that was only ever used in testing within Fedora for ptrace_child
> is reclaimed for this purpose; as far as I can tell, this policy
> capability is not enabled in any supported distro policy.
> 
> Add a pair of conditional compilation guards to detect when new AF_* values
> are added so that we can update SELinux accordingly rather than having to
> belatedly update it long after new address families are introduced.

A couple of notes on this change:

- To fully test (beyond just confirming that it doesn't break anything
when the policy capability is not defined), we'll need a patched
libsepol and policy (and unfortunately it requires patching the base
policy; can't be done via a policy module).  Can certainly provide those
too but figured I'd wait to see the response to the kernel patch first.

- There is a potential cost to this change when/if it is enabled in
policy, i.e. if we blindly allowing all of these new classes where we
previously allowed the generic socket class, we'll end up with
significant growth in policy avtab entries and in AVC entries (although
only if they are in fact used), since those are per-class.  However, I
wouldn't expect to do that except possibly for the unconfined domain;
many of these classes won't need to be allowed at all for most domains.

- There is a slight compatibility issue.  While the policy capability
ensures that we will not use the new socket classes with old policies,
we don't presently support a way to refresh socket security classes upon
a policy reload.  Hence, if you boot a kernel with a policy that has the
capability disabled, and then later load a policy that has the
capability enabled, any existing sockets won't be automatically moved
into the new security classes; they will continue to be treated as
having the generic socket security class.  I view this as a minor issue
and unlikely to cause any breakage, because refpolicy is likely to
merely add new rules for the new socket classes without removing the old
rules on the generic socket security class to provide backward
compatibility with kernels that predate this change.  Eventually we may
be able to drop those rules, but not for quite some time.  In any event,
be aware that taking full advantage of these new classes does require a
reboot.

> 
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
>  security/selinux/hooks.c            | 67 +++++++++++++++++++++++++++++++++++++
>  security/selinux/include/classmap.h | 62 ++++++++++++++++++++++++++++++++++
>  security/selinux/include/security.h |  3 +-
>  security/selinux/selinuxfs.c        |  2 +-
>  security/selinux/ss/services.c      |  3 ++
>  5 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 98a2e92..1ee2172 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1342,6 +1342,73 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
>  		return SECCLASS_APPLETALK_SOCKET;
>  	}
>  
> +	if (!selinux_policycap_extsockclass)
> +		return SECCLASS_SOCKET;
> +
> +	switch (family) {
> +	case PF_AX25:
> +		return SECCLASS_AX25_SOCKET;
> +	case PF_IPX:
> +		return SECCLASS_IPX_SOCKET;
> +	case PF_NETROM:
> +		return SECCLASS_NETROM_SOCKET;
> +	case PF_BRIDGE:
> +		return SECCLASS_BRIDGE_SOCKET;
> +	case PF_ATMPVC:
> +		return SECCLASS_ATMPVC_SOCKET;
> +	case PF_X25:
> +		return SECCLASS_X25_SOCKET;
> +	case PF_ROSE:
> +		return SECCLASS_ROSE_SOCKET;
> +	case PF_DECnet:
> +		return SECCLASS_DECNET_SOCKET;
> +	case PF_ATMSVC:
> +		return SECCLASS_ATMSVC_SOCKET;
> +	case PF_RDS:
> +		return SECCLASS_RDS_SOCKET;
> +	case PF_IRDA:
> +		return SECCLASS_IRDA_SOCKET;
> +	case PF_PPPOX:
> +		return SECCLASS_PPPOX_SOCKET;
> +	case PF_LLC:
> +		return SECCLASS_LLC_SOCKET;
> +	case PF_IB:
> +		return SECCLASS_IB_SOCKET;
> +	case PF_MPLS:
> +		return SECCLASS_MPLS_SOCKET;
> +	case PF_CAN:
> +		return SECCLASS_CAN_SOCKET;
> +	case PF_TIPC:
> +		return SECCLASS_TIPC_SOCKET;
> +	case PF_BLUETOOTH:
> +		return SECCLASS_BLUETOOTH_SOCKET;
> +	case PF_IUCV:
> +		return SECCLASS_IUCV_SOCKET;
> +	case PF_RXRPC:
> +		return SECCLASS_RXRPC_SOCKET;
> +	case PF_ISDN:
> +		return SECCLASS_ISDN_SOCKET;
> +	case PF_PHONET:
> +		return SECCLASS_PHONET_SOCKET;
> +	case PF_IEEE802154:
> +		return SECCLASS_IEEE802154_SOCKET;
> +	case PF_CAIF:
> +		return SECCLASS_CAIF_SOCKET;
> +	case PF_ALG:
> +		return SECCLASS_ALG_SOCKET;
> +	case PF_NFC:
> +		return SECCLASS_NFC_SOCKET;
> +	case PF_VSOCK:
> +		return SECCLASS_VSOCK_SOCKET;
> +	case PF_KCM:
> +		return SECCLASS_KCM_SOCKET;
> +	case PF_QIPCRTR:
> +		return SECCLASS_QIPCRTR_SOCKET;
> +#if PF_MAX > 43
> +#error New address family defined, please update this function.
> +#endif
> +	}
> +
>  	return SECCLASS_SOCKET;
>  }
>  
> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index e2d4ad3a..a11be76 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -169,5 +169,67 @@ struct security_class_mapping secclass_map[] = {
>  	  { COMMON_CAP_PERMS, NULL } },
>  	{ "cap2_userns",
>  	  { COMMON_CAP2_PERMS, NULL } },
> +	{ "ax25_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ipx_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "netrom_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "bridge_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "atmpvc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "x25_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rose_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "decnet_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "atmsvc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rds_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "irda_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "pppox_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "llc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ib_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "mpls_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "can_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "tipc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "bluetooth_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "iucv_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rxrpc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "isdn_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "phonet_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ieee802154_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "caif_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "alg_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "nfc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "vsock_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "kcm_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "qipcrtr_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
>  	{ NULL }
>    };
> +
> +#if PF_MAX > 43
> +#error New address family defined, please update secclass_map.
> +#endif
> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> index 308a286..beaa14b 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -69,7 +69,7 @@ extern int selinux_enabled;
>  enum {
>  	POLICYDB_CAPABILITY_NETPEER,
>  	POLICYDB_CAPABILITY_OPENPERM,
> -	POLICYDB_CAPABILITY_REDHAT1,
> +	POLICYDB_CAPABILITY_EXTSOCKCLASS,
>  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>  	__POLICYDB_CAPABILITY_MAX
>  };
> @@ -77,6 +77,7 @@ enum {
>  
>  extern int selinux_policycap_netpeer;
>  extern int selinux_policycap_openperm;
> +extern int selinux_policycap_extsockclass;
>  extern int selinux_policycap_alwaysnetwork;
>  
>  /*
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index cf9293e..0aac402 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -45,7 +45,7 @@
>  static char *policycap_names[] = {
>  	"network_peer_controls",
>  	"open_perms",
> -	"redhat1",
> +	"extended_socket_class",
>  	"always_check_network"
>  };
>  
> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> index 082b20c..a70fcee 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -72,6 +72,7 @@
>  
>  int selinux_policycap_netpeer;
>  int selinux_policycap_openperm;
> +int selinux_policycap_extsockclass;
>  int selinux_policycap_alwaysnetwork;
>  
>  static DEFINE_RWLOCK(policy_rwlock);
> @@ -1988,6 +1989,8 @@ static void security_load_policycaps(void)
>  						  POLICYDB_CAPABILITY_NETPEER);
>  	selinux_policycap_openperm = ebitmap_get_bit(&policydb.policycaps,
>  						  POLICYDB_CAPABILITY_OPENPERM);
> +	selinux_policycap_extsockclass = ebitmap_get_bit(&policydb.policycaps,
> +					  POLICYDB_CAPABILITY_EXTSOCKCLASS);
>  	selinux_policycap_alwaysnetwork = ebitmap_get_bit(&policydb.policycaps,
>  						  POLICYDB_CAPABILITY_ALWAYSNETWORK);
>  }
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 15:57 ` Stephen Smalley
@ 2016-12-01 16:26   ` Stephen Smalley
  2016-12-01 17:28   ` Guido Trentalancia
  2016-12-02 17:40   ` Stephen Smalley
  2 siblings, 0 replies; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 16:26 UTC (permalink / raw)
  To: selinux; +Cc: paul, guido

On 12/01/2016 10:57 AM, Stephen Smalley wrote:
> On 12/01/2016 10:07 AM, Stephen Smalley wrote:
>> Extend SELinux to support distinctions among all network address families
>> implemented by the kernel by defining new socket security classes
>> and mapping to them. Otherwise, many sockets are mapped to the generic
>> socket class and are indistinguishable in policy.  This has come up
>> previously with regard to selectively allowing access to bluetooth sockets,
>> and more recently with regard to selectively allowing access to AF_ALG
>> sockets.  Guido Trentalancia submitted a patch that took a similar approach
>> to add only support for distinguishing AF_ALG sockets, but this generalizes
>> his approach to handle all address families implemented by the kernel.
>> Socket security classes were not defined for AF_* values that are reserved
>> but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ECONET,
>> AF_SNA, AF_WANPIPE.
>>
>> Backward compatibility is provided by only enabling the finer-grained
>> socket classes if a new policy capability is set in the policy; older
>> policies will behave as before.  The legacy redhat1 policy capability
>> that was only ever used in testing within Fedora for ptrace_child
>> is reclaimed for this purpose; as far as I can tell, this policy
>> capability is not enabled in any supported distro policy.
>>
>> Add a pair of conditional compilation guards to detect when new AF_* values
>> are added so that we can update SELinux accordingly rather than having to
>> belatedly update it long after new address families are introduced.
> 
> A couple of notes on this change:
> 
> - To fully test (beyond just confirming that it doesn't break anything
> when the policy capability is not defined), we'll need a patched
> libsepol and policy (and unfortunately it requires patching the base
> policy; can't be done via a policy module).  Can certainly provide those
> too but figured I'd wait to see the response to the kernel patch first.
> 
> - There is a potential cost to this change when/if it is enabled in
> policy, i.e. if we blindly allowing all of these new classes where we
> previously allowed the generic socket class, we'll end up with
> significant growth in policy avtab entries and in AVC entries (although
> only if they are in fact used), since those are per-class.  However, I
> wouldn't expect to do that except possibly for the unconfined domain;
> many of these classes won't need to be allowed at all for most domains.
> 
> - There is a slight compatibility issue.  While the policy capability
> ensures that we will not use the new socket classes with old policies,
> we don't presently support a way to refresh socket security classes upon
> a policy reload.  Hence, if you boot a kernel with a policy that has the
> capability disabled, and then later load a policy that has the
> capability enabled, any existing sockets won't be automatically moved
> into the new security classes; they will continue to be treated as
> having the generic socket security class.  I view this as a minor issue
> and unlikely to cause any breakage, because refpolicy is likely to
> merely add new rules for the new socket classes without removing the old
> rules on the generic socket security class to provide backward
> compatibility with kernels that predate this change.  Eventually we may
> be able to drop those rules, but not for quite some time.  In any event,
> be aware that taking full advantage of these new classes does require a
> reboot.

Note btw that this slight compatibility issue was also true of commit
6c6d2e9bde1c1c87a7ead806f8f5e2181d41a652 ("selinux: update netlink
socket classes"), which doesn't appear to have caused any problems in
practice.

> 
>>
>> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
>> ---
>>  security/selinux/hooks.c            | 67 +++++++++++++++++++++++++++++++++++++
>>  security/selinux/include/classmap.h | 62 ++++++++++++++++++++++++++++++++++
>>  security/selinux/include/security.h |  3 +-
>>  security/selinux/selinuxfs.c        |  2 +-
>>  security/selinux/ss/services.c      |  3 ++
>>  5 files changed, 135 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 98a2e92..1ee2172 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -1342,6 +1342,73 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
>>  		return SECCLASS_APPLETALK_SOCKET;
>>  	}
>>  
>> +	if (!selinux_policycap_extsockclass)
>> +		return SECCLASS_SOCKET;
>> +
>> +	switch (family) {
>> +	case PF_AX25:
>> +		return SECCLASS_AX25_SOCKET;
>> +	case PF_IPX:
>> +		return SECCLASS_IPX_SOCKET;
>> +	case PF_NETROM:
>> +		return SECCLASS_NETROM_SOCKET;
>> +	case PF_BRIDGE:
>> +		return SECCLASS_BRIDGE_SOCKET;
>> +	case PF_ATMPVC:
>> +		return SECCLASS_ATMPVC_SOCKET;
>> +	case PF_X25:
>> +		return SECCLASS_X25_SOCKET;
>> +	case PF_ROSE:
>> +		return SECCLASS_ROSE_SOCKET;
>> +	case PF_DECnet:
>> +		return SECCLASS_DECNET_SOCKET;
>> +	case PF_ATMSVC:
>> +		return SECCLASS_ATMSVC_SOCKET;
>> +	case PF_RDS:
>> +		return SECCLASS_RDS_SOCKET;
>> +	case PF_IRDA:
>> +		return SECCLASS_IRDA_SOCKET;
>> +	case PF_PPPOX:
>> +		return SECCLASS_PPPOX_SOCKET;
>> +	case PF_LLC:
>> +		return SECCLASS_LLC_SOCKET;
>> +	case PF_IB:
>> +		return SECCLASS_IB_SOCKET;
>> +	case PF_MPLS:
>> +		return SECCLASS_MPLS_SOCKET;
>> +	case PF_CAN:
>> +		return SECCLASS_CAN_SOCKET;
>> +	case PF_TIPC:
>> +		return SECCLASS_TIPC_SOCKET;
>> +	case PF_BLUETOOTH:
>> +		return SECCLASS_BLUETOOTH_SOCKET;
>> +	case PF_IUCV:
>> +		return SECCLASS_IUCV_SOCKET;
>> +	case PF_RXRPC:
>> +		return SECCLASS_RXRPC_SOCKET;
>> +	case PF_ISDN:
>> +		return SECCLASS_ISDN_SOCKET;
>> +	case PF_PHONET:
>> +		return SECCLASS_PHONET_SOCKET;
>> +	case PF_IEEE802154:
>> +		return SECCLASS_IEEE802154_SOCKET;
>> +	case PF_CAIF:
>> +		return SECCLASS_CAIF_SOCKET;
>> +	case PF_ALG:
>> +		return SECCLASS_ALG_SOCKET;
>> +	case PF_NFC:
>> +		return SECCLASS_NFC_SOCKET;
>> +	case PF_VSOCK:
>> +		return SECCLASS_VSOCK_SOCKET;
>> +	case PF_KCM:
>> +		return SECCLASS_KCM_SOCKET;
>> +	case PF_QIPCRTR:
>> +		return SECCLASS_QIPCRTR_SOCKET;
>> +#if PF_MAX > 43
>> +#error New address family defined, please update this function.
>> +#endif
>> +	}
>> +
>>  	return SECCLASS_SOCKET;
>>  }
>>  
>> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
>> index e2d4ad3a..a11be76 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -169,5 +169,67 @@ struct security_class_mapping secclass_map[] = {
>>  	  { COMMON_CAP_PERMS, NULL } },
>>  	{ "cap2_userns",
>>  	  { COMMON_CAP2_PERMS, NULL } },
>> +	{ "ax25_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ipx_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "netrom_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "bridge_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "atmpvc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "x25_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rose_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "decnet_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "atmsvc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rds_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "irda_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "pppox_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "llc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ib_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "mpls_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "can_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "tipc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "bluetooth_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "iucv_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rxrpc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "isdn_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "phonet_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ieee802154_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "caif_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "alg_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "nfc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "vsock_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "kcm_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "qipcrtr_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>>  	{ NULL }
>>    };
>> +
>> +#if PF_MAX > 43
>> +#error New address family defined, please update secclass_map.
>> +#endif
>> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
>> index 308a286..beaa14b 100644
>> --- a/security/selinux/include/security.h
>> +++ b/security/selinux/include/security.h
>> @@ -69,7 +69,7 @@ extern int selinux_enabled;
>>  enum {
>>  	POLICYDB_CAPABILITY_NETPEER,
>>  	POLICYDB_CAPABILITY_OPENPERM,
>> -	POLICYDB_CAPABILITY_REDHAT1,
>> +	POLICYDB_CAPABILITY_EXTSOCKCLASS,
>>  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>>  	__POLICYDB_CAPABILITY_MAX
>>  };
>> @@ -77,6 +77,7 @@ enum {
>>  
>>  extern int selinux_policycap_netpeer;
>>  extern int selinux_policycap_openperm;
>> +extern int selinux_policycap_extsockclass;
>>  extern int selinux_policycap_alwaysnetwork;
>>  
>>  /*
>> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
>> index cf9293e..0aac402 100644
>> --- a/security/selinux/selinuxfs.c
>> +++ b/security/selinux/selinuxfs.c
>> @@ -45,7 +45,7 @@
>>  static char *policycap_names[] = {
>>  	"network_peer_controls",
>>  	"open_perms",
>> -	"redhat1",
>> +	"extended_socket_class",
>>  	"always_check_network"
>>  };
>>  
>> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
>> index 082b20c..a70fcee 100644
>> --- a/security/selinux/ss/services.c
>> +++ b/security/selinux/ss/services.c
>> @@ -72,6 +72,7 @@
>>  
>>  int selinux_policycap_netpeer;
>>  int selinux_policycap_openperm;
>> +int selinux_policycap_extsockclass;
>>  int selinux_policycap_alwaysnetwork;
>>  
>>  static DEFINE_RWLOCK(policy_rwlock);
>> @@ -1988,6 +1989,8 @@ static void security_load_policycaps(void)
>>  						  POLICYDB_CAPABILITY_NETPEER);
>>  	selinux_policycap_openperm = ebitmap_get_bit(&policydb.policycaps,
>>  						  POLICYDB_CAPABILITY_OPENPERM);
>> +	selinux_policycap_extsockclass = ebitmap_get_bit(&policydb.policycaps,
>> +					  POLICYDB_CAPABILITY_EXTSOCKCLASS);
>>  	selinux_policycap_alwaysnetwork = ebitmap_get_bit(&policydb.policycaps,
>>  						  POLICYDB_CAPABILITY_ALWAYSNETWORK);
>>  }
>>
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 15:07 [RFC][PATCH] selinux: support distinctions among all network address families Stephen Smalley
  2016-12-01 15:57 ` Stephen Smalley
@ 2016-12-01 17:04 ` Guido Trentalancia
  1 sibling, 0 replies; 19+ messages in thread
From: Guido Trentalancia @ 2016-12-01 17:04 UTC (permalink / raw)
  To: Stephen Smalley, selinux

Hello Stephen.

Glad to hear that this is making its way into the kernel !

On Thu, 01/12/2016 at 10.07 -0500, Stephen Smalley wrote:
> Extend SELinux to support distinctions among all network address
> families
> implemented by the kernel by defining new socket security classes
> and mapping to them. Otherwise, many sockets are mapped to the
> generic
> socket class and are indistinguishable in policy.  This has come up
> previously with regard to selectively allowing access to bluetooth
> sockets,
> and more recently with regard to selectively allowing access to
> AF_ALG
> sockets.  Guido Trentalancia submitted a patch that took a similar
> approach
> to add only support for distinguishing AF_ALG sockets, but this
> generalizes
> his approach to handle all address families implemented by the
> kernel.
> Socket security classes were not defined for AF_* values that are
> reserved
> but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY,
> AF_ECONET,
> AF_SNA, AF_WANPIPE.
> 
> Backward compatibility is provided by only enabling the finer-grained
> socket classes if a new policy capability is set in the policy; older
> policies will behave as before.  The legacy redhat1 policy capability
> that was only ever used in testing within Fedora for ptrace_child
> is reclaimed for this purpose; as far as I can tell, this policy
> capability is not enabled in any supported distro policy.
> 
> Add a pair of conditional compilation guards to detect when new AF_*
> values
> are added so that we can update SELinux accordingly rather than
> having to
> belatedly update it long after new address families are introduced.
> 
> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
> ---
>  security/selinux/hooks.c            | 67
> +++++++++++++++++++++++++++++++++++++
>  security/selinux/include/classmap.h | 62
> ++++++++++++++++++++++++++++++++++
>  security/selinux/include/security.h |  3 +-
>  security/selinux/selinuxfs.c        |  2 +-
>  security/selinux/ss/services.c      |  3 ++
>  5 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 98a2e92..1ee2172 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -1342,6 +1342,73 @@ static inline u16
> socket_type_to_security_class(int family, int type, int protoc
>  		return SECCLASS_APPLETALK_SOCKET;
>  	}
>  
> +	if (!selinux_policycap_extsockclass)
> +		return SECCLASS_SOCKET;
> +

The only suggestion I have to make is that, in my opinion, it might
read better and it might be easier to maintain in the future, if the
above is rewritten as follows:

if (selinux_policycap_extsockclass) {
	switch (family) {
		...
	}
}

and the return statement at the end of the function is retained.

That way, it is possible to easily add other similar policy
capabilities in the future, by just plugging in similar if statements !

Other than that, it looks fine to me and I have no other suggestions to
make about this patch.

> +	switch (family) {
> +	case PF_AX25:
> +		return SECCLASS_AX25_SOCKET;
> +	case PF_IPX:
> +		return SECCLASS_IPX_SOCKET;
> +	case PF_NETROM:
> +		return SECCLASS_NETROM_SOCKET;
> +	case PF_BRIDGE:
> +		return SECCLASS_BRIDGE_SOCKET;
> +	case PF_ATMPVC:
> +		return SECCLASS_ATMPVC_SOCKET;
> +	case PF_X25:
> +		return SECCLASS_X25_SOCKET;
> +	case PF_ROSE:
> +		return SECCLASS_ROSE_SOCKET;
> +	case PF_DECnet:
> +		return SECCLASS_DECNET_SOCKET;
> +	case PF_ATMSVC:
> +		return SECCLASS_ATMSVC_SOCKET;
> +	case PF_RDS:
> +		return SECCLASS_RDS_SOCKET;
> +	case PF_IRDA:
> +		return SECCLASS_IRDA_SOCKET;
> +	case PF_PPPOX:
> +		return SECCLASS_PPPOX_SOCKET;
> +	case PF_LLC:
> +		return SECCLASS_LLC_SOCKET;
> +	case PF_IB:
> +		return SECCLASS_IB_SOCKET;
> +	case PF_MPLS:
> +		return SECCLASS_MPLS_SOCKET;
> +	case PF_CAN:
> +		return SECCLASS_CAN_SOCKET;
> +	case PF_TIPC:
> +		return SECCLASS_TIPC_SOCKET;
> +	case PF_BLUETOOTH:
> +		return SECCLASS_BLUETOOTH_SOCKET;
> +	case PF_IUCV:
> +		return SECCLASS_IUCV_SOCKET;
> +	case PF_RXRPC:
> +		return SECCLASS_RXRPC_SOCKET;
> +	case PF_ISDN:
> +		return SECCLASS_ISDN_SOCKET;
> +	case PF_PHONET:
> +		return SECCLASS_PHONET_SOCKET;
> +	case PF_IEEE802154:
> +		return SECCLASS_IEEE802154_SOCKET;
> +	case PF_CAIF:
> +		return SECCLASS_CAIF_SOCKET;
> +	case PF_ALG:
> +		return SECCLASS_ALG_SOCKET;
> +	case PF_NFC:
> +		return SECCLASS_NFC_SOCKET;
> +	case PF_VSOCK:
> +		return SECCLASS_VSOCK_SOCKET;
> +	case PF_KCM:
> +		return SECCLASS_KCM_SOCKET;
> +	case PF_QIPCRTR:
> +		return SECCLASS_QIPCRTR_SOCKET;
> +#if PF_MAX > 43
> +#error New address family defined, please update this function.
> +#endif
> +	}
> +
>  	return SECCLASS_SOCKET;
>  }
>  
> diff --git a/security/selinux/include/classmap.h
> b/security/selinux/include/classmap.h
> index e2d4ad3a..a11be76 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -169,5 +169,67 @@ struct security_class_mapping secclass_map[] = {
>  	  { COMMON_CAP_PERMS, NULL } },
>  	{ "cap2_userns",
>  	  { COMMON_CAP2_PERMS, NULL } },
> +	{ "ax25_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ipx_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "netrom_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "bridge_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "atmpvc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "x25_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rose_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "decnet_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "atmsvc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rds_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "irda_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "pppox_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "llc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ib_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "mpls_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "can_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "tipc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "bluetooth_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "iucv_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "rxrpc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "isdn_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "phonet_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "ieee802154_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "caif_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "alg_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "nfc_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "vsock_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "kcm_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
> +	{ "qipcrtr_socket",
> +	  { COMMON_SOCK_PERMS, NULL } },
>  	{ NULL }
>    };
> +
> +#if PF_MAX > 43
> +#error New address family defined, please update secclass_map.
> +#endif
> diff --git a/security/selinux/include/security.h
> b/security/selinux/include/security.h
> index 308a286..beaa14b 100644
> --- a/security/selinux/include/security.h
> +++ b/security/selinux/include/security.h
> @@ -69,7 +69,7 @@ extern int selinux_enabled;
>  enum {
>  	POLICYDB_CAPABILITY_NETPEER,
>  	POLICYDB_CAPABILITY_OPENPERM,
> -	POLICYDB_CAPABILITY_REDHAT1,
> +	POLICYDB_CAPABILITY_EXTSOCKCLASS,
>  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>  	__POLICYDB_CAPABILITY_MAX
>  };
> @@ -77,6 +77,7 @@ enum {
>  
>  extern int selinux_policycap_netpeer;
>  extern int selinux_policycap_openperm;
> +extern int selinux_policycap_extsockclass;
>  extern int selinux_policycap_alwaysnetwork;
>  
>  /*
> diff --git a/security/selinux/selinuxfs.c
> b/security/selinux/selinuxfs.c
> index cf9293e..0aac402 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -45,7 +45,7 @@
>  static char *policycap_names[] = {
>  	"network_peer_controls",
>  	"open_perms",
> -	"redhat1",
> +	"extended_socket_class",
>  	"always_check_network"
>  };
>  
> diff --git a/security/selinux/ss/services.c
> b/security/selinux/ss/services.c
> index 082b20c..a70fcee 100644
> --- a/security/selinux/ss/services.c
> +++ b/security/selinux/ss/services.c
> @@ -72,6 +72,7 @@
>  
>  int selinux_policycap_netpeer;
>  int selinux_policycap_openperm;
> +int selinux_policycap_extsockclass;
>  int selinux_policycap_alwaysnetwork;
>  
>  static DEFINE_RWLOCK(policy_rwlock);
> @@ -1988,6 +1989,8 @@ static void security_load_policycaps(void)
>  						  POLICYDB_CAPABILIT
> Y_NETPEER);
>  	selinux_policycap_openperm =
> ebitmap_get_bit(&policydb.policycaps,
>  						  POLICYDB_CAPABILIT
> Y_OPENPERM);
> +	selinux_policycap_extsockclass =
> ebitmap_get_bit(&policydb.policycaps,
> +					  POLICYDB_CAPABILITY_EXTSOC
> KCLASS);
>  	selinux_policycap_alwaysnetwork =
> ebitmap_get_bit(&policydb.policycaps,
>  						  POLICYDB_CAPABILIT
> Y_ALWAYSNETWORK);
>  }

With kind regards,

Guido

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 15:57 ` Stephen Smalley
  2016-12-01 16:26   ` Stephen Smalley
@ 2016-12-01 17:28   ` Guido Trentalancia
  2016-12-01 18:03     ` Stephen Smalley
  2016-12-02 17:40   ` Stephen Smalley
  2 siblings, 1 reply; 19+ messages in thread
From: Guido Trentalancia @ 2016-12-01 17:28 UTC (permalink / raw)
  To: Stephen Smalley, selinux

Hello again Stephen and Paul.

On Thu, 01/12/2016 at 10.57 -0500, Stephen Smalley wrote:
> On 12/01/2016 10:07 AM, Stephen Smalley wrote:

[...]

> A couple of notes on this change:
> 
> - To fully test (beyond just confirming that it doesn't break
> anything
> when the policy capability is not defined), we'll need a patched
> libsepol and policy (and unfortunately it requires patching the base
> policy; can't be done via a policy module).  Can certainly provide
> those
> too but figured I'd wait to see the response to the kernel patch
> first.

The libsepol patch is straightforward.

You can have a look at the one I have posted on the 23rd of August 2016
under the subject "[PATCH] Update libsepol to support the policy
capability for AF_ALG sockets" and adapt it to the new policy
capability name and to the fact that you are now removing the Redhat
policy capability.

As for the Reference Policy patch, if you want, I can forward to you
the one that I had created at that time for the ALG_SOCKET family, so
that you can adapt it to the multiple socket types.

Same thing for the SELinux Testsuite patch: if you want, I can forward
to you the one that I had created at that time for the ALG_SOCKET
family and that would be enough for testing the new capability because
it's representative of all the new socket types.

With kind regards,

Guido

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 17:28   ` Guido Trentalancia
@ 2016-12-01 18:03     ` Stephen Smalley
  2016-12-01 18:53       ` Stephen Smalley
  2016-12-01 20:42       ` Guido Trentalancia
  0 siblings, 2 replies; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 18:03 UTC (permalink / raw)
  To: Guido Trentalancia, selinux

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

On 12/01/2016 12:28 PM, Guido Trentalancia wrote:
> Hello again Stephen and Paul.
> 
> On Thu, 01/12/2016 at 10.57 -0500, Stephen Smalley wrote:
>> On 12/01/2016 10:07 AM, Stephen Smalley wrote:
> 
> [...]
> 
>> A couple of notes on this change:
>>
>> - To fully test (beyond just confirming that it doesn't break
>> anything
>> when the policy capability is not defined), we'll need a patched
>> libsepol and policy (and unfortunately it requires patching the base
>> policy; can't be done via a policy module).  Can certainly provide
>> those
>> too but figured I'd wait to see the response to the kernel patch
>> first.
> 
> The libsepol patch is straightforward.
> 
> You can have a look at the one I have posted on the 23rd of August 2016
> under the subject "[PATCH] Update libsepol to support the policy
> capability for AF_ALG sockets" and adapt it to the new policy
> capability name and to the fact that you are now removing the Redhat
> policy capability.
> 
> As for the Reference Policy patch, if you want, I can forward to you
> the one that I had created at that time for the ALG_SOCKET family, so
> that you can adapt it to the multiple socket types.
> 
> Same thing for the SELinux Testsuite patch: if you want, I can forward
> to you the one that I had created at that time for the ALG_SOCKET
> family and that would be enough for testing the new capability because
> it's representative of all the new socket types.
> 
> With kind regards,

Actually, I realized belatedly that CIL makes it possible to enable
testing of this change just through a policy module.  Attached is a CIL
policy module that one can insert via semodule -i
testextsockclass.cil (caveat: may break your system if using any of
these socket classes). Also attached is the libsepol patch.  So now I
just need a test case - will have a look at your AF_ALG patch.


[-- Attachment #2: testextsockclass.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 2119 bytes --]

[-- Attachment #3: 0001-libsepol-Define-extended_socket_class-policy-capabil.patch --]
[-- Type: text/x-patch, Size: 1888 bytes --]

>From daaea4522b34a54c2cff319c458d7d1a0267ecbe Mon Sep 17 00:00:00 2001
From: Stephen Smalley <sds@tycho.nsa.gov>
Date: Thu, 1 Dec 2016 11:08:06 -0500
Subject: [PATCH] libsepol: Define extended_socket_class policy capability

Define the extended_socket_class policy capability used to enable
the use of separate socket security classes for all network address
families rather than the generic socket class.

The legacy redhat1 policy capability that was only ever used in testing
within Fedora for ptrace_child is reclaimed for this purpose; as far as
I can tell, this policy capability is not enabled in any supported distro
policy.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
---
 libsepol/include/sepol/policydb/polcaps.h | 2 +-
 libsepol/src/polcaps.c                    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libsepol/include/sepol/policydb/polcaps.h b/libsepol/include/sepol/policydb/polcaps.h
index 53d7994..c9e40f6 100644
--- a/libsepol/include/sepol/policydb/polcaps.h
+++ b/libsepol/include/sepol/policydb/polcaps.h
@@ -9,7 +9,7 @@ extern "C" {
 enum {
 	POLICYDB_CAPABILITY_NETPEER,
 	POLICYDB_CAPABILITY_OPENPERM,
-	POLICYDB_CAPABILITY_REDHAT1, /* reserved for RH testing of ptrace_child */
+	POLICYDB_CAPABILITY_EXTSOCKCLASS,
 	POLICYDB_CAPABILITY_ALWAYSNETWORK,
 	__POLICYDB_CAPABILITY_MAX
 };
diff --git a/libsepol/src/polcaps.c b/libsepol/src/polcaps.c
index 43a71a7..3924cb8 100644
--- a/libsepol/src/polcaps.c
+++ b/libsepol/src/polcaps.c
@@ -8,7 +8,7 @@
 static const char *polcap_names[] = {
 	"network_peer_controls",	/* POLICYDB_CAPABILITY_NETPEER */
 	"open_perms",			/* POLICYDB_CAPABILITY_OPENPERM */
-	"redhat1",			/* POLICYDB_CAPABILITY_REDHAT1, aka ptrace_child */
+	"extended_socket_class",	/* POLICYDB_CAPABILITY_EXTSOCKCLASS */
 	"always_check_network",		/* POLICYDB_CAPABILITY_ALWAYSNETWORK */
 	NULL
 };
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 18:03     ` Stephen Smalley
@ 2016-12-01 18:53       ` Stephen Smalley
  2016-12-01 21:37         ` Guido Trentalancia
  2016-12-01 20:42       ` Guido Trentalancia
  1 sibling, 1 reply; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 18:53 UTC (permalink / raw)
  To: Guido Trentalancia, selinux

On 12/01/2016 01:03 PM, Stephen Smalley wrote:
> On 12/01/2016 12:28 PM, Guido Trentalancia wrote:
>> Hello again Stephen and Paul.
>>
>> On Thu, 01/12/2016 at 10.57 -0500, Stephen Smalley wrote:
>>> On 12/01/2016 10:07 AM, Stephen Smalley wrote:
>>
>> [...]
>>
>>> A couple of notes on this change:
>>>
>>> - To fully test (beyond just confirming that it doesn't break
>>> anything
>>> when the policy capability is not defined), we'll need a patched
>>> libsepol and policy (and unfortunately it requires patching the base
>>> policy; can't be done via a policy module).  Can certainly provide
>>> those
>>> too but figured I'd wait to see the response to the kernel patch
>>> first.
>>
>> The libsepol patch is straightforward.
>>
>> You can have a look at the one I have posted on the 23rd of August 2016
>> under the subject "[PATCH] Update libsepol to support the policy
>> capability for AF_ALG sockets" and adapt it to the new policy
>> capability name and to the fact that you are now removing the Redhat
>> policy capability.
>>
>> As for the Reference Policy patch, if you want, I can forward to you
>> the one that I had created at that time for the ALG_SOCKET family, so
>> that you can adapt it to the multiple socket types.
>>
>> Same thing for the SELinux Testsuite patch: if you want, I can forward
>> to you the one that I had created at that time for the ALG_SOCKET
>> family and that would be enough for testing the new capability because
>> it's representative of all the new socket types.
>>
>> With kind regards,
> 
> Actually, I realized belatedly that CIL makes it possible to enable
> testing of this change just through a policy module.  Attached is a CIL
> policy module that one can insert via semodule -i
> testextsockclass.cil (caveat: may break your system if using any of
> these socket classes). Also attached is the libsepol patch.  So now I
> just need a test case - will have a look at your AF_ALG patch.

So I confirmed that using your test program, I get an avc denial for
create on alg_socket unless I allow that permission to the domain
running the program, as expected.  So no surprises there.  I'll defer
putting together a real patch for selinux-testsuite until it is clear
that the kernel patch is going to be accepted, and regardless, we'll
have to work through how to make it conditional on all the right factors
(kernel version, policy defines the capability and the new socket
classes or we add them temporarily for the tests via the CIL policy module).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 18:03     ` Stephen Smalley
  2016-12-01 18:53       ` Stephen Smalley
@ 2016-12-01 20:42       ` Guido Trentalancia
  2016-12-01 21:10         ` Stephen Smalley
  1 sibling, 1 reply; 19+ messages in thread
From: Guido Trentalancia @ 2016-12-01 20:42 UTC (permalink / raw)
  To: Stephen Smalley, selinux

Hello Stephen.

On Thu, 01/12/2016 at 13.03 -0500, Stephen Smalley write:
> On 12/01/2016 12:28 PM, Guido Trentalancia wrote:
> > 
> > Hello again Stephen and Paul.
> > 
> > On Thu, 01/12/2016 at 10.57 -0500, Stephen Smalley wrote:
> > > 
> > > On 12/01/2016 10:07 AM, Stephen Smalley wrote:
> > 
> > [...]
> > 
> > > 
> > > A couple of notes on this change:
> > > 
> > > - To fully test (beyond just confirming that it doesn't break
> > > anything
> > > when the policy capability is not defined), we'll need a patched
> > > libsepol and policy (and unfortunately it requires patching the
> > > base
> > > policy; can't be done via a policy module).  Can certainly
> > > provide
> > > those
> > > too but figured I'd wait to see the response to the kernel patch
> > > first.
> > 
> > The libsepol patch is straightforward.
> > 
> > You can have a look at the one I have posted on the 23rd of August
> > 2016
> > under the subject "[PATCH] Update libsepol to support the policy
> > capability for AF_ALG sockets" and adapt it to the new policy
> > capability name and to the fact that you are now removing the
> > Redhat
> > policy capability.
> > 
> > As for the Reference Policy patch, if you want, I can forward to
> > you
> > the one that I had created at that time for the ALG_SOCKET family,
> > so
> > that you can adapt it to the multiple socket types.
> > 
> > Same thing for the SELinux Testsuite patch: if you want, I can
> > forward
> > to you the one that I had created at that time for the ALG_SOCKET
> > family and that would be enough for testing the new capability
> > because
> > it's representative of all the new socket types.
> > 
> > With kind regards,
> 
> Actually, I realized belatedly that CIL makes it possible to enable
> testing of this change just through a policy module.  Attached is a
> CIL
> policy module that one can insert via semodule -i
> testextsockclass.cil (caveat: may break your system if using any of
> these socket classes). Also attached is the libsepol patch.  So now I
> just need a test case - will have a look at your AF_ALG patch.

The libsepol patch looks fine to me, provided that, as you say, it
doesn't break anything on Redhat systems.

Regards,

Guido

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 20:42       ` Guido Trentalancia
@ 2016-12-01 21:10         ` Stephen Smalley
  0 siblings, 0 replies; 19+ messages in thread
From: Stephen Smalley @ 2016-12-01 21:10 UTC (permalink / raw)
  To: Guido Trentalancia, selinux

On 12/01/2016 03:42 PM, Guido Trentalancia wrote:
> Hello Stephen.
> 
> On Thu, 01/12/2016 at 13.03 -0500, Stephen Smalley write:
>> On 12/01/2016 12:28 PM, Guido Trentalancia wrote:
>>>
>>> Hello again Stephen and Paul.
>>>
>>> On Thu, 01/12/2016 at 10.57 -0500, Stephen Smalley wrote:
>>>>
>>>> On 12/01/2016 10:07 AM, Stephen Smalley wrote:
>>>
>>> [...]
>>>
>>>>
>>>> A couple of notes on this change:
>>>>
>>>> - To fully test (beyond just confirming that it doesn't break
>>>> anything
>>>> when the policy capability is not defined), we'll need a patched
>>>> libsepol and policy (and unfortunately it requires patching the
>>>> base
>>>> policy; can't be done via a policy module).  Can certainly
>>>> provide
>>>> those
>>>> too but figured I'd wait to see the response to the kernel patch
>>>> first.
>>>
>>> The libsepol patch is straightforward.
>>>
>>> You can have a look at the one I have posted on the 23rd of August
>>> 2016
>>> under the subject "[PATCH] Update libsepol to support the policy
>>> capability for AF_ALG sockets" and adapt it to the new policy
>>> capability name and to the fact that you are now removing the
>>> Redhat
>>> policy capability.
>>>
>>> As for the Reference Policy patch, if you want, I can forward to
>>> you
>>> the one that I had created at that time for the ALG_SOCKET family,
>>> so
>>> that you can adapt it to the multiple socket types.
>>>
>>> Same thing for the SELinux Testsuite patch: if you want, I can
>>> forward
>>> to you the one that I had created at that time for the ALG_SOCKET
>>> family and that would be enough for testing the new capability
>>> because
>>> it's representative of all the new socket types.
>>>
>>> With kind regards,
>>
>> Actually, I realized belatedly that CIL makes it possible to enable
>> testing of this change just through a policy module.  Attached is a
>> CIL
>> policy module that one can insert via semodule -i
>> testextsockclass.cil (caveat: may break your system if using any of
>> these socket classes). Also attached is the libsepol patch.  So now I
>> just need a test case - will have a look at your AF_ALG patch.
> 
> The libsepol patch looks fine to me, provided that, as you say, it
> doesn't break anything on Redhat systems.

AFAICT, the ptrace_child policy capability (for which redhat1 was
reserved, occupying the same bit) was never set in a policy in any
Fedora release (only rawhide) and never in RHEL.  And the kernel patch
for ptrace_child seems to only have been in F17.  So I don't believe
there are any ramifications to reusing it.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 18:53       ` Stephen Smalley
@ 2016-12-01 21:37         ` Guido Trentalancia
  0 siblings, 0 replies; 19+ messages in thread
From: Guido Trentalancia @ 2016-12-01 21:37 UTC (permalink / raw)
  To: Stephen Smalley, selinux

Hello again !

On Thu, 01/12/2016 at 13.53 -0500, Stephen Smalley wrote:
> On 12/01/2016 01:03 PM, Stephen Smalley wrote:

[...]

> > Actually, I realized belatedly that CIL makes it possible to enable
> > testing of this change just through a policy module.  Attached is a
> > CIL
> > policy module that one can insert via semodule -i
> > testextsockclass.cil (caveat: may break your system if using any of
> > these socket classes). Also attached is the libsepol patch.  So now
> > I
> > just need a test case - will have a look at your AF_ALG patch.
> 
> So I confirmed that using your test program, I get an avc denial for
> create on alg_socket unless I allow that permission to the domain
> running the program, as expected.  So no surprises there.  I'll defer
> putting together a real patch for selinux-testsuite until it is clear
> that the kernel patch is going to be accepted, and regardless, we'll
> have to work through how to make it conditional on all the right
> factors
> (kernel version, policy defines the capability and the new socket
> classes or we add them temporarily for the tests via the CIL policy
> module).

I have modified the SELinux Testsuite patch that I originally posted on
the 24th of August 2016 with subject "Re: [PATCH v5] Classify AF_ALG
sockets", so that it checks the kernel version (you have to edit the
minimum version in the test source file)...

If you decide to use the standard tests instead of the CIL module, you
can save some time by using the following:

[cut]

This patch for the SELinux testsuite aims to add a very simple test
for sockets in the AF_ALG namespace.

Such test is representative of the new set of socket families that
the kernel supports if it supports the new extended_socket_class
SELinux policy capability.

BEFORE USING PLEASE EDIT THE KER_VERSION, KER_PATCHLEVEL AND
KER_SUBLEVEL DEFINED IN THE TEST SOURCE FILE.

Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
---
 policy/Makefile           |    2
 policy/test_alg_socket.te |   25 ++++++++++++
 tests/alg_socket/Makefile |    5 ++
 tests/alg_socket/client.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++
 tests/alg_socket/test     |   26 ++++++++++++
 5 files changed, 151 insertions(+), 1 deletion(-)

diff -pruN selinux-testsuite-01122016-orig/policy/Makefile selinux-testsuite-01122016/policy/Makefile
--- selinux-testsuite-01122016-orig/policy/Makefile	2016-12-01 21:52:49.170252694 +0100
+++ selinux-testsuite-01122016/policy/Makefile	2016-12-01 22:24:44.388153327 +0100
@@ -20,7 +20,7 @@ TARGETS = \
 	test_task_create.te test_task_getpgid.te test_task_getsched.te \
 	test_task_getsid.te test_task_setpgid.te test_task_setsched.te \
 	test_transition.te test_inet_socket.te test_unix_socket.te \
-	test_wait.te test_mmap.te test_overlayfs.te
+	test_alg_socket.te test_wait.te test_mmap.te test_overlayfs.te
 
 ifeq ($(shell [ $(POL_VERS) -ge 24 ] && echo true),true)
 TARGETS += test_bounds.te
diff -pruN selinux-testsuite-01122016-orig/policy/test_alg_socket.te selinux-testsuite-01122016/policy/test_alg_socket.te
--- selinux-testsuite-01122016-orig/policy/test_alg_socket.te	1970-01-01 01:00:00.000000000 +0100
+++ selinux-testsuite-01122016/policy/test_alg_socket.te	2016-12-01 21:53:30.813685402 +0100
@@ -0,0 +1,25 @@
+#################################
+#
+# Policy for testing sockets in
+# the AF_ALG namespace (Crypto
+# API).
+#
+
+attribute algsocketdomain;
+
+# Domain for client process.
+type test_alg_socket_client_t;
+domain_type(test_alg_socket_client_t)
+unconfined_runs_test(test_alg_socket_client_t)
+typeattribute test_alg_socket_client_t testdomain;
+typeattribute test_alg_socket_client_t algsocketdomain;
+
+# client can bind socket.
+allow test_alg_socket_client_t self:alg_socket bind;
+
+# client can request to load a kernel module
+kernel_request_load_module(algsocketdomain)
+
+# Allow all of these domains to be entered from the sysadm domain.
+miscfiles_domain_entry_test_files(algsocketdomain)
+userdom_sysadm_entry_spec_domtrans_to(algsocketdomain)
diff -pruN selinux-testsuite-01122016-orig/tests/alg_socket/client.c selinux-testsuite-01122016/tests/alg_socket/client.c
--- selinux-testsuite-01122016-orig/tests/alg_socket/client.c	1970-01-01 01:00:00.000000000 +0100
+++ selinux-testsuite-01122016/tests/alg_socket/client.c	2016-12-01 22:19:23.143815343 +0100
@@ -0,0 +1,94 @@
+/*
+ * The alg_socket is representative of the new set of
+ * socket families that the kernel is able to classify
+ * when it supports the new extended_socket_class policy
+ * capability.
+ *
+ * This test simply checks the result of bind() using
+ * the Kernel Crypto API.
+ */
+
+#include <sys/socket.h>
+#include <linux/if_alg.h>
+#include <linux/version.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+
+/*
+ * First kernel version that supports the new
+ * extended_socket_class policy capability.
+ */
+
+#define KER_VERSION	4
+#define KER_PATCHLEVEL	99
+#define KER_SUBLEVEL	99
+
+void usage(char *progname)
+{
+	fprintf(stderr,
+		"usage:  %s [succeed|fail]\n",
+		progname);
+	exit(1);
+}
+
+int
+main(int argc, char **argv)
+{
+	int succeed;
+	int sock;
+
+	if (argc != 2)
+		usage(argv[0]);
+
+	if (!strcmp(argv[1], "succeed"))
+		succeed = 1;
+	else if (!strcmp(argv[1], "fail"))
+		succeed = 0;
+	else
+		usage(argv[0]);
+
+	sock = socket(AF_ALG, SOCK_SEQPACKET, 0);
+	if (sock < 0) {
+		perror("socket");
+		exit(1);
+	}
+
+	if (succeed == 1) {
+		struct sockaddr_alg sa_good = {
+			.salg_family = AF_ALG,
+			.salg_type = "hash",
+			.salg_name = "sha256",
+		};
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(KER_VERSION,KER_PATCHLEVEL,KER_SUBLEVEL)
+		if (bind(sock, (struct sockaddr *) &sa_good, sizeof(sa_good)) < 0) {
+			perror("bind (algorithm available)");
+			close(sock);
+			exit(1);
+		}
+#else /* kernel does not support the new policy capability */
+	exit(0);
+#endif
+	} else {
+		struct sockaddr_alg sa_bad = {
+			.salg_family = AF_ALG,
+			.salg_type = "hash",
+			.salg_name = "NOTAVAILABLE",
+		};
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(KER_VERSION,KER_PATCHLEVEL,KER_SUBLEVEL)
+		if (bind(sock, (struct sockaddr *) &sa_bad, sizeof(sa_bad)) < 0) {
+			perror("bind (algorithm not available)");
+			close(sock);
+			exit(1);
+		}
+#else /* kernel does not support the new policy capability */
+	exit(1);
+#endif
+	}
+
+	close(sock);
+	exit(0);
+}
diff -pruN selinux-testsuite-01122016-orig/tests/alg_socket/Makefile selinux-testsuite-01122016/tests/alg_socket/Makefile
--- selinux-testsuite-01122016-orig/tests/alg_socket/Makefile	1970-01-01 01:00:00.000000000 +0100
+++ selinux-testsuite-01122016/tests/alg_socket/Makefile	2016-12-01 21:53:30.814685412 +0100
@@ -0,0 +1,5 @@
+TARGETS=client
+
+all: $(TARGETS)
+clean:
+	rm -f $(TARGETS)
diff -pruN selinux-testsuite-01122016-orig/tests/alg_socket/test selinux-testsuite-01122016/tests/alg_socket/test
--- selinux-testsuite-01122016-orig/tests/alg_socket/test	1970-01-01 01:00:00.000000000 +0100
+++ selinux-testsuite-01122016/tests/alg_socket/test	2016-12-01 22:19:42.868020293 +0100
@@ -0,0 +1,26 @@
+#!/usr/bin/perl
+
+use Test;
+BEGIN { plan tests => 2}
+
+$basedir = $0;  $basedir =~ s|(.*)/[^/]*|$1|;
+
+#
+# Tests for sockets in the AF_ALG namespace (Crypto API).
+#
+# The AF_ALG socket is representative of the new set of
+# socket families that the kernel can classify when it
+# supports the new extended_socket_class policy capability.
+#
+
+# Verify that the client can initialize the server with an
+# available algorithm.
+$result = system "runcon -t test_alg_socket_client_t $basedir/client succeed";
+ok($result, 0);
+
+# Verify that the client cannot initialize the server with an
+# unavailable algorithm.
+$result = system "runcon -t test_alg_socket_client_t $basedir/client fail";
+ok($result);
+
+exit;

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-01 15:57 ` Stephen Smalley
  2016-12-01 16:26   ` Stephen Smalley
  2016-12-01 17:28   ` Guido Trentalancia
@ 2016-12-02 17:40   ` Stephen Smalley
  2016-12-02 22:39     ` Paul Moore
  2 siblings, 1 reply; 19+ messages in thread
From: Stephen Smalley @ 2016-12-02 17:40 UTC (permalink / raw)
  To: selinux

On 12/01/2016 10:57 AM, Stephen Smalley wrote:
> On 12/01/2016 10:07 AM, Stephen Smalley wrote:
>> Extend SELinux to support distinctions among all network address families
>> implemented by the kernel by defining new socket security classes
>> and mapping to them. Otherwise, many sockets are mapped to the generic
>> socket class and are indistinguishable in policy.  This has come up
>> previously with regard to selectively allowing access to bluetooth sockets,
>> and more recently with regard to selectively allowing access to AF_ALG
>> sockets.  Guido Trentalancia submitted a patch that took a similar approach
>> to add only support for distinguishing AF_ALG sockets, but this generalizes
>> his approach to handle all address families implemented by the kernel.
>> Socket security classes were not defined for AF_* values that are reserved
>> but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ECONET,
>> AF_SNA, AF_WANPIPE.
>>
>> Backward compatibility is provided by only enabling the finer-grained
>> socket classes if a new policy capability is set in the policy; older
>> policies will behave as before.  The legacy redhat1 policy capability
>> that was only ever used in testing within Fedora for ptrace_child
>> is reclaimed for this purpose; as far as I can tell, this policy
>> capability is not enabled in any supported distro policy.
>>
>> Add a pair of conditional compilation guards to detect when new AF_* values
>> are added so that we can update SELinux accordingly rather than having to
>> belatedly update it long after new address families are introduced.
> 
> A couple of notes on this change:
> 
> - To fully test (beyond just confirming that it doesn't break anything
> when the policy capability is not defined), we'll need a patched
> libsepol and policy (and unfortunately it requires patching the base
> policy; can't be done via a policy module).  Can certainly provide those
> too but figured I'd wait to see the response to the kernel patch first.
> 
> - There is a potential cost to this change when/if it is enabled in
> policy, i.e. if we blindly allowing all of these new classes where we
> previously allowed the generic socket class, we'll end up with
> significant growth in policy avtab entries and in AVC entries (although
> only if they are in fact used), since those are per-class.  However, I
> wouldn't expect to do that except possibly for the unconfined domain;
> many of these classes won't need to be allowed at all for most domains.
> 
> - There is a slight compatibility issue.  While the policy capability
> ensures that we will not use the new socket classes with old policies,
> we don't presently support a way to refresh socket security classes upon
> a policy reload.  Hence, if you boot a kernel with a policy that has the
> capability disabled, and then later load a policy that has the
> capability enabled, any existing sockets won't be automatically moved
> into the new security classes; they will continue to be treated as
> having the generic socket security class.  I view this as a minor issue
> and unlikely to cause any breakage, because refpolicy is likely to
> merely add new rules for the new socket classes without removing the old
> rules on the generic socket security class to provide backward
> compatibility with kernels that predate this change.  Eventually we may
> be able to drop those rules, but not for quite some time.  In any event,
> be aware that taking full advantage of these new classes does require a
> reboot.

I suppose a further question on this patch is whether it should also add
new classes for ICMP, IGMP, and SCTP sockets (any others that are
presently mapped to SECCLASS_RAWIP_SOCKET that ought to be given their
own class?).  In the SCTP case, this would at least allow them to be
distinguished, but we would still lack the full support added by the
separate SCTP patchset.

> 
>>
>> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
>> ---
>>  security/selinux/hooks.c            | 67 +++++++++++++++++++++++++++++++++++++
>>  security/selinux/include/classmap.h | 62 ++++++++++++++++++++++++++++++++++
>>  security/selinux/include/security.h |  3 +-
>>  security/selinux/selinuxfs.c        |  2 +-
>>  security/selinux/ss/services.c      |  3 ++
>>  5 files changed, 135 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 98a2e92..1ee2172 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -1342,6 +1342,73 @@ static inline u16 socket_type_to_security_class(int family, int type, int protoc
>>  		return SECCLASS_APPLETALK_SOCKET;
>>  	}
>>  
>> +	if (!selinux_policycap_extsockclass)
>> +		return SECCLASS_SOCKET;
>> +
>> +	switch (family) {
>> +	case PF_AX25:
>> +		return SECCLASS_AX25_SOCKET;
>> +	case PF_IPX:
>> +		return SECCLASS_IPX_SOCKET;
>> +	case PF_NETROM:
>> +		return SECCLASS_NETROM_SOCKET;
>> +	case PF_BRIDGE:
>> +		return SECCLASS_BRIDGE_SOCKET;
>> +	case PF_ATMPVC:
>> +		return SECCLASS_ATMPVC_SOCKET;
>> +	case PF_X25:
>> +		return SECCLASS_X25_SOCKET;
>> +	case PF_ROSE:
>> +		return SECCLASS_ROSE_SOCKET;
>> +	case PF_DECnet:
>> +		return SECCLASS_DECNET_SOCKET;
>> +	case PF_ATMSVC:
>> +		return SECCLASS_ATMSVC_SOCKET;
>> +	case PF_RDS:
>> +		return SECCLASS_RDS_SOCKET;
>> +	case PF_IRDA:
>> +		return SECCLASS_IRDA_SOCKET;
>> +	case PF_PPPOX:
>> +		return SECCLASS_PPPOX_SOCKET;
>> +	case PF_LLC:
>> +		return SECCLASS_LLC_SOCKET;
>> +	case PF_IB:
>> +		return SECCLASS_IB_SOCKET;
>> +	case PF_MPLS:
>> +		return SECCLASS_MPLS_SOCKET;
>> +	case PF_CAN:
>> +		return SECCLASS_CAN_SOCKET;
>> +	case PF_TIPC:
>> +		return SECCLASS_TIPC_SOCKET;
>> +	case PF_BLUETOOTH:
>> +		return SECCLASS_BLUETOOTH_SOCKET;
>> +	case PF_IUCV:
>> +		return SECCLASS_IUCV_SOCKET;
>> +	case PF_RXRPC:
>> +		return SECCLASS_RXRPC_SOCKET;
>> +	case PF_ISDN:
>> +		return SECCLASS_ISDN_SOCKET;
>> +	case PF_PHONET:
>> +		return SECCLASS_PHONET_SOCKET;
>> +	case PF_IEEE802154:
>> +		return SECCLASS_IEEE802154_SOCKET;
>> +	case PF_CAIF:
>> +		return SECCLASS_CAIF_SOCKET;
>> +	case PF_ALG:
>> +		return SECCLASS_ALG_SOCKET;
>> +	case PF_NFC:
>> +		return SECCLASS_NFC_SOCKET;
>> +	case PF_VSOCK:
>> +		return SECCLASS_VSOCK_SOCKET;
>> +	case PF_KCM:
>> +		return SECCLASS_KCM_SOCKET;
>> +	case PF_QIPCRTR:
>> +		return SECCLASS_QIPCRTR_SOCKET;
>> +#if PF_MAX > 43
>> +#error New address family defined, please update this function.
>> +#endif
>> +	}
>> +
>>  	return SECCLASS_SOCKET;
>>  }
>>  
>> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
>> index e2d4ad3a..a11be76 100644
>> --- a/security/selinux/include/classmap.h
>> +++ b/security/selinux/include/classmap.h
>> @@ -169,5 +169,67 @@ struct security_class_mapping secclass_map[] = {
>>  	  { COMMON_CAP_PERMS, NULL } },
>>  	{ "cap2_userns",
>>  	  { COMMON_CAP2_PERMS, NULL } },
>> +	{ "ax25_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ipx_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "netrom_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "bridge_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "atmpvc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "x25_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rose_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "decnet_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "atmsvc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rds_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "irda_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "pppox_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "llc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ib_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "mpls_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "can_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "tipc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "bluetooth_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "iucv_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "rxrpc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "isdn_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "phonet_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "ieee802154_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "caif_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "alg_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "nfc_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "vsock_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "kcm_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>> +	{ "qipcrtr_socket",
>> +	  { COMMON_SOCK_PERMS, NULL } },
>>  	{ NULL }
>>    };
>> +
>> +#if PF_MAX > 43
>> +#error New address family defined, please update secclass_map.
>> +#endif
>> diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
>> index 308a286..beaa14b 100644
>> --- a/security/selinux/include/security.h
>> +++ b/security/selinux/include/security.h
>> @@ -69,7 +69,7 @@ extern int selinux_enabled;
>>  enum {
>>  	POLICYDB_CAPABILITY_NETPEER,
>>  	POLICYDB_CAPABILITY_OPENPERM,
>> -	POLICYDB_CAPABILITY_REDHAT1,
>> +	POLICYDB_CAPABILITY_EXTSOCKCLASS,
>>  	POLICYDB_CAPABILITY_ALWAYSNETWORK,
>>  	__POLICYDB_CAPABILITY_MAX
>>  };
>> @@ -77,6 +77,7 @@ enum {
>>  
>>  extern int selinux_policycap_netpeer;
>>  extern int selinux_policycap_openperm;
>> +extern int selinux_policycap_extsockclass;
>>  extern int selinux_policycap_alwaysnetwork;
>>  
>>  /*
>> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
>> index cf9293e..0aac402 100644
>> --- a/security/selinux/selinuxfs.c
>> +++ b/security/selinux/selinuxfs.c
>> @@ -45,7 +45,7 @@
>>  static char *policycap_names[] = {
>>  	"network_peer_controls",
>>  	"open_perms",
>> -	"redhat1",
>> +	"extended_socket_class",
>>  	"always_check_network"
>>  };
>>  
>> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
>> index 082b20c..a70fcee 100644
>> --- a/security/selinux/ss/services.c
>> +++ b/security/selinux/ss/services.c
>> @@ -72,6 +72,7 @@
>>  
>>  int selinux_policycap_netpeer;
>>  int selinux_policycap_openperm;
>> +int selinux_policycap_extsockclass;
>>  int selinux_policycap_alwaysnetwork;
>>  
>>  static DEFINE_RWLOCK(policy_rwlock);
>> @@ -1988,6 +1989,8 @@ static void security_load_policycaps(void)
>>  						  POLICYDB_CAPABILITY_NETPEER);
>>  	selinux_policycap_openperm = ebitmap_get_bit(&policydb.policycaps,
>>  						  POLICYDB_CAPABILITY_OPENPERM);
>> +	selinux_policycap_extsockclass = ebitmap_get_bit(&policydb.policycaps,
>> +					  POLICYDB_CAPABILITY_EXTSOCKCLASS);
>>  	selinux_policycap_alwaysnetwork = ebitmap_get_bit(&policydb.policycaps,
>>  						  POLICYDB_CAPABILITY_ALWAYSNETWORK);
>>  }
>>
> 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-02 17:40   ` Stephen Smalley
@ 2016-12-02 22:39     ` Paul Moore
  2016-12-05 14:11       ` Stephen Smalley
  0 siblings, 1 reply; 19+ messages in thread
From: Paul Moore @ 2016-12-02 22:39 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: selinux, guido

On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> I suppose a further question on this patch is whether it should also add
> new classes for ICMP, IGMP, and SCTP sockets (any others that are
> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be given their
> own class?).  In the SCTP case, this would at least allow them to be
> distinguished, but we would still lack the full support added by the
> separate SCTP patchset.

For the record, I'm okay with this patch and I agree that the
compatibility concerns aren't likely to be significant.  However, I
would like to continue the discussion on the idea to include classes
for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP, but
considering the changes necessary for SCTP I think it is okay to leave
SCTP out for now and add it in with proper SCTP support (and its own
policy capability).

Stephen, I'm assuming you feel the same since you left that out of the patch?

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-02 22:39     ` Paul Moore
@ 2016-12-05 14:11       ` Stephen Smalley
  2016-12-05 22:54         ` Paul Moore
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Smalley @ 2016-12-05 14:11 UTC (permalink / raw)
  To: Paul Moore; +Cc: selinux, guido, Richard Haines

On 12/02/2016 05:39 PM, Paul Moore wrote:
> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> I suppose a further question on this patch is whether it should also add
>> new classes for ICMP, IGMP, and SCTP sockets (any others that are
>> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be given their
>> own class?).  In the SCTP case, this would at least allow them to be
>> distinguished, but we would still lack the full support added by the
>> separate SCTP patchset.
> 
> For the record, I'm okay with this patch and I agree that the
> compatibility concerns aren't likely to be significant.  However, I
> would like to continue the discussion on the idea to include classes
> for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP, but
> considering the changes necessary for SCTP I think it is okay to leave
> SCTP out for now and add it in with proper SCTP support (and its own
> policy capability).
> 
> Stephen, I'm assuming you feel the same since you left that out of the patch?

It depends on whether we think full SCTP support will be merged sooner
or later.  If there is the possibility that full SCTP support will not
be merged for a while, then I think I'd rather just add a SCTP socket
class as part of this patch so that we can at least distinguish between
SCTP sockets and raw IP sockets in policy in the interim.

The other question is whether you agreed with Guido's suggested change
for readability/maintainability or prefer the current style. I have no
strong opinion either way.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-05 14:11       ` Stephen Smalley
@ 2016-12-05 22:54         ` Paul Moore
  2016-12-06 14:10           ` Richard Haines
  0 siblings, 1 reply; 19+ messages in thread
From: Paul Moore @ 2016-12-05 22:54 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: selinux, guido, Richard Haines

On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 12/02/2016 05:39 PM, Paul Moore wrote:
>> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> I suppose a further question on this patch is whether it should also add
>>> new classes for ICMP, IGMP, and SCTP sockets (any others that are
>>> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be given their
>>> own class?).  In the SCTP case, this would at least allow them to be
>>> distinguished, but we would still lack the full support added by the
>>> separate SCTP patchset.
>>
>> For the record, I'm okay with this patch and I agree that the
>> compatibility concerns aren't likely to be significant.  However, I
>> would like to continue the discussion on the idea to include classes
>> for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP, but
>> considering the changes necessary for SCTP I think it is okay to leave
>> SCTP out for now and add it in with proper SCTP support (and its own
>> policy capability).
>>
>> Stephen, I'm assuming you feel the same since you left that out of the patch?
>
> It depends on whether we think full SCTP support will be merged sooner
> or later.  If there is the possibility that full SCTP support will not
> be merged for a while, then I think I'd rather just add a SCTP socket
> class as part of this patch so that we can at least distinguish between
> SCTP sockets and raw IP sockets in policy in the interim.

As I sit here I would like to think that we'll get proper SCTP support
merged sooner rather than later, but well ... things happen.  I guess
there is no harm in adding the SCTP socket class now just in case.

> The other question is whether you agreed with Guido's suggested change
> for readability/maintainability or prefer the current style. I have no
> strong opinion either way.

I really don't care too much either way which is why I didn't comment
on it.  I suppose I have a slight preference for Guido's suggested
style, but I wouldn't respin the patch just for that.  However, if you
are going to add SCTP (which I'm guessing we should) go ahead and use
Guido's style.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-05 22:54         ` Paul Moore
@ 2016-12-06 14:10           ` Richard Haines
  2016-12-06 15:04             ` Stephen Smalley
  2016-12-07  0:06             ` Paul Moore
  0 siblings, 2 replies; 19+ messages in thread
From: Richard Haines @ 2016-12-06 14:10 UTC (permalink / raw)
  To: Paul Moore, Stephen Smalley; +Cc: selinux, guido

On Mon, 2016-12-05 at 17:54 -0500, Paul Moore wrote:
> On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On 12/02/2016 05:39 PM, Paul Moore wrote:
> > > On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.g
> > > ov> wrote:
> > > > I suppose a further question on this patch is whether it should
> > > > also add
> > > > new classes for ICMP, IGMP, and SCTP sockets (any others that
> > > > are
> > > > presently mapped to SECCLASS_RAWIP_SOCKET that ought to be
> > > > given their
> > > > own class?).  In the SCTP case, this would at least allow them
> > > > to be
> > > > distinguished, but we would still lack the full support added
> > > > by the
> > > > separate SCTP patchset.
> > > 
> > > For the record, I'm okay with this patch and I agree that the
> > > compatibility concerns aren't likely to be significant.  However,
> > > I
> > > would like to continue the discussion on the idea to include
> > > classes
> > > for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP,
> > > but
> > > considering the changes necessary for SCTP I think it is okay to
> > > leave
> > > SCTP out for now and add it in with proper SCTP support (and its
> > > own
> > > policy capability).
> > > 
> > > Stephen, I'm assuming you feel the same since you left that out
> > > of the patch?
> > 
> > It depends on whether we think full SCTP support will be merged
> > sooner
> > or later.  If there is the possibility that full SCTP support will
> > not
> > be merged for a while, then I think I'd rather just add a SCTP
> > socket
> > class as part of this patch so that we can at least distinguish
> > between
> > SCTP sockets and raw IP sockets in policy in the interim.
> 
> As I sit here I would like to think that we'll get proper SCTP
> support
> merged sooner rather than later, but well ... things happen.  I guess
> there is no harm in adding the SCTP socket class now just in case.
> 
> > The other question is whether you agreed with Guido's suggested
> > change
> > for readability/maintainability or prefer the current style. I have
> > no
> > strong opinion either way.
> 
> I really don't care too much either way which is why I didn't comment
> on it.  I suppose I have a slight preference for Guido's suggested
> style, but I wouldn't respin the patch just for that.  However, if
> you
> are going to add SCTP (which I'm guessing we should) go ahead and use
> Guido's style.

Not sure if helpful but I plan to submit the SCTP patch next week after
testing on Fedora 25 with kernel 4.8.11.

> 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-06 14:10           ` Richard Haines
@ 2016-12-06 15:04             ` Stephen Smalley
  2016-12-09 13:47               ` Stephen Smalley
  2016-12-07  0:06             ` Paul Moore
  1 sibling, 1 reply; 19+ messages in thread
From: Stephen Smalley @ 2016-12-06 15:04 UTC (permalink / raw)
  To: Richard Haines, Paul Moore; +Cc: selinux

On 12/06/2016 09:10 AM, Richard Haines wrote:
> On Mon, 2016-12-05 at 17:54 -0500, Paul Moore wrote:
>> On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>>> On 12/02/2016 05:39 PM, Paul Moore wrote:
>>>> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.g
>>>> ov> wrote:
>>>>> I suppose a further question on this patch is whether it should
>>>>> also add
>>>>> new classes for ICMP, IGMP, and SCTP sockets (any others that
>>>>> are
>>>>> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be
>>>>> given their
>>>>> own class?).  In the SCTP case, this would at least allow them
>>>>> to be
>>>>> distinguished, but we would still lack the full support added
>>>>> by the
>>>>> separate SCTP patchset.
>>>>
>>>> For the record, I'm okay with this patch and I agree that the
>>>> compatibility concerns aren't likely to be significant.  However,
>>>> I
>>>> would like to continue the discussion on the idea to include
>>>> classes
>>>> for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP,
>>>> but
>>>> considering the changes necessary for SCTP I think it is okay to
>>>> leave
>>>> SCTP out for now and add it in with proper SCTP support (and its
>>>> own
>>>> policy capability).
>>>>
>>>> Stephen, I'm assuming you feel the same since you left that out
>>>> of the patch?
>>>
>>> It depends on whether we think full SCTP support will be merged
>>> sooner
>>> or later.  If there is the possibility that full SCTP support will
>>> not
>>> be merged for a while, then I think I'd rather just add a SCTP
>>> socket
>>> class as part of this patch so that we can at least distinguish
>>> between
>>> SCTP sockets and raw IP sockets in policy in the interim.
>>
>> As I sit here I would like to think that we'll get proper SCTP
>> support
>> merged sooner rather than later, but well ... things happen.  I guess
>> there is no harm in adding the SCTP socket class now just in case.
>>
>>> The other question is whether you agreed with Guido's suggested
>>> change
>>> for readability/maintainability or prefer the current style. I have
>>> no
>>> strong opinion either way.
>>
>> I really don't care too much either way which is why I didn't comment
>> on it.  I suppose I have a slight preference for Guido's suggested
>> style, but I wouldn't respin the patch just for that.  However, if
>> you
>> are going to add SCTP (which I'm guessing we should) go ahead and use
>> Guido's style.
> 
> Not sure if helpful but I plan to submit the SCTP patch next week after
> testing on Fedora 25 with kernel 4.8.11.

I chose to go ahead and add the SCTP socket security class to this patch
so that we have all known socket classes defined by this patch, and then
your patch can further add new permissions and other logic specific to
SCTP under its own policy capability (at least I assume we'll want a
policy capability unless we aren't overly concerned with breaking SCTP
applications running under old policies with new kernels).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-06 14:10           ` Richard Haines
  2016-12-06 15:04             ` Stephen Smalley
@ 2016-12-07  0:06             ` Paul Moore
  1 sibling, 0 replies; 19+ messages in thread
From: Paul Moore @ 2016-12-07  0:06 UTC (permalink / raw)
  To: Richard Haines; +Cc: Stephen Smalley, selinux, guido

On Tue, Dec 6, 2016 at 9:10 AM, Richard Haines
<richard_c_haines@btinternet.com> wrote:
> On Mon, 2016-12-05 at 17:54 -0500, Paul Moore wrote:
>> On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@tycho.nsa.gov>
>> wrote:
>> > On 12/02/2016 05:39 PM, Paul Moore wrote:
>> > > On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.g
>> > > ov> wrote:
>> > > > I suppose a further question on this patch is whether it should
>> > > > also add
>> > > > new classes for ICMP, IGMP, and SCTP sockets (any others that
>> > > > are
>> > > > presently mapped to SECCLASS_RAWIP_SOCKET that ought to be
>> > > > given their
>> > > > own class?).  In the SCTP case, this would at least allow them
>> > > > to be
>> > > > distinguished, but we would still lack the full support added
>> > > > by the
>> > > > separate SCTP patchset.
>> > >
>> > > For the record, I'm okay with this patch and I agree that the
>> > > compatibility concerns aren't likely to be significant.  However,
>> > > I
>> > > would like to continue the discussion on the idea to include
>> > > classes
>> > > for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP,
>> > > but
>> > > considering the changes necessary for SCTP I think it is okay to
>> > > leave
>> > > SCTP out for now and add it in with proper SCTP support (and its
>> > > own
>> > > policy capability).
>> > >
>> > > Stephen, I'm assuming you feel the same since you left that out
>> > > of the patch?
>> >
>> > It depends on whether we think full SCTP support will be merged
>> > sooner
>> > or later.  If there is the possibility that full SCTP support will
>> > not
>> > be merged for a while, then I think I'd rather just add a SCTP
>> > socket
>> > class as part of this patch so that we can at least distinguish
>> > between
>> > SCTP sockets and raw IP sockets in policy in the interim.
>>
>> As I sit here I would like to think that we'll get proper SCTP
>> support
>> merged sooner rather than later, but well ... things happen.  I guess
>> there is no harm in adding the SCTP socket class now just in case.
>>
>> > The other question is whether you agreed with Guido's suggested
>> > change
>> > for readability/maintainability or prefer the current style. I have
>> > no
>> > strong opinion either way.
>>
>> I really don't care too much either way which is why I didn't comment
>> on it.  I suppose I have a slight preference for Guido's suggested
>> style, but I wouldn't respin the patch just for that.  However, if
>> you
>> are going to add SCTP (which I'm guessing we should) go ahead and use
>> Guido's style.
>
> Not sure if helpful but I plan to submit the SCTP patch next week after
> testing on Fedora 25 with kernel 4.8.11.

Great, thank you.  I promise to do a better job getting you prompt feedback.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-06 15:04             ` Stephen Smalley
@ 2016-12-09 13:47               ` Stephen Smalley
  2016-12-09 23:59                 ` Paul Moore
  0 siblings, 1 reply; 19+ messages in thread
From: Stephen Smalley @ 2016-12-09 13:47 UTC (permalink / raw)
  To: Richard Haines, Paul Moore; +Cc: selinux

On 12/06/2016 10:04 AM, Stephen Smalley wrote:
> On 12/06/2016 09:10 AM, Richard Haines wrote:
>> On Mon, 2016-12-05 at 17:54 -0500, Paul Moore wrote:
>>> On Mon, Dec 5, 2016 at 9:11 AM, Stephen Smalley <sds@tycho.nsa.gov>
>>> wrote:
>>>> On 12/02/2016 05:39 PM, Paul Moore wrote:
>>>>> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley <sds@tycho.nsa.g
>>>>> ov> wrote:
>>>>>> I suppose a further question on this patch is whether it should
>>>>>> also add
>>>>>> new classes for ICMP, IGMP, and SCTP sockets (any others that
>>>>>> are
>>>>>> presently mapped to SECCLASS_RAWIP_SOCKET that ought to be
>>>>>> given their
>>>>>> own class?).  In the SCTP case, this would at least allow them
>>>>>> to be
>>>>>> distinguished, but we would still lack the full support added
>>>>>> by the
>>>>>> separate SCTP patchset.
>>>>>
>>>>> For the record, I'm okay with this patch and I agree that the
>>>>> compatibility concerns aren't likely to be significant.  However,
>>>>> I
>>>>> would like to continue the discussion on the idea to include
>>>>> classes
>>>>> for ICMP, IGMP, and SCTP.  I haven't looked into ICMP or IGMP,
>>>>> but
>>>>> considering the changes necessary for SCTP I think it is okay to
>>>>> leave
>>>>> SCTP out for now and add it in with proper SCTP support (and its
>>>>> own
>>>>> policy capability).
>>>>>
>>>>> Stephen, I'm assuming you feel the same since you left that out
>>>>> of the patch?
>>>>
>>>> It depends on whether we think full SCTP support will be merged
>>>> sooner
>>>> or later.  If there is the possibility that full SCTP support will
>>>> not
>>>> be merged for a while, then I think I'd rather just add a SCTP
>>>> socket
>>>> class as part of this patch so that we can at least distinguish
>>>> between
>>>> SCTP sockets and raw IP sockets in policy in the interim.
>>>
>>> As I sit here I would like to think that we'll get proper SCTP
>>> support
>>> merged sooner rather than later, but well ... things happen.  I guess
>>> there is no harm in adding the SCTP socket class now just in case.
>>>
>>>> The other question is whether you agreed with Guido's suggested
>>>> change
>>>> for readability/maintainability or prefer the current style. I have
>>>> no
>>>> strong opinion either way.
>>>
>>> I really don't care too much either way which is why I didn't comment
>>> on it.  I suppose I have a slight preference for Guido's suggested
>>> style, but I wouldn't respin the patch just for that.  However, if
>>> you
>>> are going to add SCTP (which I'm guessing we should) go ahead and use
>>> Guido's style.
>>
>> Not sure if helpful but I plan to submit the SCTP patch next week after
>> testing on Fedora 25 with kernel 4.8.11.
> 
> I chose to go ahead and add the SCTP socket security class to this patch
> so that we have all known socket classes defined by this patch, and then
> your patch can further add new permissions and other logic specific to
> SCTP under its own policy capability (at least I assume we'll want a
> policy capability unless we aren't overly concerned with breaking SCTP
> applications running under old policies with new kernels).

Actually, perhaps we don't need another separate policy capability for
it if it goes in soon, since the extended_socket_class capability isn't
yet enabled in any policies.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC][PATCH] selinux: support distinctions among all network address families
  2016-12-09 13:47               ` Stephen Smalley
@ 2016-12-09 23:59                 ` Paul Moore
  0 siblings, 0 replies; 19+ messages in thread
From: Paul Moore @ 2016-12-09 23:59 UTC (permalink / raw)
  To: Stephen Smalley; +Cc: Richard Haines, selinux

On Fri, Dec 9, 2016 at 8:47 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 12/06/2016 10:04 AM, Stephen Smalley wrote:
>> On 12/06/2016 09:10 AM, Richard Haines wrote:
>>> Not sure if helpful but I plan to submit the SCTP patch next week after
>>> testing on Fedora 25 with kernel 4.8.11.
>>
>> I chose to go ahead and add the SCTP socket security class to this patch
>> so that we have all known socket classes defined by this patch, and then
>> your patch can further add new permissions and other logic specific to
>> SCTP under its own policy capability (at least I assume we'll want a
>> policy capability unless we aren't overly concerned with breaking SCTP
>> applications running under old policies with new kernels).
>
> Actually, perhaps we don't need another separate policy capability for
> it if it goes in soon, since the extended_socket_class capability isn't
> yet enabled in any policies.

True, we don't make any guarantees regarding code that hasn't been
released via Linus' tree and right now the extended socket class patch
is just sitting in the SELinux tree.  That said, I don't consider it
major problem to introduce another policy capability if needed; it's
definitely cleaner not to have to do so, but I wouldn't consider it
reason to rush the SCTP support if it isn't ready.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2016-12-09 23:59 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-01 15:07 [RFC][PATCH] selinux: support distinctions among all network address families Stephen Smalley
2016-12-01 15:57 ` Stephen Smalley
2016-12-01 16:26   ` Stephen Smalley
2016-12-01 17:28   ` Guido Trentalancia
2016-12-01 18:03     ` Stephen Smalley
2016-12-01 18:53       ` Stephen Smalley
2016-12-01 21:37         ` Guido Trentalancia
2016-12-01 20:42       ` Guido Trentalancia
2016-12-01 21:10         ` Stephen Smalley
2016-12-02 17:40   ` Stephen Smalley
2016-12-02 22:39     ` Paul Moore
2016-12-05 14:11       ` Stephen Smalley
2016-12-05 22:54         ` Paul Moore
2016-12-06 14:10           ` Richard Haines
2016-12-06 15:04             ` Stephen Smalley
2016-12-09 13:47               ` Stephen Smalley
2016-12-09 23:59                 ` Paul Moore
2016-12-07  0:06             ` Paul Moore
2016-12-01 17:04 ` Guido Trentalancia

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.