Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Paul Moore]

On Fri, Dec 9, 2016 at 8:47 AM, Stephen Smalley  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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Stephen Smalley]

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 
>>> wrote:
 On 12/02/2016 05:39 PM, Paul Moore wrote:
> On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley  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.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Paul Moore]

On Tue, Dec 6, 2016 at 9: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 
>> wrote:
>> > On 12/02/2016 05:39 PM, Paul Moore wrote:
>> > > On Fri, Dec 2, 2016 at 12:40 PM, Stephen Smalley > > > 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
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Stephen Smalley]

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).

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Stephen Smalley]

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.



testextsockclass.cil
Description: application/vnd.ms-artgalry
>From daaea4522b34a54c2cff319c458d7d1a0267ecbe Mon Sep 17 00:00:00 2001
From: Stephen Smalley 
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 
---
 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

___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Guido Trentalancia]

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 
> ---
>  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;
> + 

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Stephen Smalley]

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 
>> ---
>>  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;
>> +

Re: [RFC][PATCH] selinux: support distinctions among all network address families

[Stephen Smalley]

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 
> ---
>  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 

[RFC][PATCH] selinux: support distinctions among all network address families

[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 
---
 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 } },
+   {