[v2] Improve network_support.md

Commit Message

Topi Miettinen July 27, 2020, 1:04 p.m. UTC

List all access control methods available for networking and provide
examples for each.

Signed-off-by: Topi Miettinen <[e-mail]>

---
v2: address comments from Richard Haines
---
 src/network_statements.md |   2 +-
 src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
 2 files changed, 150 insertions(+), 22 deletions(-)

Comments

Dominick Grift July 27, 2020, 1:57 p.m. UTC | #1

Topi Miettinen <[e-mail]> writes:

> List all access control methods available for networking and provide
> examples for each.
>
> Signed-off-by: Topi Miettinen <[e-mail]>
>
> ---
> v2: address comments from Richard Haines
> ---
>  src/network_statements.md |   2 +-
>  src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>  2 files changed, 150 insertions(+), 22 deletions(-)
>
> diff --git a/src/network_statements.md b/src/network_statements.md
> index ef1c873..357c3b1 100644
> --- a/src/network_statements.md
> +++ b/src/network_statements.md
> @@ -102,7 +102,7 @@ the interface to a security context.
>  <tr>
>  <td><code>packet_context</code></td>
>  <td><p>The security context allocated packets. Note that these are defined but unused.</p>
> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
> +<p>The iptables(8)/nftables(8) <a
> href="network_support.md#internal-labeling-secmark">SECMARK
> services</a> should be used to label packets.</p></td>
>  </tr>
>  </tbody>
>  </table>
> diff --git a/src/network_support.md b/src/network_support.md
> index 309e863..6f9896b 100644
> --- a/src/network_support.md
> +++ b/src/network_support.md
> @@ -1,20 +1,17 @@
>  # SELinux Networking Support
>  
> -SELinux supports the following types of network labeling:
> +SELinux supports several methods for access control of networks. These are
>  
> -**Internal labeling** - This is where network objects are labeled and
> -managed internally within a single machine (i.e. their labels are not
> -transmitted as part of the session with remote systems). There are two
> -types supported: SECMARK and NetLabel. There was a service known as
> -'compat_net' controls, however that was removed in kernel 2.6.30.
> +* Packet labeling: class `packet`
> +* Peer labeling: class `peer`
> +* Interface control: class `netif`
> +* Network node control: class `node`
> +* TCP/UDP/SCTP/DCCP ports: class `port`
>  
> -**Labeled Networking** - This is where labels are passed to/from remote
> -systems where they can be interpreted and a MAC policy enforced on each
> -system. There are three types supported: Labeled IPSec, CIPSO
> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
> -IPv6 Security Option)
> +Networking support is not enabled by default. It can be enabled either
> +the policy capabilities or by loading SECMARK rules.
>  
> -There are two policy capability options that can be set within policy
> +There are three policy capability options that can be set within policy
>  using the `policycap` statement that affect networking configuration:
>  
>  **`network_peer_controls`** - This is always enabled in the latest
> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>  SELinux filesystem as shown in the
>  [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>  
> -To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
> -be installed:
> +SELinux supports the following types of network labeling:
> +
> +**Internal labeling** - This is where network objects are labeled and
> +managed internally within a single machine (i.e. their labels are not
> +transmitted as part of the session with remote systems). There are two
> +types supported: SECMARK and NetLabel. There was a service known as
> +'compat_net' controls, however that was removed in kernel 2.6.30.
> +
> +**Labeled Networking** - This is where labels are passed to/from remote
> +systems where they can be interpreted and a MAC policy enforced on each
> +system. There are three types supported: Labeled IPSec, CIPSO
> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
> +IPv6 Security Option).
> +
> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
> +the NetLabel tools need to be installed:
>  
>  `dnf install netlabel_tools`
>  
> @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>  `dnf install libreswan`
>  
>  It is important to note that the kernel must be configured to support
> -these services. The Fedora kernels are configured to handle all the above
> -services.
> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
> +`CONFIG_NF_CONNTRACK_SECMARK`,
> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
> +configured to handle all the above services.
>  
>  The Linux networking package *iproute* has an SELinux aware socket
>  statistics command ***ss**(8)* that will show the SELinux context of
> @@ -65,7 +80,7 @@ to achieve this).
>  
>  <br>
>  
> -## SECMARK
> +## Internal labeling: SECMARK
>  
>  SECMARK makes use of the standard kernel NetFilter framework that
>  underpins the GNU / Linux IP networking sub-system. NetFilter services
> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>  controls on interfaces, IP addresses (nodes) and ports with the added
>  advantage of connection tracking. The SECMARK security extensions allow
>  security contexts to be added to packets (SECMARK) or sessions
> -(CONNSECMARK).
> +(CONNSECMARK), belonging to object class of `packet`.
>  
>  The NetFilter framework inspects and tag packets with labels as defined
>  within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
> @@ -172,6 +187,16 @@ table ip6 security {
>  }
>  ```
>  
> +Before the SECMARK rules can be loaded, TE rules must be added to
> +define the types, and also allow domains to send and/or receive
> +objects of `packet` class:
> +
> +```
> +type test_server_packet_t, packet_type;
> +
> +allow my_server_t test_server_packet_t:packet { send recv };
> +```
> +
>  The following articles explain the SECMARK service:
>  -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>  -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>  
>  <br>
>  
> -## NetLabel - Fallback Peer Labeling
> +## Internal labeling: NetLabel - Fallback Peer Labeling
>  
>  Fallback labeling can optionally be implemented on a system if the
>  Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
> @@ -217,9 +242,20 @@ netlabelctl -p map list
>  Note that the security contexts must be valid in the policy otherwise the
>  commands will fail.
>  
> +Before the NetLabel rules can be loaded, TE rules must be added to
> +define the types. Then the rules can allow domains to receive data
> +from objects of `peer` class:
> +
> +```
> +type netlabel_sctp_peer_t;
> +
> +allow my_server_t netlabel_sctp_peer_t:peer recv;
> +```
> +Note that sending can't be controlled with `peer` class.
> +
>  <br>
>  
> -## NetLabel – CIPSO/CALIPSO
> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>  
>  To allow MLS [**security levels**](mls_mcs.md#security-levels) to be passed
>  over a network between MLS
> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>  
>  <br>
>  
> -## Labeled IPSec
> +## Labeled Networking: Labeled IPSec
>  
>  Labeled IPSec has been built into the standard GNU / Linux IPSec
>  services as described in the
> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>  
>  <br>
>  
> +## Access Control for Network Interfaces
> +
> +SELinux domains can be restricted to use only specific network
> +interfaces. TE rules must define the interface types and then allow a
> +domain to `egress` in class `netif` for the defined interface types:
> +
> +```
> +require {
> +        attribute netif_type;
> +}
> +
> +type external_if_t, netif_type;
> +type loopback_if_t, netif_type;
> +
> +allow my_server_t external_if_t:netif egress;
> +allow my_server_t loopback_if_t:netif egress;
> +```
> +
> +The interfaces must also be labeled with ***semanage**(8)* (or by
> +using `netifcon` statements in the policy):
> +```
> +semanage interface -a -t loopback_if_t -r s0 lo
> +semanage interface -a -t external_if_t -r s0 eth0
> +```
> +
> +Note that reception can't be controlled with `netif` class.

Probably nothing but I did not understand this: Is reception not
controlled with the netif ingress permission?

> +
> +<br>
> +
> +## Access Control for Network Nodes
> +
> +Domains can be restricted by SELinux to access and bind sockets to
> +only dedicated network nodes (in practice, IP addresses).
> +
> +The node types must be defined and then the node types can be used for
> +TE rules as target context. TE rules to allow a domain to `sendto` for
> +class `node` and to `node_bind` (for incoming connections) for class
> +`tcp_socket`:
> +
> +```
> +require {
> +        attribute node_type;
> +}
> +
> +type loopback_node_t, node_type;
> +type internet_node_t, node_type;
> +type link_local_node_t, node_type;
> +type multicast_node_t, node_type;
> +
> +allow my_server_t loopback_node_t:node sendto;
> +allow my_server_t loopback_node_t:tcp_socket node_bind;
> +allow my_server_t internet_node_t:node sendto;
> +```
> +
> +After the types have been defined, corresponding node rules can be
> +added with `semanage` (or `nodecon` statements):
> +```
> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
> +```
> +
> +<br>
> +
> +## Access Control for Network Ports
> +
> +SELinux policy can also control access to ports used by various
> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
> +define the port types and then allow a domain to `name_connect`
> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
> +`udp_socket` etc) for the defined port types:
> +
> +```
> +require {
> +        attribute port_type;
> +}
> +
> +type my_server_port_t, port_type;
> +
> +allow my_server_t my_server_port_t:tcp_socket name_connect;
> +allow my_server_t my_server_port_t:tcp_socket name_bind;
> +```
> +
> +The ports must also be labeled with `semanage` (or `portcon`
> +statements):
> +```
> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
> +```
> +
> +<br>
> +
>  <section class="footnotes">
>  <ol>
>  <li id="fnn1"><p>For example, an ftp session where the server is
> listening on a specific port (the destination port) but the client
> will be assigned a random source port. The CONNSECMARK will ensure
> that all packets for the ftp session are marked with the same label.<a
> href="#fnnet1" class="footnote-back">↩</a></p></li>

Topi Miettinen July 27, 2020, 3:21 p.m. UTC | #2

On 27.7.2020 16.57, Dominick Grift wrote:
> Topi Miettinen <[e-mail]> writes:
> 
>> List all access control methods available for networking and provide
>> examples for each.
>>
>> Signed-off-by: Topi Miettinen <[e-mail]>
>>
>> ---
>> v2: address comments from Richard Haines
>> ---
>>   src/network_statements.md |   2 +-
>>   src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>   2 files changed, 150 insertions(+), 22 deletions(-)
>>
>> diff --git a/src/network_statements.md b/src/network_statements.md
>> index ef1c873..357c3b1 100644
>> --- a/src/network_statements.md
>> +++ b/src/network_statements.md
>> @@ -102,7 +102,7 @@ the interface to a security context.
>>   <tr>
>>   <td><code>packet_context</code></td>
>>   <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>> +<p>The iptables(8)/nftables(8) <a
>> href="network_support.md#internal-labeling-secmark">SECMARK
>> services</a> should be used to label packets.</p></td>
>>   </tr>
>>   </tbody>
>>   </table>
>> diff --git a/src/network_support.md b/src/network_support.md
>> index 309e863..6f9896b 100644
>> --- a/src/network_support.md
>> +++ b/src/network_support.md
>> @@ -1,20 +1,17 @@
>>   # SELinux Networking Support
>>   
>> -SELinux supports the following types of network labeling:
>> +SELinux supports several methods for access control of networks. These are
>>   
>> -**Internal labeling** - This is where network objects are labeled and
>> -managed internally within a single machine (i.e. their labels are not
>> -transmitted as part of the session with remote systems). There are two
>> -types supported: SECMARK and NetLabel. There was a service known as
>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>> +* Packet labeling: class `packet`
>> +* Peer labeling: class `peer`
>> +* Interface control: class `netif`
>> +* Network node control: class `node`
>> +* TCP/UDP/SCTP/DCCP ports: class `port`
>>   
>> -**Labeled Networking** - This is where labels are passed to/from remote
>> -systems where they can be interpreted and a MAC policy enforced on each
>> -system. There are three types supported: Labeled IPSec, CIPSO
>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>> -IPv6 Security Option)
>> +Networking support is not enabled by default. It can be enabled either
>> +the policy capabilities or by loading SECMARK rules.
>>   
>> -There are two policy capability options that can be set within policy
>> +There are three policy capability options that can be set within policy
>>   using the `policycap` statement that affect networking configuration:
>>   
>>   **`network_peer_controls`** - This is always enabled in the latest
>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>   SELinux filesystem as shown in the
>>   [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>   
>> -To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
>> -be installed:
>> +SELinux supports the following types of network labeling:
>> +
>> +**Internal labeling** - This is where network objects are labeled and
>> +managed internally within a single machine (i.e. their labels are not
>> +transmitted as part of the session with remote systems). There are two
>> +types supported: SECMARK and NetLabel. There was a service known as
>> +'compat_net' controls, however that was removed in kernel 2.6.30.
>> +
>> +**Labeled Networking** - This is where labels are passed to/from remote
>> +systems where they can be interpreted and a MAC policy enforced on each
>> +system. There are three types supported: Labeled IPSec, CIPSO
>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>> +IPv6 Security Option).
>> +
>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>> +the NetLabel tools need to be installed:
>>   
>>   `dnf install netlabel_tools`
>>   
>> @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>>   `dnf install libreswan`
>>   
>>   It is important to note that the kernel must be configured to support
>> -these services. The Fedora kernels are configured to handle all the above
>> -services.
>> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
>> +`CONFIG_NF_CONNTRACK_SECMARK`,
>> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
>> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
>> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
>> +configured to handle all the above services.
>>   
>>   The Linux networking package *iproute* has an SELinux aware socket
>>   statistics command ***ss**(8)* that will show the SELinux context of
>> @@ -65,7 +80,7 @@ to achieve this).
>>   
>>   <br>
>>   
>> -## SECMARK
>> +## Internal labeling: SECMARK
>>   
>>   SECMARK makes use of the standard kernel NetFilter framework that
>>   underpins the GNU / Linux IP networking sub-system. NetFilter services
>> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>>   controls on interfaces, IP addresses (nodes) and ports with the added
>>   advantage of connection tracking. The SECMARK security extensions allow
>>   security contexts to be added to packets (SECMARK) or sessions
>> -(CONNSECMARK).
>> +(CONNSECMARK), belonging to object class of `packet`.
>>   
>>   The NetFilter framework inspects and tag packets with labels as defined
>>   within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
>> @@ -172,6 +187,16 @@ table ip6 security {
>>   }
>>   ```
>>   
>> +Before the SECMARK rules can be loaded, TE rules must be added to
>> +define the types, and also allow domains to send and/or receive
>> +objects of `packet` class:
>> +
>> +```
>> +type test_server_packet_t, packet_type;
>> +
>> +allow my_server_t test_server_packet_t:packet { send recv };
>> +```
>> +
>>   The following articles explain the SECMARK service:
>>   -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>>   -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
>> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>>   
>>   <br>
>>   
>> -## NetLabel - Fallback Peer Labeling
>> +## Internal labeling: NetLabel - Fallback Peer Labeling
>>   
>>   Fallback labeling can optionally be implemented on a system if the
>>   Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
>> @@ -217,9 +242,20 @@ netlabelctl -p map list
>>   Note that the security contexts must be valid in the policy otherwise the
>>   commands will fail.
>>   
>> +Before the NetLabel rules can be loaded, TE rules must be added to
>> +define the types. Then the rules can allow domains to receive data
>> +from objects of `peer` class:
>> +
>> +```
>> +type netlabel_sctp_peer_t;
>> +
>> +allow my_server_t netlabel_sctp_peer_t:peer recv;
>> +```
>> +Note that sending can't be controlled with `peer` class.
>> +
>>   <br>
>>   
>> -## NetLabel – CIPSO/CALIPSO
>> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>>   
>>   To allow MLS [**security levels**](mls_mcs.md#security-levels) to be passed
>>   over a network between MLS
>> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>>   
>>   <br>
>>   
>> -## Labeled IPSec
>> +## Labeled Networking: Labeled IPSec
>>   
>>   Labeled IPSec has been built into the standard GNU / Linux IPSec
>>   services as described in the
>> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>>   
>>   <br>
>>   
>> +## Access Control for Network Interfaces
>> +
>> +SELinux domains can be restricted to use only specific network
>> +interfaces. TE rules must define the interface types and then allow a
>> +domain to `egress` in class `netif` for the defined interface types:
>> +
>> +```
>> +require {
>> +        attribute netif_type;
>> +}
>> +
>> +type external_if_t, netif_type;
>> +type loopback_if_t, netif_type;
>> +
>> +allow my_server_t external_if_t:netif egress;
>> +allow my_server_t loopback_if_t:netif egress;
>> +```
>> +
>> +The interfaces must also be labeled with ***semanage**(8)* (or by
>> +using `netifcon` statements in the policy):
>> +```
>> +semanage interface -a -t loopback_if_t -r s0 lo
>> +semanage interface -a -t external_if_t -r s0 eth0
>> +```
>> +
>> +Note that reception can't be controlled with `netif` class.
> 
> Probably nothing but I did not understand this: Is reception not
> controlled with the netif ingress permission?

I'm no expert, but the only netif ingress rules which I have are rather 
generic:

allow internet_peer_t external_if_t:netif ingress;
allow link_local_peer_t external_if_t:netif ingress;
allow localnet_peer_t external_if_t:netif ingress;
allow multicast_peer_t external_if_t:netif ingress;
allow loopback_peer_t loopback_if_t:netif ingress;

`peer` types above have been added with NetLabel rules like:

netlabelctl unlbl add default address:2000::/3 
label:system_u:object_r:internet_peer_t:s0

Perhaps this would be better:

Note that reception for application domains can't be controlled with 
`netif` class.

> 
>> +
>> +<br>
>> +
>> +## Access Control for Network Nodes
>> +
>> +Domains can be restricted by SELinux to access and bind sockets to
>> +only dedicated network nodes (in practice, IP addresses).
>> +
>> +The node types must be defined and then the node types can be used for
>> +TE rules as target context. TE rules to allow a domain to `sendto` for
>> +class `node` and to `node_bind` (for incoming connections) for class
>> +`tcp_socket`:
>> +
>> +```
>> +require {
>> +        attribute node_type;
>> +}
>> +
>> +type loopback_node_t, node_type;
>> +type internet_node_t, node_type;
>> +type link_local_node_t, node_type;
>> +type multicast_node_t, node_type;
>> +
>> +allow my_server_t loopback_node_t:node sendto;
>> +allow my_server_t loopback_node_t:tcp_socket node_bind;
>> +allow my_server_t internet_node_t:node sendto;
>> +```
>> +
>> +After the types have been defined, corresponding node rules can be
>> +added with `semanage` (or `nodecon` statements):
>> +```
>> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
>> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
>> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
>> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
>> +```
>> +
>> +<br>
>> +
>> +## Access Control for Network Ports
>> +
>> +SELinux policy can also control access to ports used by various
>> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
>> +define the port types and then allow a domain to `name_connect`
>> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
>> +`udp_socket` etc) for the defined port types:
>> +
>> +```
>> +require {
>> +        attribute port_type;
>> +}
>> +
>> +type my_server_port_t, port_type;
>> +
>> +allow my_server_t my_server_port_t:tcp_socket name_connect;
>> +allow my_server_t my_server_port_t:tcp_socket name_bind;
>> +```
>> +
>> +The ports must also be labeled with `semanage` (or `portcon`
>> +statements):
>> +```
>> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
>> +```
>> +
>> +<br>
>> +
>>   <section class="footnotes">
>>   <ol>
>>   <li id="fnn1"><p>For example, an ftp session where the server is
>> listening on a specific port (the destination port) but the client
>> will be assigned a random source port. The CONNSECMARK will ensure
>> that all packets for the ftp session are marked with the same label.<a
>> href="#fnnet1" class="footnote-back">↩</a></p></li>
>

