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