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

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

On 6/4/25 1:12 PM, Cedric Blancher wrote:
> On Tue, 13 May 2025 at 18:12, Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On 5/13/25 11:14 AM, Lionel Cons wrote:
>>> On Tue, 13 May 2025 at 15:50, Jeff Layton <jlayton@kernel.org> wrote:
>>>>
>>>> Back in the 80's someone thought it was a good idea to carve out a set
>>>> of ports that only privileged users could use. When NFS was originally
>>>> conceived, Sun made its server require that clients use low ports.
>>>> Since Linux was following suit with Sun in those days, exportfs has
>>>> always defaulted to requiring connections from low ports.
>>>>
>>>> These days, anyone can be root on their laptop, so limiting connections
>>>> to low source ports is of little value.
>>>>
>>>> Make the default be "insecure" when creating exports.
>>>>
>>>> Signed-off-by: Jeff Layton <jlayton@kernel.org>
>>>> ---
>>>> In discussion at the Bake-a-thon, we decided to just go for making
>>>> "insecure" the default for all exports.
>>>
>>> This patch is one of the WORST ideas in recent times.
>>>
>>> While your assessment might be half-true for the average home office,
>>> sites like universities, scientific labs and enterprise networks
>>> consider RPC traffic being restricted to a port below 1024 as a layer
>>> of security.
>>>
>>> The original idea was that only trusted people have "root" access, and
>>> only uid=0/root can allocate TCP ports below 1024.
>>> That is STILL TRUE for universities and other sides, and I think most
>>> admins there will absolutely NOT appreciate that you disable a layer
>>> of security just to please script kiddles and wanna-be hackers.
>>>
>>> I am going to fight this patch, to the BITTER end, with blood and biting.
>>
>> Lionel, your combative attitude is not helpful. You clearly did not read
>> Jeff's patch, nor do you understand how network security is implemented.
>> Checking the source port was long ago deemed completely useless, no more
>> secure than ROT13. Solaris NFS servers have not checked the client's
>> source port for many many years, for example.
>>
>> Most of the contributors and maintainers here were first employed by
>> universities. We're well aware of the security requirements in those
>> environments and how university IT departments meet those requirements.
>> Any environment that requires security uses a solution based on
>> cryptography, such as Kerberos or TLS.
> 
> I wouldn't even dare to mention TLS here. TLS is mostly experimental
> at best, and its performance is so bad that enforcing it might finally
> ruin the Linux NFS client+server reputation.
> 
> In that context, TLS is not an option, unless performance, latency
> sensitivity and CPU usage can be improved by at least a factor of 5.
> Yes, factor FIVE, because TLS is that BAD.

I've heard this claim several times now with no reference to actual
data. I do accept the claim that NFS on an ssh tunnel is going to be
pretty awful. I don't accept the subtext that NFS over TLS will /always/
be terrible for the rest of time. (and note that QUIC is coming, and
for QUIC, transport-layer encryption is always on -- this problem has
to be solved).

We can't begin to address problems that we don't know about. Can you
cite a study or give us a reproducer? Was testing done with a NIC
capable of offloading the TLS record protocol (on both ends)? Flame
graphs to show us where the CPU bottlenecks are? How does the
performance of NFS on TLS compare with krb5p ? I would greatly
appreciate seeing careful studies of the problems.

Lastly, there are plenty of light workloads where TLS is a more
operational choice than Kerberos. It's fair to exclude intensive
workloads for now, but those are not the only workloads being run on
NFS.


> I only agree to this change because Solaris did change it long ago,
> but even then it was a highly disputed change, and today's
> universities still prefer the "resvport"
> 
> Ced


-- 
Chuck Lever