selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: <selinux@vger.kernel.org>
Subject: Re: [PATCH v3] Improve network_support.md
Date: Mon, 10 Aug 2020 09:48:00 -0400	[thread overview]
Message-ID: <173d8a0be80.27df.85c95baa4474aabc7814e68940a78392@paul-moore.com> (raw)
In-Reply-To: <7db33d9d-f0eb-40f9-2f2a-19db07d71963@gmail.com>

[Apologies for top posting]

Hi,

Thanks for thinking of that, but it's not necessary; you have been the one doing the work and updating the text, I'm just providing some review and feedback :)

I see you posted an updated draft - thanks. My time is limited this week, so I may not be able to properly review it until next week, but Stephen, Petr, and James have agreed to help maintain The Notebook in GitHub so they may be able to help provide some review and/or merge the patch.

--
paul moore
www.paul-moore.com
On August 9, 2020 3:38:44 AM Topi Miettinen <toiwoton@gmail.com> wrote:

> 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-10 13:48 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
2020-08-10 13:48     ` Paul Moore [this message]

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=173d8a0be80.27df.85c95baa4474aabc7814e68940a78392@paul-moore.com \
    --to=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=toiwoton@gmail.com \
    /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).