Re: [PATCH v2] Improve network_support.md

[Topi Miettinen <toiwoton@gmail.com>]

On 28.7.2020 5.44, Paul Moore wrote:
> On Mon, Jul 27, 2020 at 9:04 AM Topi Miettinen <toiwoton@gmail.com> wrote:
>>
>> List all access control methods available for networking and provide
>> examples for each.
>>
>> Signed-off-by: Topi Miettinen <toiwoton@gmail.com>
>>
>> ---
>> 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:
>