On Tue, Jul 28, 2020 at 6:30 AM Topi Miettinen <toiwoton@xxxxxxxxx> wrote: > 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. 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. -- paul moore www.paul-moore.com
