From: Topi Miettinen <toiwoton@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: selinux@vger.kernel.org
Subject: Re: [PATCH v3] Improve network_support.md
Date: Sun, 9 Aug 2020 10:38:41 +0300 [thread overview]
Message-ID: <7db33d9d-f0eb-40f9-2f2a-19db07d71963@gmail.com> (raw)
In-Reply-To: <CAHC9VhRACosseuAM9f17EkcFJ=RzvZ3A6f3vpjkEBfo8RN8GpQ@mail.gmail.com>
On 6.8.2020 6.32, Paul Moore wrote:
> On Sat, Aug 1, 2020 at 5:26 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
>> 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`
>>
>
Thanks for the comments. Perhaps there should be your Signed-off-by line
too since the patch has a lot of text which was actually written by you,
so I don't take credit from your work?
-Topi
next prev parent reply other threads:[~2020-08-09 7:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-01 9:26 [PATCH v3] Improve network_support.md Topi Miettinen
2020-08-06 3:32 ` Paul Moore
2020-08-09 7:38 ` Topi Miettinen [this message]
2020-08-10 13:48 ` Paul Moore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7db33d9d-f0eb-40f9-2f2a-19db07d71963@gmail.com \
--to=toiwoton@gmail.com \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).