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` > -- paul moore www.paul-moore.com