Dominick Grift July 27, 2020, 3:39 p.m. UTC | #3

Topi Miettinen <[e-mail]> writes:

> On 27.7.2020 16.57, Dominick Grift wrote:
>> Topi Miettinen <[e-mail]> writes:
>>
>>> List all access control methods available for networking and provide
>>> examples for each.
>>>
>>> Signed-off-by: Topi Miettinen <[e-mail]>
>>>
>>> ---
>>> v2: address comments from Richard Haines
>>> ---
>>>   src/network_statements.md |   2 +-
>>>   src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>>   2 files changed, 150 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/src/network_statements.md b/src/network_statements.md
>>> index ef1c873..357c3b1 100644
>>> --- a/src/network_statements.md
>>> +++ b/src/network_statements.md
>>> @@ -102,7 +102,7 @@ the interface to a security context.
>>>   <tr>
>>>   <td><code>packet_context</code></td>
>>>   <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>>> +<p>The iptables(8)/nftables(8) <a
>>> href="network_support.md#internal-labeling-secmark">SECMARK
>>> services</a> should be used to label packets.</p></td>
>>>   </tr>
>>>   </tbody>
>>>   </table>
>>> diff --git a/src/network_support.md b/src/network_support.md
>>> index 309e863..6f9896b 100644
>>> --- a/src/network_support.md
>>> +++ b/src/network_support.md
>>> @@ -1,20 +1,17 @@
>>>   # SELinux Networking Support
>>>   -SELinux supports the following types of network labeling:
>>> +SELinux supports several methods for access control of networks. These are
>>>   -**Internal labeling** - This is where network objects are
>>> labeled and
>>> -managed internally within a single machine (i.e. their labels are not
>>> -transmitted as part of the session with remote systems). There are two
>>> -types supported: SECMARK and NetLabel. There was a service known as
>>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>>> +* Packet labeling: class `packet`
>>> +* Peer labeling: class `peer`
>>> +* Interface control: class `netif`
>>> +* Network node control: class `node`
>>> +* TCP/UDP/SCTP/DCCP ports: class `port`
>>>   -**Labeled Networking** - This is where labels are passed to/from
>>> remote
>>> -systems where they can be interpreted and a MAC policy enforced on each
>>> -system. There are three types supported: Labeled IPSec, CIPSO
>>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>> -IPv6 Security Option)
>>> +Networking support is not enabled by default. It can be enabled either
>>> +the policy capabilities or by loading SECMARK rules.
>>>   -There are two policy capability options that can be set within
>>> policy
>>> +There are three policy capability options that can be set within policy
>>>   using the `policycap` statement that affect networking configuration:
>>>     **`network_peer_controls`** - This is always enabled in the
>>> latest
>>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>>   SELinux filesystem as shown in the
>>>   [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>>   -To support peer labeling, CIPSO and CALIPSO the NetLabel tools
>>> need to
>>> -be installed:
>>> +SELinux supports the following types of network labeling:
>>> +
>>> +**Internal labeling** - This is where network objects are labeled and
>>> +managed internally within a single machine (i.e. their labels are not
>>> +transmitted as part of the session with remote systems). There are two
>>> +types supported: SECMARK and NetLabel. There was a service known as
>>> +'compat_net' controls, however that was removed in kernel 2.6.30.
>>> +
>>> +**Labeled Networking** - This is where labels are passed to/from remote
>>> +systems where they can be interpreted and a MAC policy enforced on each
>>> +system. There are three types supported: Labeled IPSec, CIPSO
>>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>> +IPv6 Security Option).
>>> +
>>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>>> +the NetLabel tools need to be installed:
>>>     `dnf install netlabel_tools`
>>>   @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>>>   `dnf install libreswan`
>>>     It is important to note that the kernel must be configured to
>>> support
>>> -these services. The Fedora kernels are configured to handle all the above
>>> -services.
>>> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
>>> +`CONFIG_NF_CONNTRACK_SECMARK`,
>>> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
>>> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
>>> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
>>> +configured to handle all the above services.
>>>     The Linux networking package *iproute* has an SELinux aware
>>> socket
>>>   statistics command ***ss**(8)* that will show the SELinux context of
>>> @@ -65,7 +80,7 @@ to achieve this).
>>>     <br>
>>>   -## SECMARK
>>> +## Internal labeling: SECMARK
>>>     SECMARK makes use of the standard kernel NetFilter framework
>>> that
>>>   underpins the GNU / Linux IP networking sub-system. NetFilter services
>>> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>>>   controls on interfaces, IP addresses (nodes) and ports with the added
>>>   advantage of connection tracking. The SECMARK security extensions allow
>>>   security contexts to be added to packets (SECMARK) or sessions
>>> -(CONNSECMARK).
>>> +(CONNSECMARK), belonging to object class of `packet`.
>>>     The NetFilter framework inspects and tag packets with labels as
>>> defined
>>>   within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
>>> @@ -172,6 +187,16 @@ table ip6 security {
>>>   }
>>>   ```
>>>   +Before the SECMARK rules can be loaded, TE rules must be added
>>> to
>>> +define the types, and also allow domains to send and/or receive
>>> +objects of `packet` class:
>>> +
>>> +```
>>> +type test_server_packet_t, packet_type;
>>> +
>>> +allow my_server_t test_server_packet_t:packet { send recv };
>>> +```
>>> +
>>>   The following articles explain the SECMARK service:
>>>   -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>>>   -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
>>> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>>>     <br>
>>>   -## NetLabel - Fallback Peer Labeling
>>> +## Internal labeling: NetLabel - Fallback Peer Labeling
>>>     Fallback labeling can optionally be implemented on a system if
>>> the
>>>   Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
>>> @@ -217,9 +242,20 @@ netlabelctl -p map list
>>>   Note that the security contexts must be valid in the policy otherwise the
>>>   commands will fail.
>>>   +Before the NetLabel rules can be loaded, TE rules must be added
>>> to
>>> +define the types. Then the rules can allow domains to receive data
>>> +from objects of `peer` class:
>>> +
>>> +```
>>> +type netlabel_sctp_peer_t;
>>> +
>>> +allow my_server_t netlabel_sctp_peer_t:peer recv;
>>> +```
>>> +Note that sending can't be controlled with `peer` class.
>>> +
>>>   <br>
>>>   -## NetLabel – CIPSO/CALIPSO
>>> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>>>     To allow MLS [**security levels**](mls_mcs.md#security-levels)
>>> to be passed
>>>   over a network between MLS
>>> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>>>     <br>
>>>   -## Labeled IPSec
>>> +## Labeled Networking: Labeled IPSec
>>>     Labeled IPSec has been built into the standard GNU / Linux
>>> IPSec
>>>   services as described in the
>>> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>>>     <br>
>>>   +## Access Control for Network Interfaces
>>> +
>>> +SELinux domains can be restricted to use only specific network
>>> +interfaces. TE rules must define the interface types and then allow a
>>> +domain to `egress` in class `netif` for the defined interface types:
>>> +
>>> +```
>>> +require {
>>> +        attribute netif_type;
>>> +}
>>> +
>>> +type external_if_t, netif_type;
>>> +type loopback_if_t, netif_type;
>>> +
>>> +allow my_server_t external_if_t:netif egress;
>>> +allow my_server_t loopback_if_t:netif egress;
>>> +```
>>> +
>>> +The interfaces must also be labeled with ***semanage**(8)* (or by
>>> +using `netifcon` statements in the policy):
>>> +```
>>> +semanage interface -a -t loopback_if_t -r s0 lo
>>> +semanage interface -a -t external_if_t -r s0 eth0
>>> +```
>>> +
>>> +Note that reception can't be controlled with `netif` class.
>>
>> Probably nothing but I did not understand this: Is reception not
>> controlled with the netif ingress permission?
>
> I'm no expert, but the only netif ingress rules which I have are
> rather generic:
>
> allow internet_peer_t external_if_t:netif ingress;
> allow link_local_peer_t external_if_t:netif ingress;
> allow localnet_peer_t external_if_t:netif ingress;
> allow multicast_peer_t external_if_t:netif ingress;
> allow loopback_peer_t loopback_if_t:netif ingress;
>
> `peer` types above have been added with NetLabel rules like:
>
> netlabelctl unlbl add default address:2000::/3
> label:system_u:object_r:internet_peer_t:s0
>
> Perhaps this would be better:
>
> Note that reception for application domains can't be controlled with
> `netif` class.
>

I look at it this way: peers *are* processes, You seem to
essentually use peers as nodes above.

It would become more clear if you would try this out with labeled ipsec.
A peer, in my experience is kind of the same as an association in the
labeled ipsec scenario (the classes actually overlap). That is also why
you should probably disable the netlabel_peer_controls polcap if you use
labeled ipsec.

>>
>>> +
>>> +<br>
>>> +
>>> +## Access Control for Network Nodes
>>> +
>>> +Domains can be restricted by SELinux to access and bind sockets to
>>> +only dedicated network nodes (in practice, IP addresses).
>>> +
>>> +The node types must be defined and then the node types can be used for
>>> +TE rules as target context. TE rules to allow a domain to `sendto` for
>>> +class `node` and to `node_bind` (for incoming connections) for class
>>> +`tcp_socket`:
>>> +
>>> +```
>>> +require {
>>> +        attribute node_type;
>>> +}
>>> +
>>> +type loopback_node_t, node_type;
>>> +type internet_node_t, node_type;
>>> +type link_local_node_t, node_type;
>>> +type multicast_node_t, node_type;
>>> +
>>> +allow my_server_t loopback_node_t:node sendto;
>>> +allow my_server_t loopback_node_t:tcp_socket node_bind;
>>> +allow my_server_t internet_node_t:node sendto;
>>> +```
>>> +
>>> +After the types have been defined, corresponding node rules can be
>>> +added with `semanage` (or `nodecon` statements):
>>> +```
>>> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
>>> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
>>> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
>>> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
>>> +```
>>> +
>>> +<br>
>>> +
>>> +## Access Control for Network Ports
>>> +
>>> +SELinux policy can also control access to ports used by various
>>> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
>>> +define the port types and then allow a domain to `name_connect`
>>> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
>>> +`udp_socket` etc) for the defined port types:
>>> +
>>> +```
>>> +require {
>>> +        attribute port_type;
>>> +}
>>> +
>>> +type my_server_port_t, port_type;
>>> +
>>> +allow my_server_t my_server_port_t:tcp_socket name_connect;
>>> +allow my_server_t my_server_port_t:tcp_socket name_bind;
>>> +```
>>> +
>>> +The ports must also be labeled with `semanage` (or `portcon`
>>> +statements):
>>> +```
>>> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
>>> +```
>>> +
>>> +<br>
>>> +
>>>   <section class="footnotes">
>>>   <ol>
>>>   <li id="fnn1"><p>For example, an ftp session where the server is
>>> listening on a specific port (the destination port) but the client
>>> will be assigned a random source port. The CONNSECMARK will ensure
>>> that all packets for the ftp session are marked with the same label.<a
>>> href="#fnnet1" class="footnote-back">↩</a></p></li>
>>
>

Topi Miettinen July 27, 2020, 8:20 p.m. UTC | #4

On 27.7.2020 18.39, Dominick Grift wrote:
> Topi Miettinen <[e-mail]> writes:
> 
>> On 27.7.2020 16.57, Dominick Grift wrote:
>>> Topi Miettinen <[e-mail]> writes:
>>>
>>>> List all access control methods available for networking and provide
>>>> examples for each.
>>>>
>>>> Signed-off-by: Topi Miettinen <[e-mail]>
>>>>
>>>> ---
>>>> v2: address comments from Richard Haines
>>>> ---
>>>>    src/network_statements.md |   2 +-
>>>>    src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>>>    2 files changed, 150 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/src/network_statements.md b/src/network_statements.md
>>>> index ef1c873..357c3b1 100644
>>>> --- a/src/network_statements.md
>>>> +++ b/src/network_statements.md
>>>> @@ -102,7 +102,7 @@ the interface to a security context.
>>>>    <tr>
>>>>    <td><code>packet_context</code></td>
>>>>    <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>>>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>>>> +<p>The iptables(8)/nftables(8) <a
>>>> href="network_support.md#internal-labeling-secmark">SECMARK
>>>> services</a> should be used to label packets.</p></td>
>>>>    </tr>
>>>>    </tbody>
>>>>    </table>
>>>> diff --git a/src/network_support.md b/src/network_support.md
>>>> index 309e863..6f9896b 100644
>>>> --- a/src/network_support.md
>>>> +++ b/src/network_support.md
>>>> @@ -1,20 +1,17 @@
>>>>    # SELinux Networking Support
>>>>    -SELinux supports the following types of network labeling:
>>>> +SELinux supports several methods for access control of networks. These are
>>>>    -**Internal labeling** - This is where network objects are
>>>> labeled and
>>>> -managed internally within a single machine (i.e. their labels are not
>>>> -transmitted as part of the session with remote systems). There are two
>>>> -types supported: SECMARK and NetLabel. There was a service known as
>>>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>>>> +* Packet labeling: class `packet`
>>>> +* Peer labeling: class `peer`
>>>> +* Interface control: class `netif`
>>>> +* Network node control: class `node`
>>>> +* TCP/UDP/SCTP/DCCP ports: class `port`
>>>>    -**Labeled Networking** - This is where labels are passed to/from
>>>> remote
>>>> -systems where they can be interpreted and a MAC policy enforced on each
>>>> -system. There are three types supported: Labeled IPSec, CIPSO
>>>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>> -IPv6 Security Option)
>>>> +Networking support is not enabled by default. It can be enabled either
>>>> +the policy capabilities or by loading SECMARK rules.
>>>>    -There are two policy capability options that can be set within
>>>> policy
>>>> +There are three policy capability options that can be set within policy
>>>>    using the `policycap` statement that affect networking configuration:
>>>>      **`network_peer_controls`** - This is always enabled in the
>>>> latest
>>>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>>>    SELinux filesystem as shown in the
>>>>    [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>>>    -To support peer labeling, CIPSO and CALIPSO the NetLabel tools
>>>> need to
>>>> -be installed:
>>>> +SELinux supports the following types of network labeling:
>>>> +
>>>> +**Internal labeling** - This is where network objects are labeled and
>>>> +managed internally within a single machine (i.e. their labels are not
>>>> +transmitted as part of the session with remote systems). There are two
>>>> +types supported: SECMARK and NetLabel. There was a service known as
>>>> +'compat_net' controls, however that was removed in kernel 2.6.30.
>>>> +
>>>> +**Labeled Networking** - This is where labels are passed to/from remote
>>>> +systems where they can be interpreted and a MAC policy enforced on each
>>>> +system. There are three types supported: Labeled IPSec, CIPSO
>>>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>> +IPv6 Security Option).
>>>> +
>>>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>>>> +the NetLabel tools need to be installed:
>>>>      `dnf install netlabel_tools`
>>>>    @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>>>>    `dnf install libreswan`
>>>>      It is important to note that the kernel must be configured to
>>>> support
>>>> -these services. The Fedora kernels are configured to handle all the above
>>>> -services.
>>>> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
>>>> +`CONFIG_NF_CONNTRACK_SECMARK`,
>>>> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
>>>> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
>>>> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
>>>> +configured to handle all the above services.
>>>>      The Linux networking package *iproute* has an SELinux aware
>>>> socket
>>>>    statistics command ***ss**(8)* that will show the SELinux context of
>>>> @@ -65,7 +80,7 @@ to achieve this).
>>>>      <br>
>>>>    -## SECMARK
>>>> +## Internal labeling: SECMARK
>>>>      SECMARK makes use of the standard kernel NetFilter framework
>>>> that
>>>>    underpins the GNU / Linux IP networking sub-system. NetFilter services
>>>> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>>>>    controls on interfaces, IP addresses (nodes) and ports with the added
>>>>    advantage of connection tracking. The SECMARK security extensions allow
>>>>    security contexts to be added to packets (SECMARK) or sessions
>>>> -(CONNSECMARK).
>>>> +(CONNSECMARK), belonging to object class of `packet`.
>>>>      The NetFilter framework inspects and tag packets with labels as
>>>> defined
>>>>    within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
>>>> @@ -172,6 +187,16 @@ table ip6 security {
>>>>    }
>>>>    ```
>>>>    +Before the SECMARK rules can be loaded, TE rules must be added
>>>> to
>>>> +define the types, and also allow domains to send and/or receive
>>>> +objects of `packet` class:
>>>> +
>>>> +```
>>>> +type test_server_packet_t, packet_type;
>>>> +
>>>> +allow my_server_t test_server_packet_t:packet { send recv };
>>>> +```
>>>> +
>>>>    The following articles explain the SECMARK service:
>>>>    -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>>>>    -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
>>>> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>>>>      <br>
>>>>    -## NetLabel - Fallback Peer Labeling
>>>> +## Internal labeling: NetLabel - Fallback Peer Labeling
>>>>      Fallback labeling can optionally be implemented on a system if
>>>> the
>>>>    Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
>>>> @@ -217,9 +242,20 @@ netlabelctl -p map list
>>>>    Note that the security contexts must be valid in the policy otherwise the
>>>>    commands will fail.
>>>>    +Before the NetLabel rules can be loaded, TE rules must be added
>>>> to
>>>> +define the types. Then the rules can allow domains to receive data
>>>> +from objects of `peer` class:
>>>> +
>>>> +```
>>>> +type netlabel_sctp_peer_t;
>>>> +
>>>> +allow my_server_t netlabel_sctp_peer_t:peer recv;
>>>> +```
>>>> +Note that sending can't be controlled with `peer` class.
>>>> +
>>>>    <br>
>>>>    -## NetLabel – CIPSO/CALIPSO
>>>> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>>>>      To allow MLS [**security levels**](mls_mcs.md#security-levels)
>>>> to be passed
>>>>    over a network between MLS
>>>> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>>>>      <br>
>>>>    -## Labeled IPSec
>>>> +## Labeled Networking: Labeled IPSec
>>>>      Labeled IPSec has been built into the standard GNU / Linux
>>>> IPSec
>>>>    services as described in the
>>>> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>>>>      <br>
>>>>    +## Access Control for Network Interfaces
>>>> +
>>>> +SELinux domains can be restricted to use only specific network
>>>> +interfaces. TE rules must define the interface types and then allow a
>>>> +domain to `egress` in class `netif` for the defined interface types:
>>>> +
>>>> +```
>>>> +require {
>>>> +        attribute netif_type;
>>>> +}
>>>> +
>>>> +type external_if_t, netif_type;
>>>> +type loopback_if_t, netif_type;
>>>> +
>>>> +allow my_server_t external_if_t:netif egress;
>>>> +allow my_server_t loopback_if_t:netif egress;
>>>> +```
>>>> +
>>>> +The interfaces must also be labeled with ***semanage**(8)* (or by
>>>> +using `netifcon` statements in the policy):
>>>> +```
>>>> +semanage interface -a -t loopback_if_t -r s0 lo
>>>> +semanage interface -a -t external_if_t -r s0 eth0
>>>> +```
>>>> +
>>>> +Note that reception can't be controlled with `netif` class.
>>>
>>> Probably nothing but I did not understand this: Is reception not
>>> controlled with the netif ingress permission?
>>
>> I'm no expert, but the only netif ingress rules which I have are
>> rather generic:
>>
>> allow internet_peer_t external_if_t:netif ingress;
>> allow link_local_peer_t external_if_t:netif ingress;
>> allow localnet_peer_t external_if_t:netif ingress;
>> allow multicast_peer_t external_if_t:netif ingress;
>> allow loopback_peer_t loopback_if_t:netif ingress;
>>
>> `peer` types above have been added with NetLabel rules like:
>>
>> netlabelctl unlbl add default address:2000::/3
>> label:system_u:object_r:internet_peer_t:s0
>>
>> Perhaps this would be better:
>>
>> Note that reception for application domains can't be controlled with
>> `netif` class.
>>
> 
> I look at it this way: peers *are* processes, You seem to
> essentually use peers as nodes above.

I think both are true. When labeled IPSec is used, it's probably (I 
haven't tried it yet) possible to identify peers at process level. 
Without IPSec it's only possible to get peer labeling with NetLabel 
rules, which only allow IP address (host or even networks of hosts) 
level accuracy.

> It would become more clear if you would try this out with labeled ipsec.
> A peer, in my experience is kind of the same as an association in the
> labeled ipsec scenario (the classes actually overlap). That is also why
> you should probably disable the netlabel_peer_controls polcap if you use
> labeled ipsec.

Right, but I think my setup could be useful for cases where labeled 
IPSec is not used.

Do you see AVC denials etc. for netif *ingress* for process level 
domains with labeled IPSec?

-Topi

>>>
>>>> +
>>>> +<br>
>>>> +
>>>> +## Access Control for Network Nodes
>>>> +
>>>> +Domains can be restricted by SELinux to access and bind sockets to
>>>> +only dedicated network nodes (in practice, IP addresses).
>>>> +
>>>> +The node types must be defined and then the node types can be used for
>>>> +TE rules as target context. TE rules to allow a domain to `sendto` for
>>>> +class `node` and to `node_bind` (for incoming connections) for class
>>>> +`tcp_socket`:
>>>> +
>>>> +```
>>>> +require {
>>>> +        attribute node_type;
>>>> +}
>>>> +
>>>> +type loopback_node_t, node_type;
>>>> +type internet_node_t, node_type;
>>>> +type link_local_node_t, node_type;
>>>> +type multicast_node_t, node_type;
>>>> +
>>>> +allow my_server_t loopback_node_t:node sendto;
>>>> +allow my_server_t loopback_node_t:tcp_socket node_bind;
>>>> +allow my_server_t internet_node_t:node sendto;
>>>> +```
>>>> +
>>>> +After the types have been defined, corresponding node rules can be
>>>> +added with `semanage` (or `nodecon` statements):
>>>> +```
>>>> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
>>>> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
>>>> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
>>>> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
>>>> +```
>>>> +
>>>> +<br>
>>>> +
>>>> +## Access Control for Network Ports
>>>> +
>>>> +SELinux policy can also control access to ports used by various
>>>> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
>>>> +define the port types and then allow a domain to `name_connect`
>>>> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
>>>> +`udp_socket` etc) for the defined port types:
>>>> +
>>>> +```
>>>> +require {
>>>> +        attribute port_type;
>>>> +}
>>>> +
>>>> +type my_server_port_t, port_type;
>>>> +
>>>> +allow my_server_t my_server_port_t:tcp_socket name_connect;
>>>> +allow my_server_t my_server_port_t:tcp_socket name_bind;
>>>> +```
>>>> +
>>>> +The ports must also be labeled with `semanage` (or `portcon`
>>>> +statements):
>>>> +```
>>>> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
>>>> +```
>>>> +
>>>> +<br>
>>>> +
>>>>    <section class="footnotes">
>>>>    <ol>
>>>>    <li id="fnn1"><p>For example, an ftp session where the server is
>>>> listening on a specific port (the destination port) but the client
>>>> will be assigned a random source port. The CONNSECMARK will ensure
>>>> that all packets for the ftp session are marked with the same label.<a
>>>> href="#fnnet1" class="footnote-back">↩</a></p></li>
>>>
>>
>

