Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1600f24c-70fb-15f3-029a-7152d8225437@schaufler-ca.com>
Date:   Fri, 5 May 2023 09:54:07 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: NFS mount fail
Content-Language: en-US
To:     Paul Moore <paul@paul-moore.com>
Cc:     Roberto Sassu <roberto.sassu@huaweicloud.com>,
        linux-security-module@vger.kernel.org, linux-nfs@vger.kernel.org,
        chuck.lever@oracle.com, jlayton@kernel.org,
        Casey Schaufler <casey@schaufler-ca.com>
References: <1923bc2f330f576cd246856f976af448c035d02e.camel@huaweicloud.com>
 <d34c30ba-55cc-8662-3587-bb66e234b714@schaufler-ca.com>
 <CAHC9VhQu7GQ54H0k=C8ZWU-5zOX35QNWrBMEyNTE1AU_e8DcPQ@mail.gmail.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
In-Reply-To: <CAHC9VhQu7GQ54H0k=C8ZWU-5zOX35QNWrBMEyNTE1AU_e8DcPQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 5/5/2023 7:03 AM, Paul Moore wrote:
> On Thu, May 4, 2023 at 9:00 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 5/4/2023 9:11 AM, Roberto Sassu wrote:
>>> Hi Casey
>>>
>>> while developing the fix for overlayfs, I tried first to address the
>>> issue of a NFS filesystem failing to mount.
>>>
>>> The NFS server does not like the packets sent by the client:
>>>
>>> 14:52:20.827208 IP (tos 0x0, ttl 64, id 60628, offset 0, flags [DF], proto TCP (6), length 72, options (unknown 134,EOL))
>>>     localhost.localdomain.omginitialrefs > _gateway.nfs: Flags [S], cksum 0x7618 (incorrect -> 0xa18c), seq 455337903, win 64240, options [mss 1460,sackOK,TS val 2178524519 ecr 0,nop,wscale 7], length 0
>>> 14:52:20.827376 IP (tos 0xc0, ttl 64, id 5906, offset 0, flags [none], proto ICMP (1), length 112, options (unknown 134,EOL))
>>>     _gateway > localhost.localdomain: ICMP parameter problem - octet 22, length 80
>>>
>>> I looked at the possible causes. SELinux works properly.
>> SELinux was the reference LSM implementation for labeled networking.
>>
>>> What it seems to happen is that there is a default netlabel mapping,
>>> that is used to send the packets out.
>> Correct. SELinux only uses CIPSO options for MLS.
> SELinux can use the NetLabel/CIPSO "local" configuration to send a
> full SELinux labels over a loopback connection.

True enough. As you point out below, that's an advanced configuration
option. A typical SELinux system isn't going to be set up that way.

> * https://www.paul-moore.com/blog/d/2012/06/cipso_loopback_full_labels.html
>
> There are several differences between how SELinux and Smack implement
> labeled networking, one of the larger differences is that SELinux
> leaves the labeling configuration, e.g. which networks/interfaces are
> labeled and how, as a separate exercise for the admin whereas the
> labeling configuration is much more integrated with Smack.

Which is consistent with the general approach of the two systems.

> I wouldn't say one approach is better than the other, they are simply
> different.  

Agreed, for the most part.

> The SELinux approach provides for the greatest amount of
> flexibility with the understanding that more work needs to be done by
> the admin. The Smack approach provides a quicker path to getting a
> system up and running, but it is less flexible for challenging/mixed
> network environments.

Smack does have knobs and levers for setting some network attributes,
and netlabelctl can be useful in certain cases. Smack could take better
advantage of the netlabel capabilities than it does.

> There are other issues around handling IPv6,

Smack CALIPSO support (to replace the existing IPv6 handling) is on
the short list. When that gets done depends on many factors.

>  the sockets-as-objects
> debate, etc. but those shouldn't be relevant to this discussion.

Agreed.