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

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

On 5/15/25 5:44 PM, NeilBrown wrote:
> On Thu, 15 May 2025, Chuck Lever wrote:
>> On 5/14/25 5:47 PM, NeilBrown wrote:
>>> On Wed, 14 May 2025, Chuck Lever wrote:
>>>>
>>>> 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.
> 
> I don't think it is relevant what other protocols do.  If we were adding
> a new feature, then examining the state of the art would make sense, but
> that is not what is happening here.
> 
> It might make sense to remove AUTH_SYS support in the same way that
> rlogin and rsh have effectively been removed and replaced by ssh.

The point of TLS is to protect the use of AUTH_SYS, because as Martin
points out, Kerberos is challenging to deploy. I don't believe support
for AUTH_SYS is something we can get rid of, and the nfsv4 WG has
recognized this reality with the publication of RFC 9289.

With TLS, not only is the use of cleartext user identity encrypted, but
when mtls is in use, we have client peer authentication, which serves
the same purpose as source port checking, but does so with
cryptography.


> It
> would never have made sense to change rlogind to stop checking the
> source port of the TCP connection (and would never have made sense for
> sshd to check it).
> 
> I cannot ever see any justification for changing defaults to make a
> service less secure.

I do not disagree at all with that general philosophy.

I think where you and I disagree is in how much actual security that
source port checking actually confers.


>> 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 ?
> 
> Those two sound like very sensible changes.

Fair enough. We'll focus on improving the man page text for now.


-- 
Chuck Lever