Dominick Grift July 27, 2020, 8:36 p.m. UTC | #5

Topi Miettinen <[e-mail]> writes:

> On 27.7.2020 18.39, Dominick Grift wrote:
>> Topi Miettinen <[e-mail]> writes:
>>
>>> On 27.7.2020 16.57, Dominick Grift wrote:
>>>> Topi Miettinen <[e-mail]> writes:
>>>>
>>>>> List all access control methods available for networking and provide
>>>>> examples for each.
>>>>>
>>>>> Signed-off-by: Topi Miettinen <[e-mail]>
>>>>>
>>>>> ---
>>>>> v2: address comments from Richard Haines
>>>>> ---
>>>>>    src/network_statements.md |   2 +-
>>>>>    src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>>>>    2 files changed, 150 insertions(+), 22 deletions(-)
>>>>>
>>>>> diff --git a/src/network_statements.md b/src/network_statements.md
>>>>> index ef1c873..357c3b1 100644
>>>>> --- a/src/network_statements.md
>>>>> +++ b/src/network_statements.md
>>>>> @@ -102,7 +102,7 @@ the interface to a security context.
>>>>>    <tr>
>>>>>    <td><code>packet_context</code></td>
>>>>>    <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>>>>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>>>>> +<p>The iptables(8)/nftables(8) <a
>>>>> href="network_support.md#internal-labeling-secmark">SECMARK
>>>>> services</a> should be used to label packets.</p></td>
>>>>>    </tr>
>>>>>    </tbody>
>>>>>    </table>
>>>>> diff --git a/src/network_support.md b/src/network_support.md
>>>>> index 309e863..6f9896b 100644
>>>>> --- a/src/network_support.md
>>>>> +++ b/src/network_support.md
>>>>> @@ -1,20 +1,17 @@
>>>>>    # SELinux Networking Support
>>>>>    -SELinux supports the following types of network labeling:
>>>>> +SELinux supports several methods for access control of networks. These are
>>>>>    -**Internal labeling** - This is where network objects are
>>>>> labeled and
>>>>> -managed internally within a single machine (i.e. their labels are not
>>>>> -transmitted as part of the session with remote systems). There are two
>>>>> -types supported: SECMARK and NetLabel. There was a service known as
>>>>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>>>>> +* Packet labeling: class `packet`
>>>>> +* Peer labeling: class `peer`
>>>>> +* Interface control: class `netif`
>>>>> +* Network node control: class `node`
>>>>> +* TCP/UDP/SCTP/DCCP ports: class `port`
>>>>>    -**Labeled Networking** - This is where labels are passed to/from
>>>>> remote
>>>>> -systems where they can be interpreted and a MAC policy enforced on each
>>>>> -system. There are three types supported: Labeled IPSec, CIPSO
>>>>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>>> -IPv6 Security Option)
>>>>> +Networking support is not enabled by default. It can be enabled either
>>>>> +the policy capabilities or by loading SECMARK rules.
>>>>>    -There are two policy capability options that can be set within
>>>>> policy
>>>>> +There are three policy capability options that can be set within policy
>>>>>    using the `policycap` statement that affect networking configuration:
>>>>>      **`network_peer_controls`** - This is always enabled in the
>>>>> latest
>>>>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>>>>    SELinux filesystem as shown in the
>>>>>    [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>>>>    -To support peer labeling, CIPSO and CALIPSO the NetLabel tools
>>>>> need to
>>>>> -be installed:
>>>>> +SELinux supports the following types of network labeling:
>>>>> +
>>>>> +**Internal labeling** - This is where network objects are labeled and
>>>>> +managed internally within a single machine (i.e. their labels are not
>>>>> +transmitted as part of the session with remote systems). There are two
>>>>> +types supported: SECMARK and NetLabel. There was a service known as
>>>>> +'compat_net' controls, however that was removed in kernel 2.6.30.
>>>>> +
>>>>> +**Labeled Networking** - This is where labels are passed to/from remote
>>>>> +systems where they can be interpreted and a MAC policy enforced on each
>>>>> +system. There are three types supported: Labeled IPSec, CIPSO
>>>>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>>> +IPv6 Security Option).
>>>>> +
>>>>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>>>>> +the NetLabel tools need to be installed:
>>>>>      `dnf install netlabel_tools`
>>>>>    @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>>>>>    `dnf install libreswan`
>>>>>      It is important to note that the kernel must be configured to
>>>>> support
>>>>> -these services. The Fedora kernels are configured to handle all the above
>>>>> -services.
>>>>> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
>>>>> +`CONFIG_NF_CONNTRACK_SECMARK`,
>>>>> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
>>>>> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
>>>>> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
>>>>> +configured to handle all the above services.
>>>>>      The Linux networking package *iproute* has an SELinux aware
>>>>> socket
>>>>>    statistics command ***ss**(8)* that will show the SELinux context of
>>>>> @@ -65,7 +80,7 @@ to achieve this).
>>>>>      <br>
>>>>>    -## SECMARK
>>>>> +## Internal labeling: SECMARK
>>>>>      SECMARK makes use of the standard kernel NetFilter framework
>>>>> that
>>>>>    underpins the GNU / Linux IP networking sub-system. NetFilter services
>>>>> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>>>>>    controls on interfaces, IP addresses (nodes) and ports with the added
>>>>>    advantage of connection tracking. The SECMARK security extensions allow
>>>>>    security contexts to be added to packets (SECMARK) or sessions
>>>>> -(CONNSECMARK).
>>>>> +(CONNSECMARK), belonging to object class of `packet`.
>>>>>      The NetFilter framework inspects and tag packets with labels as
>>>>> defined
>>>>>    within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
>>>>> @@ -172,6 +187,16 @@ table ip6 security {
>>>>>    }
>>>>>    ```
>>>>>    +Before the SECMARK rules can be loaded, TE rules must be added
>>>>> to
>>>>> +define the types, and also allow domains to send and/or receive
>>>>> +objects of `packet` class:
>>>>> +
>>>>> +```
>>>>> +type test_server_packet_t, packet_type;
>>>>> +
>>>>> +allow my_server_t test_server_packet_t:packet { send recv };
>>>>> +```
>>>>> +
>>>>>    The following articles explain the SECMARK service:
>>>>>    -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>>>>>    -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
>>>>> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>>>>>      <br>
>>>>>    -## NetLabel - Fallback Peer Labeling
>>>>> +## Internal labeling: NetLabel - Fallback Peer Labeling
>>>>>      Fallback labeling can optionally be implemented on a system if
>>>>> the
>>>>>    Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
>>>>> @@ -217,9 +242,20 @@ netlabelctl -p map list
>>>>>    Note that the security contexts must be valid in the policy otherwise the
>>>>>    commands will fail.
>>>>>    +Before the NetLabel rules can be loaded, TE rules must be added
>>>>> to
>>>>> +define the types. Then the rules can allow domains to receive data
>>>>> +from objects of `peer` class:
>>>>> +
>>>>> +```
>>>>> +type netlabel_sctp_peer_t;
>>>>> +
>>>>> +allow my_server_t netlabel_sctp_peer_t:peer recv;
>>>>> +```
>>>>> +Note that sending can't be controlled with `peer` class.
>>>>> +
>>>>>    <br>
>>>>>    -## NetLabel – CIPSO/CALIPSO
>>>>> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>>>>>      To allow MLS [**security levels**](mls_mcs.md#security-levels)
>>>>> to be passed
>>>>>    over a network between MLS
>>>>> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>>>>>      <br>
>>>>>    -## Labeled IPSec
>>>>> +## Labeled Networking: Labeled IPSec
>>>>>      Labeled IPSec has been built into the standard GNU / Linux
>>>>> IPSec
>>>>>    services as described in the
>>>>> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>>>>>      <br>
>>>>>    +## Access Control for Network Interfaces
>>>>> +
>>>>> +SELinux domains can be restricted to use only specific network
>>>>> +interfaces. TE rules must define the interface types and then allow a
>>>>> +domain to `egress` in class `netif` for the defined interface types:
>>>>> +
>>>>> +```
>>>>> +require {
>>>>> +        attribute netif_type;
>>>>> +}
>>>>> +
>>>>> +type external_if_t, netif_type;
>>>>> +type loopback_if_t, netif_type;
>>>>> +
>>>>> +allow my_server_t external_if_t:netif egress;
>>>>> +allow my_server_t loopback_if_t:netif egress;
>>>>> +```
>>>>> +
>>>>> +The interfaces must also be labeled with ***semanage**(8)* (or by
>>>>> +using `netifcon` statements in the policy):
>>>>> +```
>>>>> +semanage interface -a -t loopback_if_t -r s0 lo
>>>>> +semanage interface -a -t external_if_t -r s0 eth0
>>>>> +```
>>>>> +
>>>>> +Note that reception can't be controlled with `netif` class.
>>>>
>>>> Probably nothing but I did not understand this: Is reception not
>>>> controlled with the netif ingress permission?
>>>
>>> I'm no expert, but the only netif ingress rules which I have are
>>> rather generic:
>>>
>>> allow internet_peer_t external_if_t:netif ingress;
>>> allow link_local_peer_t external_if_t:netif ingress;
>>> allow localnet_peer_t external_if_t:netif ingress;
>>> allow multicast_peer_t external_if_t:netif ingress;
>>> allow loopback_peer_t loopback_if_t:netif ingress;
>>>
>>> `peer` types above have been added with NetLabel rules like:
>>>
>>> netlabelctl unlbl add default address:2000::/3
>>> label:system_u:object_r:internet_peer_t:s0
>>>
>>> Perhaps this would be better:
>>>
>>> Note that reception for application domains can't be controlled with
>>> `netif` class.
>>>
>>
>> I look at it this way: peers *are* processes, You seem to
>> essentually use peers as nodes above.
>
> I think both are true. When labeled IPSec is used, it's probably (I
> haven't tried it yet) possible to identify peers at process
> level. Without IPSec it's only possible to get peer labeling with
> NetLabel rules, which only allow IP address (host or even networks of
> hosts) level accuracy.
>

The thing, i think, is that netlabel is limited and really geared
towards MLS, it will only send levels over the wire i believe (except for loopback)

By AFAIK the point of netlabel is to be able enforce mult-level security
on secure networks. For example you could have a ssh server running on a
particular level. In other words netlabel AFAIK should be able to send a
process/peer level over the network AFAIK.

>> It would become more clear if you would try this out with labeled ipsec.
>> A peer, in my experience is kind of the same as an association in the
>> labeled ipsec scenario (the classes actually overlap). That is also why
>> you should probably disable the netlabel_peer_controls polcap if you use
>> labeled ipsec.
>
> Right, but I think my setup could be useful for cases where labeled
> IPSec is not used.
>
> Do you see AVC denials etc. for netif *ingress* for process level
> domains with labeled IPSec?

I use to have extensive recordings and blogs about this matter but i
erased it all, and i currently dont have a ipsec tunnel, or avc denials,
but I do vaguely recall that the ingress with labeled ipsec was on a per process
level. I might be wrong though.

I would probably just omit the line about the reception to be on the
safe side. (can always add that later if needed)

>
> -Topi
>
>>>>
>>>>> +
>>>>> +<br>
>>>>> +
>>>>> +## Access Control for Network Nodes
>>>>> +
>>>>> +Domains can be restricted by SELinux to access and bind sockets to
>>>>> +only dedicated network nodes (in practice, IP addresses).
>>>>> +
>>>>> +The node types must be defined and then the node types can be used for
>>>>> +TE rules as target context. TE rules to allow a domain to `sendto` for
>>>>> +class `node` and to `node_bind` (for incoming connections) for class
>>>>> +`tcp_socket`:
>>>>> +
>>>>> +```
>>>>> +require {
>>>>> +        attribute node_type;
>>>>> +}
>>>>> +
>>>>> +type loopback_node_t, node_type;
>>>>> +type internet_node_t, node_type;
>>>>> +type link_local_node_t, node_type;
>>>>> +type multicast_node_t, node_type;
>>>>> +
>>>>> +allow my_server_t loopback_node_t:node sendto;
>>>>> +allow my_server_t loopback_node_t:tcp_socket node_bind;
>>>>> +allow my_server_t internet_node_t:node sendto;
>>>>> +```
>>>>> +
>>>>> +After the types have been defined, corresponding node rules can be
>>>>> +added with `semanage` (or `nodecon` statements):
>>>>> +```
>>>>> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
>>>>> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
>>>>> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
>>>>> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
>>>>> +```
>>>>> +
>>>>> +<br>
>>>>> +
>>>>> +## Access Control for Network Ports
>>>>> +
>>>>> +SELinux policy can also control access to ports used by various
>>>>> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
>>>>> +define the port types and then allow a domain to `name_connect`
>>>>> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
>>>>> +`udp_socket` etc) for the defined port types:
>>>>> +
>>>>> +```
>>>>> +require {
>>>>> +        attribute port_type;
>>>>> +}
>>>>> +
>>>>> +type my_server_port_t, port_type;
>>>>> +
>>>>> +allow my_server_t my_server_port_t:tcp_socket name_connect;
>>>>> +allow my_server_t my_server_port_t:tcp_socket name_bind;
>>>>> +```
>>>>> +
>>>>> +The ports must also be labeled with `semanage` (or `portcon`
>>>>> +statements):
>>>>> +```
>>>>> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
>>>>> +```
>>>>> +
>>>>> +<br>
>>>>> +
>>>>>    <section class="footnotes">
>>>>>    <ol>
>>>>>    <li id="fnn1"><p>For example, an ftp session where the server is
>>>>> listening on a specific port (the destination port) but the client
>>>>> will be assigned a random source port. The CONNSECMARK will ensure
>>>>> that all packets for the ftp session are marked with the same label.<a
>>>>> href="#fnnet1" class="footnote-back">↩</a></p></li>
>>>>
>>>
>>
>

Topi Miettinen July 27, 2020, 9:44 p.m. UTC | #6

On 27.7.2020 23.36, Dominick Grift wrote:
> Topi Miettinen <[e-mail]> writes:
> 
>> On 27.7.2020 18.39, Dominick Grift wrote:
>>> Topi Miettinen <[e-mail]> writes:
>>>
>>>> On 27.7.2020 16.57, Dominick Grift wrote:
>>>>> Topi Miettinen <[e-mail]> writes:
>>>>>
>>>>>> List all access control methods available for networking and provide
>>>>>> examples for each.
>>>>>>
>>>>>> Signed-off-by: Topi Miettinen <[e-mail]>
>>>>>>
>>>>>> ---
>>>>>> v2: address comments from Richard Haines
>>>>>> ---
>>>>>>     src/network_statements.md |   2 +-
>>>>>>     src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>>>>>     2 files changed, 150 insertions(+), 22 deletions(-)
>>>>>>
>>>>>> diff --git a/src/network_statements.md b/src/network_statements.md
>>>>>> index ef1c873..357c3b1 100644
>>>>>> --- a/src/network_statements.md
>>>>>> +++ b/src/network_statements.md
>>>>>> @@ -102,7 +102,7 @@ the interface to a security context.
>>>>>>     <tr>
>>>>>>     <td><code>packet_context</code></td>
>>>>>>     <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>>>>>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>>>>>> +<p>The iptables(8)/nftables(8) <a
>>>>>> href="network_support.md#internal-labeling-secmark">SECMARK
>>>>>> services</a> should be used to label packets.</p></td>
>>>>>>     </tr>
>>>>>>     </tbody>
>>>>>>     </table>
>>>>>> diff --git a/src/network_support.md b/src/network_support.md
>>>>>> index 309e863..6f9896b 100644
>>>>>> --- a/src/network_support.md
>>>>>> +++ b/src/network_support.md
>>>>>> @@ -1,20 +1,17 @@
>>>>>>     # SELinux Networking Support
>>>>>>     -SELinux supports the following types of network labeling:
>>>>>> +SELinux supports several methods for access control of networks. These are
>>>>>>     -**Internal labeling** - This is where network objects are
>>>>>> labeled and
>>>>>> -managed internally within a single machine (i.e. their labels are not
>>>>>> -transmitted as part of the session with remote systems). There are two
>>>>>> -types supported: SECMARK and NetLabel. There was a service known as
>>>>>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>>>>>> +* Packet labeling: class `packet`
>>>>>> +* Peer labeling: class `peer`
>>>>>> +* Interface control: class `netif`
>>>>>> +* Network node control: class `node`
>>>>>> +* TCP/UDP/SCTP/DCCP ports: class `port`
>>>>>>     -**Labeled Networking** - This is where labels are passed to/from
>>>>>> remote
>>>>>> -systems where they can be interpreted and a MAC policy enforced on each
>>>>>> -system. There are three types supported: Labeled IPSec, CIPSO
>>>>>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>>>> -IPv6 Security Option)
>>>>>> +Networking support is not enabled by default. It can be enabled either
>>>>>> +the policy capabilities or by loading SECMARK rules.
>>>>>>     -There are two policy capability options that can be set within
>>>>>> policy
>>>>>> +There are three policy capability options that can be set within policy
>>>>>>     using the `policycap` statement that affect networking configuration:
>>>>>>       **`network_peer_controls`** - This is always enabled in the
>>>>>> latest
>>>>>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>>>>>     SELinux filesystem as shown in the
>>>>>>     [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>>>>>     -To support peer labeling, CIPSO and CALIPSO the NetLabel tools
>>>>>> need to
>>>>>> -be installed:
>>>>>> +SELinux supports the following types of network labeling:
>>>>>> +
>>>>>> +**Internal labeling** - This is where network objects are labeled and
>>>>>> +managed internally within a single machine (i.e. their labels are not
>>>>>> +transmitted as part of the session with remote systems). There are two
>>>>>> +types supported: SECMARK and NetLabel. There was a service known as
>>>>>> +'compat_net' controls, however that was removed in kernel 2.6.30.
>>>>>> +
>>>>>> +**Labeled Networking** - This is where labels are passed to/from remote
>>>>>> +systems where they can be interpreted and a MAC policy enforced on each
>>>>>> +system. There are three types supported: Labeled IPSec, CIPSO
>>>>>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>>>>>> +IPv6 Security Option).
>>>>>> +
>>>>>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>>>>>> +the NetLabel tools need to be installed:
>>>>>>       `dnf install netlabel_tools`
>>>>>>     @@ -52,8 +63,12 @@ OpenSwan but is now distributed as LibreSwan:
>>>>>>     `dnf install libreswan`
>>>>>>       It is important to note that the kernel must be configured to
>>>>>> support
>>>>>> -these services. The Fedora kernels are configured to handle all the above
>>>>>> -services.
>>>>>> +these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
>>>>>> +`CONFIG_NF_CONNTRACK_SECMARK`,
>>>>>> +`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
>>>>>> +`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
>>>>>> +`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
>>>>>> +configured to handle all the above services.
>>>>>>       The Linux networking package *iproute* has an SELinux aware
>>>>>> socket
>>>>>>     statistics command ***ss**(8)* that will show the SELinux context of
>>>>>> @@ -65,7 +80,7 @@ to achieve this).
>>>>>>       <br>
>>>>>>     -## SECMARK
>>>>>> +## Internal labeling: SECMARK
>>>>>>       SECMARK makes use of the standard kernel NetFilter framework
>>>>>> that
>>>>>>     underpins the GNU / Linux IP networking sub-system. NetFilter services
>>>>>> @@ -73,7 +88,7 @@ automatically inspects all incoming and outgoing packets and can place
>>>>>>     controls on interfaces, IP addresses (nodes) and ports with the added
>>>>>>     advantage of connection tracking. The SECMARK security extensions allow
>>>>>>     security contexts to be added to packets (SECMARK) or sessions
>>>>>> -(CONNSECMARK).
>>>>>> +(CONNSECMARK), belonging to object class of `packet`.
>>>>>>       The NetFilter framework inspects and tag packets with labels as
>>>>>> defined
>>>>>>     within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
>>>>>> @@ -172,6 +187,16 @@ table ip6 security {
>>>>>>     }
>>>>>>     ```
>>>>>>     +Before the SECMARK rules can be loaded, TE rules must be added
>>>>>> to
>>>>>> +define the types, and also allow domains to send and/or receive
>>>>>> +objects of `packet` class:
>>>>>> +
>>>>>> +```
>>>>>> +type test_server_packet_t, packet_type;
>>>>>> +
>>>>>> +allow my_server_t test_server_packet_t:packet { send recv };
>>>>>> +```
>>>>>> +
>>>>>>     The following articles explain the SECMARK service:
>>>>>>     -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
>>>>>>     -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
>>>>>> @@ -179,7 +204,7 @@ The following articles explain the SECMARK service:
>>>>>>       <br>
>>>>>>     -## NetLabel - Fallback Peer Labeling
>>>>>> +## Internal labeling: NetLabel - Fallback Peer Labeling
>>>>>>       Fallback labeling can optionally be implemented on a system if
>>>>>> the
>>>>>>     Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
>>>>>> @@ -217,9 +242,20 @@ netlabelctl -p map list
>>>>>>     Note that the security contexts must be valid in the policy otherwise the
>>>>>>     commands will fail.
>>>>>>     +Before the NetLabel rules can be loaded, TE rules must be added
>>>>>> to
>>>>>> +define the types. Then the rules can allow domains to receive data
>>>>>> +from objects of `peer` class:
>>>>>> +
>>>>>> +```
>>>>>> +type netlabel_sctp_peer_t;
>>>>>> +
>>>>>> +allow my_server_t netlabel_sctp_peer_t:peer recv;
>>>>>> +```
>>>>>> +Note that sending can't be controlled with `peer` class.
>>>>>> +
>>>>>>     <br>
>>>>>>     -## NetLabel – CIPSO/CALIPSO
>>>>>> +## Labeled Networking: NetLabel – CIPSO/CALIPSO
>>>>>>       To allow MLS [**security levels**](mls_mcs.md#security-levels)
>>>>>> to be passed
>>>>>>     over a network between MLS
>>>>>> @@ -288,7 +324,7 @@ section, plus the standard Fedora 'targeted' policy for the tests.
>>>>>>       <br>
>>>>>>     -## Labeled IPSec
>>>>>> +## Labeled Networking: Labeled IPSec
>>>>>>       Labeled IPSec has been built into the standard GNU / Linux
>>>>>> IPSec
>>>>>>     services as described in the
>>>>>> @@ -451,6 +487,98 @@ The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
>>>>>>       <br>
>>>>>>     +## Access Control for Network Interfaces
>>>>>> +
>>>>>> +SELinux domains can be restricted to use only specific network
>>>>>> +interfaces. TE rules must define the interface types and then allow a
>>>>>> +domain to `egress` in class `netif` for the defined interface types:
>>>>>> +
>>>>>> +```
>>>>>> +require {
>>>>>> +        attribute netif_type;
>>>>>> +}
>>>>>> +
>>>>>> +type external_if_t, netif_type;
>>>>>> +type loopback_if_t, netif_type;
>>>>>> +
>>>>>> +allow my_server_t external_if_t:netif egress;
>>>>>> +allow my_server_t loopback_if_t:netif egress;
>>>>>> +```
>>>>>> +
>>>>>> +The interfaces must also be labeled with ***semanage**(8)* (or by
>>>>>> +using `netifcon` statements in the policy):
>>>>>> +```
>>>>>> +semanage interface -a -t loopback_if_t -r s0 lo
>>>>>> +semanage interface -a -t external_if_t -r s0 eth0
>>>>>> +```
>>>>>> +
>>>>>> +Note that reception can't be controlled with `netif` class.
>>>>>
>>>>> Probably nothing but I did not understand this: Is reception not
>>>>> controlled with the netif ingress permission?
>>>>
>>>> I'm no expert, but the only netif ingress rules which I have are
>>>> rather generic:
>>>>
>>>> allow internet_peer_t external_if_t:netif ingress;
>>>> allow link_local_peer_t external_if_t:netif ingress;
>>>> allow localnet_peer_t external_if_t:netif ingress;
>>>> allow multicast_peer_t external_if_t:netif ingress;
>>>> allow loopback_peer_t loopback_if_t:netif ingress;
>>>>
>>>> `peer` types above have been added with NetLabel rules like:
>>>>
>>>> netlabelctl unlbl add default address:2000::/3
>>>> label:system_u:object_r:internet_peer_t:s0
>>>>
>>>> Perhaps this would be better:
>>>>
>>>> Note that reception for application domains can't be controlled with
>>>> `netif` class.
>>>>
>>>
>>> I look at it this way: peers *are* processes, You seem to
>>> essentually use peers as nodes above.
>>
>> I think both are true. When labeled IPSec is used, it's probably (I
>> haven't tried it yet) possible to identify peers at process
>> level. Without IPSec it's only possible to get peer labeling with
>> NetLabel rules, which only allow IP address (host or even networks of
>> hosts) level accuracy.
>>
> 
> The thing, i think, is that netlabel is limited and really geared
> towards MLS, it will only send levels over the wire i believe (except for loopback)
> 
> By AFAIK the point of netlabel is to be able enforce mult-level security
> on secure networks. For example you could have a ssh server running on a
> particular level. In other words netlabel AFAIK should be able to send a
> process/peer level over the network AFAIK.

I think this applies to CIPSO/CALIPSO but not `unlabeled` mode which is 
used in my example.

MLS is not very interesting for users in general and so neither will be 
CIPSO/CALIPSO. Maybe labeled IPSec could be useful in some controlled 
corporate environments where all parties are relatively trusted.

But I think `unlabeled` mode, together with other networking controls, 
could be very useful for all users. For some reason, it's bit hard in 
Linux to give each application an individual firewall while this has 
been easy in Windows for a long time. With SELinux network controls it's 
possible to enforce application level access control but the knobs seem 
to be weird.

>>> It would become more clear if you would try this out with labeled ipsec.
>>> A peer, in my experience is kind of the same as an association in the
>>> labeled ipsec scenario (the classes actually overlap). That is also why
>>> you should probably disable the netlabel_peer_controls polcap if you use
>>> labeled ipsec.
>>
>> Right, but I think my setup could be useful for cases where labeled
>> IPSec is not used.
>>
>> Do you see AVC denials etc. for netif *ingress* for process level
>> domains with labeled IPSec?
> 
> I use to have extensive recordings and blogs about this matter but i
> erased it all, and i currently dont have a ipsec tunnel, or avc denials,
> but I do vaguely recall that the ingress with labeled ipsec was on a per process
> level. I might be wrong though.
> 
> I would probably just omit the line about the reception to be on the
> safe side. (can always add that later if needed)

Yes, that's probably safer.

-Topi

> 
>>
>> -Topi
>>
>>>>>
>>>>>> +
>>>>>> +<br>
>>>>>> +
>>>>>> +## Access Control for Network Nodes
>>>>>> +
>>>>>> +Domains can be restricted by SELinux to access and bind sockets to
>>>>>> +only dedicated network nodes (in practice, IP addresses).
>>>>>> +
>>>>>> +The node types must be defined and then the node types can be used for
>>>>>> +TE rules as target context. TE rules to allow a domain to `sendto` for
>>>>>> +class `node` and to `node_bind` (for incoming connections) for class
>>>>>> +`tcp_socket`:
>>>>>> +
>>>>>> +```
>>>>>> +require {
>>>>>> +        attribute node_type;
>>>>>> +}
>>>>>> +
>>>>>> +type loopback_node_t, node_type;
>>>>>> +type internet_node_t, node_type;
>>>>>> +type link_local_node_t, node_type;
>>>>>> +type multicast_node_t, node_type;
>>>>>> +
>>>>>> +allow my_server_t loopback_node_t:node sendto;
>>>>>> +allow my_server_t loopback_node_t:tcp_socket node_bind;
>>>>>> +allow my_server_t internet_node_t:node sendto;
>>>>>> +```
>>>>>> +
>>>>>> +After the types have been defined, corresponding node rules can be
>>>>>> +added with `semanage` (or `nodecon` statements):
>>>>>> +```
>>>>>> +semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
>>>>>> +semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
>>>>>> +semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
>>>>>> +semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
>>>>>> +```
>>>>>> +
>>>>>> +<br>
>>>>>> +
>>>>>> +## Access Control for Network Ports
>>>>>> +
>>>>>> +SELinux policy can also control access to ports used by various
>>>>>> +networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
>>>>>> +define the port types and then allow a domain to `name_connect`
>>>>>> +(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
>>>>>> +`udp_socket` etc) for the defined port types:
>>>>>> +
>>>>>> +```
>>>>>> +require {
>>>>>> +        attribute port_type;
>>>>>> +}
>>>>>> +
>>>>>> +type my_server_port_t, port_type;
>>>>>> +
>>>>>> +allow my_server_t my_server_port_t:tcp_socket name_connect;
>>>>>> +allow my_server_t my_server_port_t:tcp_socket name_bind;
>>>>>> +```
>>>>>> +
>>>>>> +The ports must also be labeled with `semanage` (or `portcon`
>>>>>> +statements):
>>>>>> +```
>>>>>> +semanage port -a -t my_server_port_t -p tcp -r s0 12345
>>>>>> +```
>>>>>> +
>>>>>> +<br>
>>>>>> +
>>>>>>     <section class="footnotes">
>>>>>>     <ol>
>>>>>>     <li id="fnn1"><p>For example, an ftp session where the server is
>>>>>> listening on a specific port (the destination port) but the client
>>>>>> will be assigned a random source port. The CONNSECMARK will ensure
>>>>>> that all packets for the ftp session are marked with the same label.<a
>>>>>> href="#fnnet1" class="footnote-back">↩</a></p></li>
>>>>>
>>>>
>>>
>>
>

Paul Moore July 28, 2020, 2:44 a.m. UTC | #7

On Mon, Jul 27, 2020 at 9:04 AM Topi Miettinen <[e-mail]> wrote:
>
> List all access control methods available for networking and provide
> examples for each.
>
> Signed-off-by: Topi Miettinen <[e-mail]>
>
> ---
> v2: address comments from Richard Haines
> ---
>  src/network_statements.md |   2 +-
>  src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>  2 files changed, 150 insertions(+), 22 deletions(-)
>
> diff --git a/src/network_statements.md b/src/network_statements.md
> index ef1c873..357c3b1 100644
> --- a/src/network_statements.md
> +++ b/src/network_statements.md
> @@ -102,7 +102,7 @@ the interface to a security context.
>  <tr>
>  <td><code>packet_context</code></td>
>  <td><p>The security context allocated packets. Note that these are defined but unused.</p>
> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
> +<p>The iptables(8)/nftables(8) <a href="network_support.md#internal-labeling-secmark">SECMARK services</a> should be used to label packets.</p></td>
>  </tr>
>  </tbody>
>  </table>
> diff --git a/src/network_support.md b/src/network_support.md
> index 309e863..6f9896b 100644
> --- a/src/network_support.md
> +++ b/src/network_support.md
> @@ -1,20 +1,17 @@
>  # SELinux Networking Support
>
> -SELinux supports the following types of network labeling:
> +SELinux supports several methods for access control of networks. These are
>
> -**Internal labeling** - This is where network objects are labeled and
> -managed internally within a single machine (i.e. their labels are not
> -transmitted as part of the session with remote systems). There are two
> -types supported: SECMARK and NetLabel. There was a service known as
> -'compat_net' controls, however that was removed in kernel 2.6.30.
> +* Packet labeling: class `packet`
> +* Peer labeling: class `peer`
> +* Interface control: class `netif`
> +* Network node control: class `node`
> +* TCP/UDP/SCTP/DCCP ports: class `port`

For whatever it is worth, I've always thought of the SELinux network
access controls as being composed of two parts: socket layer controls
and packet layer controls (or per-packet controls).  The packet layer
controls are further divided into the "peer" and "secmark" controls.

The socket layer controls are the access controls which closely mimic
the socket syscalls and typically involve checking if a running task
can perform an operation on a network socket, e.g. bind().  These are
usually easy to understand and don't require any special network
configuration.

The packet layer controls are where things start to get interesting as
this is where we apply SELinux security policy to individual packets
as they flow into, out of, and through the system.  As mentioned
above, the packet layer controls are comprised of both "peer" and
"secmark" controls.  The "peer" controls are those access controls
which compare the security attributes (SELinux label) of the sending
peer with the security context of the receiving peer.  The "secmark"
controls compare the network attributes (e.g. IP header values) with
the sending or receiving task's security attributes.  It get's very
complicated very quickly, but a simple example is to think of the
"peer" access controls as restricting firefox_t to talking only to
httpd_t, while the "secmark" access controls restrict firefox_t to
talking only to network services on TCP port 80.

Secmark is (obviously) the "secmark" access controls.

Labeled IPsec and the NetLabel framework are the current "peer" access
controls, with NetLabel supporting CIPSO for IPv4, CALIPSO for IPv6,
and a fallback/static labeling for unlabeled IPv4 and IPv6 networks.

> -**Labeled Networking** - This is where labels are passed to/from remote
> -systems where they can be interpreted and a MAC policy enforced on each
> -system. There are three types supported: Labeled IPSec, CIPSO
> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
> -IPv6 Security Option)
> +Networking support is not enabled by default. It can be enabled either
> +the policy capabilities or by loading SECMARK rules.
>
> -There are two policy capability options that can be set within policy
> +There are three policy capability options that can be set within policy
>  using the `policycap` statement that affect networking configuration:
>
>  **`network_peer_controls`** - This is always enabled in the latest
> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>  SELinux filesystem as shown in the
>  [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>
> -To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
> -be installed:
> +SELinux supports the following types of network labeling:
> +
> +**Internal labeling** - This is where network objects are labeled and
> +managed internally within a single machine (i.e. their labels are not
> +transmitted as part of the session with remote systems). There are two
> +types supported: SECMARK and NetLabel. There was a service known as
> +'compat_net' controls, however that was removed in kernel 2.6.30.

Using your terminology, NetLabel is external or "labeled networking".

NetLabel is a framework for explicit network labeling that abstracts
away the underlying labeling protocol from the LSMs.  It provides
CIPSO, CALIPSO, and fallback/static protocol support to SELinux (and
Smack).

> +**Labeled Networking** - This is where labels are passed to/from remote
> +systems where they can be interpreted and a MAC policy enforced on each
> +system. There are three types supported: Labeled IPSec, CIPSO
> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
> +IPv6 Security Option).
> +
> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
> +the NetLabel tools need to be installed:

Paul Moore July 28, 2020, 2:49 a.m. UTC | #8

On Mon, Jul 27, 2020 at 9:57 AM Dominick Grift
<[e-mail]> wrote:
>
> Probably nothing but I did not understand this: Is reception not
> controlled with the netif ingress permission?

Yes, the netif/ingress and node/recvfrom permissions are checked when
packets are received; in both cases the subject is the peer labels
(think the security context of the remote network peer) and the
objects are the network interface's label or network node's label,
respectively.

This is pretty old, almost twelve years old, but it should still be accurate:
* https://www.paul-moore.com/blog/d/2008/12/network_ingress_egress_controls.html

Paul Moore July 28, 2020, 2:57 a.m. UTC | #9

On Mon, Jul 27, 2020 at 11:39 AM Dominick Grift
<[e-mail]> wrote:
> Topi Miettinen <[e-mail]> writes:
> > I'm no expert, but the only netif ingress rules which I have are
> > rather generic:
> >
> > allow internet_peer_t external_if_t:netif ingress;
> > allow link_local_peer_t external_if_t:netif ingress;
> > allow localnet_peer_t external_if_t:netif ingress;
> > allow multicast_peer_t external_if_t:netif ingress;
> > allow loopback_peer_t loopback_if_t:netif ingress;
> >
> > `peer` types above have been added with NetLabel rules like:
> >
> > netlabelctl unlbl add default address:2000::/3
> > label:system_u:object_r:internet_peer_t:s0
> >
> > Perhaps this would be better:
> >
> > Note that reception for application domains can't be controlled with
> > `netif` class.
> >
>
> I look at it this way: peers *are* processes, You seem to
> essentually use peers as nodes above.

Peer labels are essentially process labels (that isn't 100% correct,
but it is close enough for this particular discussion).

In the netif/ingress access control, the subject is the peer label of
the *remote* peer, not the receiving process on the local system.  If
you were running a web server on your system under httpd_t and a
remote node connected to your web server with firefox running under
firefox_t, you would need the following netif/ingress rule:

  allow firefox_t external_if_t:netif ingress;

You will note that it is firefox_t and *not* httpd_t as the subject.

> It would become more clear if you would try this out with labeled ipsec.
> A peer, in my experience is kind of the same as an association in the
> labeled ipsec scenario (the classes actually overlap). That is also why
> you should probably disable the netlabel_peer_controls polcap if you use
> labeled ipsec.

Paul Moore July 28, 2020, 3:08 a.m. UTC | #10

On Mon, Jul 27, 2020 at 4:36 PM Dominick Grift
<[e-mail]> wrote:
> The thing, i think, is that netlabel is limited and really geared
> towards MLS, it will only send levels over the wire i believe (except for loopback)
>
> By AFAIK the point of netlabel is to be able enforce mult-level security
> on secure networks. For example you could have a ssh server running on a
> particular level. In other words netlabel AFAIK should be able to send a
> process/peer level over the network AFAIK.

The original motivation behind NetLabel was to provide an
interoperable labeled networking mechanism that would allow SELinux to
talk to (at the time) existing trusted UNIX systems such as Trusted
Solaris.  The NetLabel framework abstraction was created both to be
able to support multiple different labeling protocols (CIPSO, CALIPSO,
fallback/static) as well as to support multiple LSMs (SELinux, Smack).

Beyond this, we start getting into a bit of a rathole of comparing
network labeling designs and implementations which gets very ugly,
very quickly.

Paul Moore July 28, 2020, 3:12 a.m. UTC | #11

On Mon, Jul 27, 2020 at 5:44 PM Topi Miettinen <[e-mail]> wrote:
> MLS is not very interesting for users in general and so neither will be
> CIPSO/CALIPSO. Maybe labeled IPSec could be useful in some controlled
> corporate environments where all parties are relatively trusted.

Don't forget that in most cases when you see "MLS" in the context of
SELinux, you should think "MLS" or "MCS".  While MLS may have limited
interest outside of a few specific types of users, MCS is what
underpins SELinux's virtualization and container security for most
users.

Topi Miettinen July 28, 2020, 10:30 a.m. UTC | #12

On 28.7.2020 5.44, Paul Moore wrote:
> On Mon, Jul 27, 2020 at 9:04 AM Topi Miettinen <[e-mail]> wrote:
>>
>> List all access control methods available for networking and provide
>> examples for each.
>>
>> Signed-off-by: Topi Miettinen <[e-mail]>
>>
>> ---
>> v2: address comments from Richard Haines
>> ---
>>   src/network_statements.md |   2 +-
>>   src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
>>   2 files changed, 150 insertions(+), 22 deletions(-)
>>
>> diff --git a/src/network_statements.md b/src/network_statements.md
>> index ef1c873..357c3b1 100644
>> --- a/src/network_statements.md
>> +++ b/src/network_statements.md
>> @@ -102,7 +102,7 @@ the interface to a security context.
>>   <tr>
>>   <td><code>packet_context</code></td>
>>   <td><p>The security context allocated packets. Note that these are defined but unused.</p>
>> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
>> +<p>The iptables(8)/nftables(8) <a href="network_support.md#internal-labeling-secmark">SECMARK services</a> should be used to label packets.</p></td>
>>   </tr>
>>   </tbody>
>>   </table>
>> diff --git a/src/network_support.md b/src/network_support.md
>> index 309e863..6f9896b 100644
>> --- a/src/network_support.md
>> +++ b/src/network_support.md
>> @@ -1,20 +1,17 @@
>>   # SELinux Networking Support
>>
>> -SELinux supports the following types of network labeling:
>> +SELinux supports several methods for access control of networks. These are
>>
>> -**Internal labeling** - This is where network objects are labeled and
>> -managed internally within a single machine (i.e. their labels are not
>> -transmitted as part of the session with remote systems). There are two
>> -types supported: SECMARK and NetLabel. There was a service known as
>> -'compat_net' controls, however that was removed in kernel 2.6.30.
>> +* Packet labeling: class `packet`
>> +* Peer labeling: class `peer`
>> +* Interface control: class `netif`
>> +* Network node control: class `node`
>> +* TCP/UDP/SCTP/DCCP ports: class `port`
> 
> For whatever it is worth, I've always thought of the SELinux network
> access controls as being composed of two parts: socket layer controls
> and packet layer controls (or per-packet controls).  The packet layer
> controls are further divided into the "peer" and "secmark" controls.

This could be a more easily understandable way to describe the access 
controls, at least `port` would fall to socket layer controls nicely. 
Would this division work with netifs and nodes?

> The socket layer controls are the access controls which closely mimic
> the socket syscalls and typically involve checking if a running task
> can perform an operation on a network socket, e.g. bind().  These are
> usually easy to understand and don't require any special network
> configuration.
> 
> The packet layer controls are where things start to get interesting as
> this is where we apply SELinux security policy to individual packets
> as they flow into, out of, and through the system.  As mentioned
> above, the packet layer controls are comprised of both "peer" and
> "secmark" controls.  The "peer" controls are those access controls
> which compare the security attributes (SELinux label) of the sending
> peer with the security context of the receiving peer.  The "secmark"
> controls compare the network attributes (e.g. IP header values) with
> the sending or receiving task's security attributes.  It get's very
> complicated very quickly, but a simple example is to think of the
> "peer" access controls as restricting firefox_t to talking only to
> httpd_t, while the "secmark" access controls restrict firefox_t to
> talking only to network services on TCP port 80.
> 
> Secmark is (obviously) the "secmark" access controls.
> 
> Labeled IPsec and the NetLabel framework are the current "peer" access
> controls, with NetLabel supporting CIPSO for IPv4, CALIPSO for IPv6,
> and a fallback/static labeling for unlabeled IPv4 and IPv6 networks.
> 
>> -**Labeled Networking** - This is where labels are passed to/from remote
>> -systems where they can be interpreted and a MAC policy enforced on each
>> -system. There are three types supported: Labeled IPSec, CIPSO
>> -(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>> -IPv6 Security Option)
>> +Networking support is not enabled by default. It can be enabled either
>> +the policy capabilities or by loading SECMARK rules.
>>
>> -There are two policy capability options that can be set within policy
>> +There are three policy capability options that can be set within policy
>>   using the `policycap` statement that affect networking configuration:
>>
>>   **`network_peer_controls`** - This is always enabled in the latest
>> @@ -37,8 +34,22 @@ The policy capability settings are available in userspace via the
>>   SELinux filesystem as shown in the
>>   [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
>>
>> -To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
>> -be installed:
>> +SELinux supports the following types of network labeling:
>> +
>> +**Internal labeling** - This is where network objects are labeled and
>> +managed internally within a single machine (i.e. their labels are not
>> +transmitted as part of the session with remote systems). There are two
>> +types supported: SECMARK and NetLabel. There was a service known as
>> +'compat_net' controls, however that was removed in kernel 2.6.30.
> 
> Using your terminology, NetLabel is external or "labeled networking".

It's not my terminology, the text is just moved down. I think 
fallback/static labeling part of NetLabel is not external, the labeling 
happens internally and the labels are not transmitted.

-Topi

> NetLabel is a framework for explicit network labeling that abstracts
> away the underlying labeling protocol from the LSMs.  It provides
> CIPSO, CALIPSO, and fallback/static protocol support to SELinux (and
> Smack).
> 
>> +**Labeled Networking** - This is where labels are passed to/from remote
>> +systems where they can be interpreted and a MAC policy enforced on each
>> +system. There are three types supported: Labeled IPSec, CIPSO
>> +(Commercial IP Security Option) and CALIPSO (Common Architecture Label
>> +IPv6 Security Option).
>> +
>> +To support peer labeling with CIPSO and CALIPSO or fallback labeling,
>> +the NetLabel tools need to be installed:
>

Paul Moore July 28, 2020, 10 p.m. UTC | #13

On Tue, Jul 28, 2020 at 6:30 AM Topi Miettinen <[e-mail]> wrote:
> On 28.7.2020 5.44, Paul Moore wrote:
> > On Mon, Jul 27, 2020 at 9:04 AM Topi Miettinen <[e-mail]> wrote:
> >>
> >> List all access control methods available for networking and provide
> >> examples for each.
> >>
> >> Signed-off-by: Topi Miettinen <[e-mail]>
> >>
> >> ---
> >> v2: address comments from Richard Haines
> >> ---
> >>   src/network_statements.md |   2 +-
> >>   src/network_support.md    | 170 +++++++++++++++++++++++++++++++++-----
> >>   2 files changed, 150 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/src/network_statements.md b/src/network_statements.md
> >> index ef1c873..357c3b1 100644
> >> --- a/src/network_statements.md
> >> +++ b/src/network_statements.md
> >> @@ -102,7 +102,7 @@ the interface to a security context.
> >>   <tr>
> >>   <td><code>packet_context</code></td>
> >>   <td><p>The security context allocated packets. Note that these are defined but unused.</p>
> >> -<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
> >> +<p>The iptables(8)/nftables(8) <a href="network_support.md#internal-labeling-secmark">SECMARK services</a> should be used to label packets.</p></td>
> >>   </tr>
> >>   </tbody>
> >>   </table>
> >> diff --git a/src/network_support.md b/src/network_support.md
> >> index 309e863..6f9896b 100644
> >> --- a/src/network_support.md
> >> +++ b/src/network_support.md
> >> @@ -1,20 +1,17 @@
> >>   # SELinux Networking Support
> >>
> >> -SELinux supports the following types of network labeling:
> >> +SELinux supports several methods for access control of networks. These are
> >>
> >> -**Internal labeling** - This is where network objects are labeled and
> >> -managed internally within a single machine (i.e. their labels are not
> >> -transmitted as part of the session with remote systems). There are two
> >> -types supported: SECMARK and NetLabel. There was a service known as
> >> -'compat_net' controls, however that was removed in kernel 2.6.30.
> >> +* Packet labeling: class `packet`
> >> +* Peer labeling: class `peer`
> >> +* Interface control: class `netif`
> >> +* Network node control: class `node`
> >> +* TCP/UDP/SCTP/DCCP ports: class `port`
> >
> > For whatever it is worth, I've always thought of the SELinux network
> > access controls as being composed of two parts: socket layer controls
> > and packet layer controls (or per-packet controls).  The packet layer
> > controls are further divided into the "peer" and "secmark" controls.
>
> This could be a more easily understandable way to describe the access
> controls, at least `port` would fall to socket layer controls nicely.

Yes, I personally think it is better way to explain the network access controls.

> Would this division work with netifs and nodes?

I'm not entirely clear on the question, but both the netif/node
ingress and egress controls fall into the packet layer.


> >> -To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
> >> -be installed:
> >> +SELinux supports the following types of network labeling:
> >> +
> >> +**Internal labeling** - This is where network objects are labeled and
> >> +managed internally within a single machine (i.e. their labels are not
> >> +transmitted as part of the session with remote systems). There are two
> >> +types supported: SECMARK and NetLabel. There was a service known as
> >> +'compat_net' controls, however that was removed in kernel 2.6.30.
> >
> > Using your terminology, NetLabel is external or "labeled networking".
>
> It's not my terminology, the text is just moved down.

My apologies, using the *existing* terminology ...

> I think
> fallback/static labeling part of NetLabel is not external, the labeling
> happens internally and the labels are not transmitted.

I guess this is another problem with the "internal" vs "external"
approach to the current text.  I prefer to think in terms of how the
access controls are structured, and as far as SELinux is concerned it
only has to worry about calling the general NetLabel APIs; it doesn't
matter if CIPSO, CALIPSO, or the static/fallback labeling is
concerned, it's all the same.

Things get more complicated if you start digging into individual
protocols.  Look at the different CIPSO tag types, vs the tagless
approach taken in CALIPSO.  Not to mention the way labeled IPsec
works; people get enamored by the encryption/authentication aspects,
but it's really a very poor fit for SELinux.  There are a number of
problems caused by the fact that labeled IPsec is an implicit labeling
mechanism that labels SAs and not packets, there are issues around
ensuring all of the labels have the same (or close enough) meaning on
both systems, and it is likely only to ever work between the SELinux
systems.

Patch

diff --git a/src/network_statements.md b/src/network_statements.md
index ef1c873..357c3b1 100644
--- a/src/network_statements.md
+++ b/src/network_statements.md
@@ -102,7 +102,7 @@  the interface to a security context.
 <tr>
 <td><code>packet_context</code></td>
 <td><p>The security context allocated packets. Note that these are defined but unused.</p>
-<p>The iptables(8)/nftables(8) <a href="network_support.md#secmark">SECMARK services</a> should be used to label packets.</p></td>
+<p>The iptables(8)/nftables(8) <a href="network_support.md#internal-labeling-secmark">SECMARK services</a> should be used to label packets.</p></td>
 </tr>
 </tbody>
 </table>
diff --git a/src/network_support.md b/src/network_support.md
index 309e863..6f9896b 100644
--- a/src/network_support.md
+++ b/src/network_support.md
@@ -1,20 +1,17 @@ 
 # SELinux Networking Support
 
-SELinux supports the following types of network labeling:
+SELinux supports several methods for access control of networks. These are
 
-**Internal labeling** - This is where network objects are labeled and
-managed internally within a single machine (i.e. their labels are not
-transmitted as part of the session with remote systems). There are two
-types supported: SECMARK and NetLabel. There was a service known as
-'compat_net' controls, however that was removed in kernel 2.6.30.
+* Packet labeling: class `packet`
+* Peer labeling: class `peer`
+* Interface control: class `netif`
+* Network node control: class `node`
+* TCP/UDP/SCTP/DCCP ports: class `port`
 
-**Labeled Networking** - This is where labels are passed to/from remote
-systems where they can be interpreted and a MAC policy enforced on each
-system. There are three types supported: Labeled IPSec, CIPSO
-(Commercial IP Security Option) and CALIPSO (Common Architecture Label
-IPv6 Security Option)
+Networking support is not enabled by default. It can be enabled either
+the policy capabilities or by loading SECMARK rules.
 
-There are two policy capability options that can be set within policy
+There are three policy capability options that can be set within policy
 using the `policycap` statement that affect networking configuration:
 
 **`network_peer_controls`** - This is always enabled in the latest
@@ -37,8 +34,22 @@  The policy capability settings are available in userspace via the
 SELinux filesystem as shown in the
 [**SELinux Filesystem**](lsm_selinux.md#selinux-filesystem) section.
 
-To support peer labeling, CIPSO and CALIPSO the NetLabel tools need to
-be installed:
+SELinux supports the following types of network labeling:
+
+**Internal labeling** - This is where network objects are labeled and
+managed internally within a single machine (i.e. their labels are not
+transmitted as part of the session with remote systems). There are two
+types supported: SECMARK and NetLabel. There was a service known as
+'compat_net' controls, however that was removed in kernel 2.6.30.
+
+**Labeled Networking** - This is where labels are passed to/from remote
+systems where they can be interpreted and a MAC policy enforced on each
+system. There are three types supported: Labeled IPSec, CIPSO
+(Commercial IP Security Option) and CALIPSO (Common Architecture Label
+IPv6 Security Option).
+
+To support peer labeling with CIPSO and CALIPSO or fallback labeling,
+the NetLabel tools need to be installed:
 
 `dnf install netlabel_tools`
 
@@ -52,8 +63,12 @@  OpenSwan but is now distributed as LibreSwan:
 `dnf install libreswan`
 
 It is important to note that the kernel must be configured to support
-these services. The Fedora kernels are configured to handle all the above
-services.
+these services (`CONFIG_NETLABEL`, `CONFIG_NETWORK_SECMARK`,
+`CONFIG_NF_CONNTRACK_SECMARK`,
+`CONFIG_NETFILTER_XT_TARGET_CONNSECMARK`,
+`CONFIG_NETFILTER_XT_TARGET_SECMARK`, `CONFIG_IP_NF_SECURITY`,
+`CONFIG_IP6_NF_SECURITY`). At least Fedora and Debian kernels are
+configured to handle all the above services.
 
 The Linux networking package *iproute* has an SELinux aware socket
 statistics command ***ss**(8)* that will show the SELinux context of
@@ -65,7 +80,7 @@  to achieve this).
 
 <br>
 
-## SECMARK
+## Internal labeling: SECMARK
 
 SECMARK makes use of the standard kernel NetFilter framework that
 underpins the GNU / Linux IP networking sub-system. NetFilter services
@@ -73,7 +88,7 @@  automatically inspects all incoming and outgoing packets and can place
 controls on interfaces, IP addresses (nodes) and ports with the added
 advantage of connection tracking. The SECMARK security extensions allow
 security contexts to be added to packets (SECMARK) or sessions
-(CONNSECMARK).
+(CONNSECMARK), belonging to object class of `packet`.
 
 The NetFilter framework inspects and tag packets with labels as defined
 within ***iptables**(8)* (also 'nftables' ***nft**(8)* from version 9.3 with
@@ -172,6 +187,16 @@  table ip6 security {
 }
 ```
 
