Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Chuck Lever <chuck.lever@oracle.com>]

On 5/14/25 5:47 PM, NeilBrown wrote:
> On Wed, 14 May 2025, Chuck Lever wrote:
>> On 5/14/25 7:43 AM, NeilBrown wrote:
>>> On Wed, 14 May 2025, Jeff Layton wrote:
>>>> On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote:
>>
>>>> True. Anyone relying on this "protection" is fooling themselves though.
>>>
>>> As above: in some circumstances with physically secure networks
>>> (entirely in a locked room, or entire in a virtualisation host, or a
>>> VPN) it makes perfect sense.
>>
>> On a physically secure network where all the hosts are also known to be
>> secure, source port checking is wholly superfluous. It makes no sense
>> there.
> 
> No, that is the only place that it makes sense.
> 
> If you have a secure network of secure machines running a secure
> configuration of secure software managed by secure administrators, then
> you can trust that a low port number comes from secure software and,
> in particular, that the UID in the AUTH_SYS credential is reliable.
> 
> If you don't have that security, then you cannot trust the port number
> or the uid and should not be accepting AUTH_SYS at all.
> 
> If you *Do* have that security, then we can discuss if the "secure" or
> "insecure" flag is appropriate.  If you know that all processes running
> on all nodes in the network are secure, and will only do what the admins
> let them do, then there is no need for "secure" with its restrictions,
> and "insecure" is perfectly fine.  However if you allow lower-privileged
> processes - maybe you have a login server, or you let people upload their
> own cgi scripts to the web server - then "secure" is important to ensure
> users only access file that their uid has access to.
> 
>>
>>
>>>>>> I don't see any really motivation for this change.  Could you provide it
>>>>>> please?
>>>>>
>>>>> Or to put it another way: who benefits?
>>>>>
>>>>
>>>> Anyone running NFS clients behind NAT?
>>>
>>> Maybe that should have been in the commit message?
>>
>> Agreed, the commit message should have more beef (sorry, vegetarians).
>>
>> The commit message should also mention that NFS clients frequently
>> exhaust their privileged source port range, causing new mount
>> operations to fail sporadically. This is a well-documented problem
>> and the main reason we started moving Kerberized mounts to ephemeral
>> ports.
>>
>> Generally that's a situation that is sticky for a couple of minutes
>> while TCP sockets proceed through TIME_WAIT until the source port can
>> be re-used by another connection.
>>
>>
>>>> The main discussion came about when we were testing against a
>>>> hammerspace deployment. They were using knfsd as their DS's, and had
>>>> forgotten to add "insecure" to the export options. When the (NAT'ed)
>>>> client tried to talk to the DS's, it got back NFSERR3_PERM because of
>>>> this. It took a little while to ascertain the cause.
>>>
>>> "Change default to fix configuration problem"....???
>>> The default must always be the more secure.  "fail safe".
>>
>> Sure, but this option, although it's name is "secure", offers very
>> little real security. So we are actively promoting a mythological level
>> of security here, and that is a Bad Thing (tm).
> 
> "very little" is not zero.  "mythological" is unfair.  There is real
> security is certain specific situations.

We can argue about "mythological", but it is totally fair to say that
calling this mechanism "secure", and its inverse "insecure" is an
overreach and a gross misrepresentation. It is relevant only for
AUTH_UNIX and only then when there are other active forms of security
in place.

So I think our fundamental point is that the balance has changed. These
days, in most situations, source port checking is not relevant and is
actively inconvenient for many common usage scenarios.

Before changing the default behavior of NFSD, we can survey other common
network storage protocol implementations (iSCSI, NVMe, SMB) to see if
those protocols also use this form of authorizing access.

In the meantime, do you object to moving forward with the other two
suggestions I made:

 - Updating the description of the "secure" export option in exports(5)

 - Adding a warning to exportfs when an export has neither "secure" or
   "insecure" set and allows access via sec=sys ?


-- 
Chuck Lever