On Sat, Aug 1, 2020 at 5:26 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
v3: address comments from Paul Moore
---
src/network_statements.md | 2 +-
src/network_support.md | 225 ++++++++++++++++++++++++++++++++++----
2 files changed, 207 insertions(+), 20 deletions(-)
diff --git a/src/network_statements.md b/src/network_statements.md
index ef1c873..a2213d4 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#packet-controls-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..e3101ee 100644
--- a/src/network_support.md
+++ b/src/network_support.md
@@ -1,20 +1,51 @@
# SELinux Networking Support
-SELinux supports the following types of network labeling:
+SELinux controls network access in kernel at two locations: at the
"in the kernel"
+socket interface, and when packets are processed by the protocol
+stacks. Controls at socket interface are invoked when a task makes
"at the socket interface"
+network related system calls and thus the access permission checks
+mimic the sockets programming interface (e.g. ***bind**(2)*
+vs. `node_bind`). Packet controls are more distant from applications
+and they are invoked whenever any packets are received, forwarded or
+sent.
+
+Packet level controls include:
+* Packet labeling with SECMARK: class `packet`
+* Peer labeling with Labeled IPSec or NetLabel: class `peer`
+* Interface control: class `netif`
+* Network node control: class `node`
+
+Controls at socket interface include:
+* TCP/UDP/SCTP/DCCP ports: class `port`
+
+Packet controls can be organized further according to the source of
+the label for the packets, which can be internal or external:
**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
+types supported: SECMARK and NetLabel. As an example, SECMARK access
Instead of just "NetLabel" here we should probably give some
indication that this is NetLabel with the static/fallback "protocol".
+controls could restrict `firefox_t` to talking only to network
+services on TCP port 80 while NetLabel fallback/static rules could
+restrict `firefox_t` to only receive data from specific IP addresses
+on a specific network interface. There was a service known as
'compat_net' controls, however that was removed in kernel 2.6.30.
I wonder if it is even worth mentioning compat_net here, without any
explanation of the controls it just seems confusing.
2.6.30 was released over 11 years ago.
**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)
+IPv6 Security Option). With labeled networking, it's possible to
Similar to my comments above, there should be some indication of
NetLabel here, e.g. "NetLabel/CIPSO"; I fear this will be confusing
otherwise.
+compare the security attributes (SELinux label) of the sending peer
+with the security context of the receiving peer. A simple example with
+Labeled IPSec is restricting `firefox_t` to talking only to `httpd_t`,
+while CIPSO/CALIPSO could restrict domains with MLS security level
+`s32` not to talk with domains with level `s31`.
-There are two policy capability options that can be set within policy
+Networking support is not enabled by default. It can be enabled either
+the policy capabilities or by loading SECMARK rules.
It may be more accurate to say that the SELinux network access
controls are not enforced by default; they must first be configured or
forced on by the "always_check_network" policy capability.
+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 +68,14 @@ 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:
+NetLabel is a framework for explicit network labeling that abstracts
+away the underlying labeling protocol from the LSMs. Labeled IPsec and
+the NetLabel framework are the current access controls for class
+`peer`, with NetLabel supporting CIPSO for IPv4, CALIPSO for IPv6, and
+a fallback/static labeling for unlabeled IPv4 and IPv6 networks.
It seems like it might be better to move this explanation closer to
the top of this section.
+To support peer labeling with CIPSO and CALIPSO or fallback labeling,
+the NetLabel tools need to be installed:
`dnf install netlabel_tools`