+Before the SECMARK rules can be loaded, TE rules must be added to
+define the types, and also allow domains to send and/or receive
+objects of `packet` class:
+
+```
+type test_server_packet_t, packet_type;
+
+allow my_server_t test_server_packet_t:packet { send recv };
+```
+
 The following articles explain the SECMARK service:
 -   [*Transitioning to Secmark*](http://paulmoore.livejournal.com/4281.html)
 -   [New secmark-based network controls for SELinux](http://james-morris.livejournal.com/11010.html)
@@ -179,7 +204,7 @@  The following articles explain the SECMARK service:
 
 <br>
 
-## NetLabel - Fallback Peer Labeling
+## Internal labeling: NetLabel - Fallback Peer Labeling
 
 Fallback labeling can optionally be implemented on a system if the
 Labeled IPSec or CIPSO/CALIPSO is not being used (hence 'fallback
@@ -217,9 +242,20 @@  netlabelctl -p map list
 Note that the security contexts must be valid in the policy otherwise the
 commands will fail.
 
+Before the NetLabel rules can be loaded, TE rules must be added to
+define the types. Then the rules can allow domains to receive data
+from objects of `peer` class:
+
+```
+type netlabel_sctp_peer_t;
+
+allow my_server_t netlabel_sctp_peer_t:peer recv;
+```
+Note that sending can't be controlled with `peer` class.
+
 <br>
 
-## NetLabel – CIPSO/CALIPSO
+## Labeled Networking: NetLabel – CIPSO/CALIPSO
 
 To allow MLS [**security levels**](mls_mcs.md#security-levels) to be passed
 over a network between MLS
@@ -288,7 +324,7 @@  section, plus the standard Fedora 'targeted' policy for the tests.
 
 <br>
 
-## Labeled IPSec
+## Labeled Networking: Labeled IPSec
 
 Labeled IPSec has been built into the standard GNU / Linux IPSec
 services as described in the
@@ -451,6 +487,98 @@  The *selinux-testsuite tools/nfs.sh* tests labeled NFS using various labels.
 
 <br>
 
+## Access Control for Network Interfaces
+
+SELinux domains can be restricted to use only specific network
+interfaces. TE rules must define the interface types and then allow a
+domain to `egress` in class `netif` for the defined interface types:
+
+```
+require {
+        attribute netif_type;
+}
+
+type external_if_t, netif_type;
+type loopback_if_t, netif_type;
+
+allow my_server_t external_if_t:netif egress;
+allow my_server_t loopback_if_t:netif egress;
+```
+
+The interfaces must also be labeled with ***semanage**(8)* (or by
+using `netifcon` statements in the policy):
+```
+semanage interface -a -t loopback_if_t -r s0 lo
+semanage interface -a -t external_if_t -r s0 eth0
+```
+
+Note that reception can't be controlled with `netif` class.
+
+<br>
+
+## Access Control for Network Nodes
+
+Domains can be restricted by SELinux to access and bind sockets to
+only dedicated network nodes (in practice, IP addresses).
+
+The node types must be defined and then the node types can be used for
+TE rules as target context. TE rules to allow a domain to `sendto` for
+class `node` and to `node_bind` (for incoming connections) for class
+`tcp_socket`:
+
+```
+require {
+        attribute node_type;
+}
+
+type loopback_node_t, node_type;
+type internet_node_t, node_type;
+type link_local_node_t, node_type;
+type multicast_node_t, node_type;
+
+allow my_server_t loopback_node_t:node sendto;
+allow my_server_t loopback_node_t:tcp_socket node_bind;
+allow my_server_t internet_node_t:node sendto;
+```
+
+After the types have been defined, corresponding node rules can be
+added with `semanage` (or `nodecon` statements):
+```
+semanage node -a -M /128 -p ipv6 -t loopback_node_t -r s0 ::1
+semanage node -a -M /3 -p ipv6 -t internet_node_t -r s0 2000::
+semanage node -a -M /8 -p ipv6 -t link_local_node_t -r s0 fe00::
+semanage node -a -M /8 -p ipv6 -t multicast_node_t -r s0 ff00::
+```
+
+<br>
+
+## Access Control for Network Ports
+
+SELinux policy can also control access to ports used by various
+networking protocols such as TCP, UDP, SCTP and DCCP. TE rules must
+define the port types and then allow a domain to `name_connect`
+(outgoing) or `name_bind` (incoming) in class `tcp_socket` (or
+`udp_socket` etc) for the defined port types:
+
+```
+require {
+        attribute port_type;
+}
+
+type my_server_port_t, port_type;
+
+allow my_server_t my_server_port_t:tcp_socket name_connect;
+allow my_server_t my_server_port_t:tcp_socket name_bind;
+```
+
+The ports must also be labeled with `semanage` (or `portcon`
+statements):
+```
+semanage port -a -t my_server_port_t -p tcp -r s0 12345
+```
+
+<br>
+
 <section class="footnotes">
 <ol>
 <li id="fnn1"><p>For example, an ftp session where the server is listening on a specific port (the destination port) but the client will be assigned a random source port. The CONNSECMARK will ensure that all packets for the ftp session are marked with the same label.<a href="#fnnet1" class="footnote-back">↩</a></p></li>