selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).