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

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

[Jeff Layton]

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.
---
 support/nfs/exports.c      | 7 +++++--
 utils/exportfs/exports.man | 4 ++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/support/nfs/exports.c b/support/nfs/exports.c
index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
--- a/support/nfs/exports.c
+++ b/support/nfs/exports.c
@@ -34,8 +34,11 @@
 #include "reexport.h"
 #include "nfsd_path.h"
 
-#define EXPORT_DEFAULT_FLAGS	\
-  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
+#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
+				 NFSEXP_ROOTSQUASH |	\
+				 NFSEXP_GATHERED_WRITES |\
+				 NFSEXP_NOSUBTREECHECK | \
+				 NFSEXP_INSECURE_PORT)
 
 struct flav_info flav_map[] = {
 	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
--- a/utils/exportfs/exports.man
+++ b/utils/exportfs/exports.man
@@ -180,8 +180,8 @@ understands the following export options:
 .TP
 .IR secure
 This option requires that requests not using gss originate on an
-Internet port less than IPPORT_RESERVED (1024). This option is on by default.
-To turn it off, specify
+Internet port less than IPPORT_RESERVED (1024). This option is off by default
+but can be explicitly disabled by specifying
 .IR insecure .
 (NOTE: older kernels (before upstream kernel version 4.17) enforced this
 requirement on gss requests as well.)

---
base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
change-id: 20250513-master-89974087bb04

Best regards,
-- 
Jeff Layton <jlayton@kernel.org>

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

[Chuck Lever]

On 5/13/25 9:50 AM, Jeff Layton 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>

Reviewed-by: Chuck Lever <chuck.lever@oracle.com>


> ---
> In discussion at the Bake-a-thon, we decided to just go for making
> "insecure" the default for all exports.
> ---
>  support/nfs/exports.c      | 7 +++++--
>  utils/exportfs/exports.man | 4 ++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> --- a/support/nfs/exports.c
> +++ b/support/nfs/exports.c
> @@ -34,8 +34,11 @@
>  #include "reexport.h"
>  #include "nfsd_path.h"
>  
> -#define EXPORT_DEFAULT_FLAGS	\
> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> +				 NFSEXP_ROOTSQUASH |	\
> +				 NFSEXP_GATHERED_WRITES |\
> +				 NFSEXP_NOSUBTREECHECK | \
> +				 NFSEXP_INSECURE_PORT)
>  
>  struct flav_info flav_map[] = {
>  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> --- a/utils/exportfs/exports.man
> +++ b/utils/exportfs/exports.man
> @@ -180,8 +180,8 @@ understands the following export options:
>  .TP
>  .IR secure
>  This option requires that requests not using gss originate on an
> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> -To turn it off, specify
> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> +but can be explicitly disabled by specifying
>  .IR insecure .
>  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>  requirement on gss requests as well.)
> 
> ---
> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> change-id: 20250513-master-89974087bb04
> 
> Best regards,


-- 
Chuck Lever

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

[Lionel Cons]

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

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

[Jeff Layton]

On Tue, 2025-05-13 at 17:14 +0200, 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.
> 

Get your teeth ready then.

Are your university networks segregated such that you have control over
every client? If not, then the current regime of limiting connections
to ports lower than 1024 is absolutely meaningless. As soon as you have
one unmanaged client that can access the server via socket that measure
is easily defeated. Windows machines (for instance) have no such
restriction on opening low ports, and on *nix most users can easily be
root on their own host these days.

Also, if you're that concerned about security, why are you not using
krb5? Note that using gssapi also disables the restriction to low
ports, so I assume you must be using AUTH_UNIX? That's easily spoofable
as well by an unmanaged client.

Finally, I'm not disabling anything. We're simply setting the default
to the value that _most_ users will want to use. If you feel that you
have need to keep preventing inbound connections from ports lower than
1024, you can just set "secure" on your exports and go about your day.

Cheers,
-- 
Jeff Layton <jlayton@kernel.org>

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

[Chuck Lever]

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.

Jeff can, of course, ably defend his work. The reason I'm responding in
this email thread is to make this general comment to the list:

This mailing list is not a help desk, nor is it a users group, nor is it
a place where you can come and ask for new features without providing a
single use case. This is a discussion list for contributors to the Linux
in-kernel NFS implementation. The active word in that last sentence is
"contributor".

If you can't follow along or do not understand a posting, please do not
respond to it. Or if you must respond, first ask for clarification -- if
something seems outrageous to you, it is highly likely that you do not
understand what you read.

Think carefully before you post on a public mailing list, and please
respect your readers' time and attention.


-- 
Chuck Lever

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

[Cedric Blancher]

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 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
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Chuck Lever]

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

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

[NeilBrown]

On Tue, 13 May 2025, Jeff Layton 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.

But who is going to export any filesystem to their laptop?

> 
> Make the default be "insecure" when creating exports.

So you want to break lots of configurations that are working perfectly
well?

I don't see any really motivation for this change.  Could you provide it
please?

Thanks,
NeilBrown

> 
> 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.
> ---
>  support/nfs/exports.c      | 7 +++++--
>  utils/exportfs/exports.man | 4 ++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> --- a/support/nfs/exports.c
> +++ b/support/nfs/exports.c
> @@ -34,8 +34,11 @@
>  #include "reexport.h"
>  #include "nfsd_path.h"
>  
> -#define EXPORT_DEFAULT_FLAGS	\
> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> +				 NFSEXP_ROOTSQUASH |	\
> +				 NFSEXP_GATHERED_WRITES |\
> +				 NFSEXP_NOSUBTREECHECK | \
> +				 NFSEXP_INSECURE_PORT)
>  
>  struct flav_info flav_map[] = {
>  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> --- a/utils/exportfs/exports.man
> +++ b/utils/exportfs/exports.man
> @@ -180,8 +180,8 @@ understands the following export options:
>  .TP
>  .IR secure
>  This option requires that requests not using gss originate on an
> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> -To turn it off, specify
> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> +but can be explicitly disabled by specifying
>  .IR insecure .
>  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>  requirement on gss requests as well.)
> 
> ---
> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> change-id: 20250513-master-89974087bb04
> 
> Best regards,
> -- 
> Jeff Layton <jlayton@kernel.org>
> 
> 
> 

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

[NeilBrown]

On Wed, 14 May 2025, NeilBrown wrote:
> On Tue, 13 May 2025, Jeff Layton 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.
> 
> But who is going to export any filesystem to their laptop?
> 
> > 
> > Make the default be "insecure" when creating exports.
> 
> So you want to break lots of configurations that are working perfectly
> well?

Sorry - I was wrong.  You aren't breaking working configurations, but
you are removing a protection that people might be expecting.  It might
not be much protection, but it is not zero.

> 
> I don't see any really motivation for this change.  Could you provide it
> please?

Or to put it another way: who benefits?

Thanks,
NeilBrown


> 
> Thanks,
> NeilBrown
> 
> > 
> > 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.
> > ---
> >  support/nfs/exports.c      | 7 +++++--
> >  utils/exportfs/exports.man | 4 ++--
> >  2 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > --- a/support/nfs/exports.c
> > +++ b/support/nfs/exports.c
> > @@ -34,8 +34,11 @@
> >  #include "reexport.h"
> >  #include "nfsd_path.h"
> >  
> > -#define EXPORT_DEFAULT_FLAGS	\
> > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > +				 NFSEXP_ROOTSQUASH |	\
> > +				 NFSEXP_GATHERED_WRITES |\
> > +				 NFSEXP_NOSUBTREECHECK | \
> > +				 NFSEXP_INSECURE_PORT)
> >  
> >  struct flav_info flav_map[] = {
> >  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > --- a/utils/exportfs/exports.man
> > +++ b/utils/exportfs/exports.man
> > @@ -180,8 +180,8 @@ understands the following export options:
> >  .TP
> >  .IR secure
> >  This option requires that requests not using gss originate on an
> > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > -To turn it off, specify
> > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > +but can be explicitly disabled by specifying
> >  .IR insecure .
> >  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> >  requirement on gss requests as well.)
> > 
> > ---
> > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > change-id: 20250513-master-89974087bb04
> > 
> > Best regards,
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 
> > 
> > 
> 
> 
> 

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

[Jeff Layton]

On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote:
> On Wed, 14 May 2025, NeilBrown wrote:
> > On Tue, 13 May 2025, Jeff Layton 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.
> > 
> > But who is going to export any filesystem to their laptop?
> > 
> > > 

The point is that most NFS servers are run on networks where the admin
may not have 100% control over every host on the network. Once you're
that situation, relying on low port values for security is basically
worthless.

> > > Make the default be "insecure" when creating exports.
> > 
> > So you want to break lots of configurations that are working perfectly
> > well?
> 
> Sorry - I was wrong.  You aren't breaking working configurations, but
> you are removing a protection that people might be expecting.  It might
> not be much protection, but it is not zero.
> 

True. Anyone relying on this "protection" is fooling themselves though.

> > 
> > 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?

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.

Note that Solaris' NFS server stopped checking source ports many years
ago. We're only doing this now because we followed suit from how they
behaved in the 90s and never changed it.

> > 
> > Thanks,
> > NeilBrown
> > 
> > > 
> > > 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.
> > > ---
> > >  support/nfs/exports.c      | 7 +++++--
> > >  utils/exportfs/exports.man | 4 ++--
> > >  2 files changed, 7 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > > --- a/support/nfs/exports.c
> > > +++ b/support/nfs/exports.c
> > > @@ -34,8 +34,11 @@
> > >  #include "reexport.h"
> > >  #include "nfsd_path.h"
> > >  
> > > -#define EXPORT_DEFAULT_FLAGS	\
> > > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > > +				 NFSEXP_ROOTSQUASH |	\
> > > +				 NFSEXP_GATHERED_WRITES |\
> > > +				 NFSEXP_NOSUBTREECHECK | \
> > > +				 NFSEXP_INSECURE_PORT)
> > >  
> > >  struct flav_info flav_map[] = {
> > >  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > > --- a/utils/exportfs/exports.man
> > > +++ b/utils/exportfs/exports.man
> > > @@ -180,8 +180,8 @@ understands the following export options:
> > >  .TP
> > >  .IR secure
> > >  This option requires that requests not using gss originate on an
> > > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > > -To turn it off, specify
> > > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > > +but can be explicitly disabled by specifying
> > >  .IR insecure .
> > >  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> > >  requirement on gss requests as well.)
> > > 
> > > ---
> > > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > > change-id: 20250513-master-89974087bb04
> > > 
> > > Best regards,
> > > -- 
> > > Jeff Layton <jlayton@kernel.org>
> > > 
> > > 
> > > 
> > 
> > 
> > 

-- 
Jeff Layton <jlayton@kernel.org>

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

[NeilBrown]

On Wed, 14 May 2025, Jeff Layton wrote:
> On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote:
> > On Wed, 14 May 2025, NeilBrown wrote:
> > > On Tue, 13 May 2025, Jeff Layton 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.
> > > 
> > > But who is going to export any filesystem to their laptop?
> > > 
> > > > 
> 
> The point is that most NFS servers are run on networks where the admin
> may not have 100% control over every host on the network. Once you're
> that situation, relying on low port values for security is basically
> worthless.

"most" ??  Where did you get that statistic?

"Some" are run on in-machine-room networks which are completely
controlled, but which allow local users to log in to unprivileged
accounts.  In this case it makes perfect sense to rely on "privileged"
ports to control access.  If you silently change nfs-utils so that
unprivileged users can have root-level access over NFS, then you are
exposing the file server completely to anyone who can log in to an
server in that local network.  Are you sure you want to do that?

> 
> > > > Make the default be "insecure" when creating exports.
> > > 
> > > So you want to break lots of configurations that are working perfectly
> > > well?
> > 
> > Sorry - I was wrong.  You aren't breaking working configurations, but
> > you are removing a protection that people might be expecting.  It might
> > not be much protection, but it is not zero.
> > 
> 
> 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.

> 
> > > 
> > > 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?

> 
> 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".

If we want to make this configuration problem more easy to detect, maybe
we should log unprivileged port access (beyond the few requests for
which it can make sense).

> 
> Note that Solaris' NFS server stopped checking source ports many years
> ago. We're only doing this now because we followed suit from how they
> behaved in the 90s and never changed it.

I wonder why Sun went out of business.....

Ignoring source ports makes no sense at all unless you enforce some other
authentication, like krb5 or TLS, or unless you *know* that there are no
unprivileged processes running on any client machines.

Thanks,
NeilBrown 


> 
> > > 
> > > Thanks,
> > > NeilBrown
> > > 
> > > > 
> > > > 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.
> > > > ---
> > > >  support/nfs/exports.c      | 7 +++++--
> > > >  utils/exportfs/exports.man | 4 ++--
> > > >  2 files changed, 7 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > > > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > > > --- a/support/nfs/exports.c
> > > > +++ b/support/nfs/exports.c
> > > > @@ -34,8 +34,11 @@
> > > >  #include "reexport.h"
> > > >  #include "nfsd_path.h"
> > > >  
> > > > -#define EXPORT_DEFAULT_FLAGS	\
> > > > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > > > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > > > +				 NFSEXP_ROOTSQUASH |	\
> > > > +				 NFSEXP_GATHERED_WRITES |\
> > > > +				 NFSEXP_NOSUBTREECHECK | \
> > > > +				 NFSEXP_INSECURE_PORT)
> > > >  
> > > >  struct flav_info flav_map[] = {
> > > >  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > > > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > > > --- a/utils/exportfs/exports.man
> > > > +++ b/utils/exportfs/exports.man
> > > > @@ -180,8 +180,8 @@ understands the following export options:
> > > >  .TP
> > > >  .IR secure
> > > >  This option requires that requests not using gss originate on an
> > > > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > > > -To turn it off, specify
> > > > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > > > +but can be explicitly disabled by specifying
> > > >  .IR insecure .
> > > >  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> > > >  requirement on gss requests as well.)
> > > > 
> > > > ---
> > > > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > > > change-id: 20250513-master-89974087bb04
> > > > 
> > > > Best regards,
> > > > -- 
> > > > Jeff Layton <jlayton@kernel.org>
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > 
> 
> -- 
> Jeff Layton <jlayton@kernel.org>
> 

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

[Jeff Layton]

On Wed, 2025-05-14 at 21:43 +1000, NeilBrown wrote:
> On Wed, 14 May 2025, Jeff Layton wrote:
> > On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote:
> > > On Wed, 14 May 2025, NeilBrown wrote:
> > > > On Tue, 13 May 2025, Jeff Layton 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.
> > > > 
> > > > But who is going to export any filesystem to their laptop?
> > > > 
> > > > > 
> > 
> > The point is that most NFS servers are run on networks where the admin
> > may not have 100% control over every host on the network. Once you're
> > that situation, relying on low port values for security is basically
> > worthless.
> 
> "most" ??  Where did you get that statistic?
> 

Anecdotal experience.

> "Some" are run on in-machine-room networks which are completely
> controlled, but which allow local users to log in to unprivileged
> accounts.  In this case it makes perfect sense to rely on "privileged"
> ports to control access.  If you silently change nfs-utils so that
> unprivileged users can have root-level access over NFS, then you are
> exposing the file server completely to anyone who can log in to an
> server in that local network.  Are you sure you want to do that?
> 

These types of environments are vanishingly small these days. If you
have a network of any size, it is _really_ hard to prevent someone from
plugging a laptop or something else into a random network drop.

You can prevent that with 802.1x security, or something similar, but at
that point what is checking the source port going to give you?

> > 
> > > > > Make the default be "insecure" when creating exports.
> > > > 
> > > > So you want to break lots of configurations that are working perfectly
> > > > well?
> > > 
> > > Sorry - I was wrong.  You aren't breaking working configurations, but
> > > you are removing a protection that people might be expecting.  It might
> > > not be much protection, but it is not zero.
> > > 
> > 
> > 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.
> 

Not really. If any host is compromised on your network then this
protection goes out the window.
 
> > 
> > > > 
> > > > 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?
> 

Sure. I can add that and resend.

> > 
> > 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".
> 

The default should also always "just work". We have to balance that
with being secure. There is a reason we don't default to krb5, for
instance. In this case, the added security of checking low port values
by default is pretty worthless. I think we ought to err on the side of
usability.

Also, to be clear, this currently not even enforced in all situations
where TCP is used. iwarp travels over TCP, but using RDMA disables this
check.

> If we want to make this configuration problem more easy to detect, maybe
> we should log unprivileged port access (beyond the few requests for
> which it can make sense).
> 

I don't see any benefit in that at all. If someone wants to do that,
they can get that via tracepoints.

> > 
> > Note that Solaris' NFS server stopped checking source ports many years
> > ago. We're only doing this now because we followed suit from how they
> > behaved in the 90s and never changed it.
> 
> I wonder why Sun went out of business.....
> 

I'm fairly certain that NFS server security had little to do with Sun's
death.

> Ignoring source ports makes no sense at all unless you enforce some other
> authentication, like krb5 or TLS, or unless you *know* that there are no
> unprivileged processes running on any client machines.
> 

Paying attention to source ports makes no sense at all. In the modern
age, all sorts of middleware boxes can change the source port on a
connection. It is essentially meaningless outside of a few tightly
controlled environments. Those environments can always enable "secure"
if they require it.


> > 
> > > > 
> > > > Thanks,
> > > > NeilBrown
> > > > 
> > > > > 
> > > > > 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.
> > > > > ---
> > > > >  support/nfs/exports.c      | 7 +++++--
> > > > >  utils/exportfs/exports.man | 4 ++--
> > > > >  2 files changed, 7 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > > > > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > > > > --- a/support/nfs/exports.c
> > > > > +++ b/support/nfs/exports.c
> > > > > @@ -34,8 +34,11 @@
> > > > >  #include "reexport.h"
> > > > >  #include "nfsd_path.h"
> > > > >  
> > > > > -#define EXPORT_DEFAULT_FLAGS	\
> > > > > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > > > > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > > > > +				 NFSEXP_ROOTSQUASH |	\
> > > > > +				 NFSEXP_GATHERED_WRITES |\
> > > > > +				 NFSEXP_NOSUBTREECHECK | \
> > > > > +				 NFSEXP_INSECURE_PORT)
> > > > >  
> > > > >  struct flav_info flav_map[] = {
> > > > >  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > > > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > > > > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > > > > --- a/utils/exportfs/exports.man
> > > > > +++ b/utils/exportfs/exports.man
> > > > > @@ -180,8 +180,8 @@ understands the following export options:
> > > > >  .TP
> > > > >  .IR secure
> > > > >  This option requires that requests not using gss originate on an
> > > > > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > > > > -To turn it off, specify
> > > > > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > > > > +but can be explicitly disabled by specifying
> > > > >  .IR insecure .
> > > > >  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> > > > >  requirement on gss requests as well.)
> > > > > 
> > > > > ---
> > > > > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > > > > change-id: 20250513-master-89974087bb04
> > > > > 
> > > > > Best regards,
> > > > > -- 
> > > > > Jeff Layton <jlayton@kernel.org>
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > 
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 

-- 
Jeff Layton <jlayton@kernel.org>

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

[NeilBrown]

On Wed, 14 May 2025, Jeff Layton wrote:
> On Wed, 2025-05-14 at 21:43 +1000, NeilBrown wrote:
> > On Wed, 14 May 2025, Jeff Layton wrote:
> > > On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote:
> > > > On Wed, 14 May 2025, NeilBrown wrote:
> > > > > On Tue, 13 May 2025, Jeff Layton 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.
> > > > > 
> > > > > But who is going to export any filesystem to their laptop?
> > > > > 
> > > > > > 
> > > 
> > > The point is that most NFS servers are run on networks where the admin
> > > may not have 100% control over every host on the network. Once you're
> > > that situation, relying on low port values for security is basically
> > > worthless.
> > 
> > "most" ??  Where did you get that statistic?
> > 
> 
> Anecdotal experience.
> 
> > "Some" are run on in-machine-room networks which are completely
> > controlled, but which allow local users to log in to unprivileged
> > accounts.  In this case it makes perfect sense to rely on "privileged"
> > ports to control access.  If you silently change nfs-utils so that
> > unprivileged users can have root-level access over NFS, then you are
> > exposing the file server completely to anyone who can log in to an
> > server in that local network.  Are you sure you want to do that?
> > 
> 
> These types of environments are vanishingly small these days. If you
> have a network of any size, it is _really_ hard to prevent someone from
> plugging a laptop or something else into a random network drop.

In that case you should be disabling AUTH_UNIX, not disabling "secure".


> 
> You can prevent that with 802.1x security, or something similar, but at
> that point what is checking the source port going to give you?
> 
> > > 
> > > > > > Make the default be "insecure" when creating exports.
> > > > > 
> > > > > So you want to break lots of configurations that are working perfectly
> > > > > well?
> > > > 
> > > > Sorry - I was wrong.  You aren't breaking working configurations, but
> > > > you are removing a protection that people might be expecting.  It might
> > > > not be much protection, but it is not zero.
> > > > 
> > > 
> > > 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.
> > 
> 
> Not really. If any host is compromised on your network then this
> protection goes out the window.

If any host is compromised then all protections go out the window.  Let's
make "allsquash,anonuid=0" the default.

> 
> The default should also always "just work". We have to balance that
> with being secure. There is a reason we don't default to krb5, for
> instance. In this case, the added security of checking low port values
> by default is pretty worthless. I think we ought to err on the side of
> usability.

No.  nonononono.  The default should always be secure.  Many things
should be installed inactive and require explicit admin action to
enable.  A tool should "just work".  A service should do nothing unless
explicitly asked.

> 
> Also, to be clear, this currently not even enforced in all situations
> where TCP is used. iwarp travels over TCP, but using RDMA disables this
> check.

And presumably this has always been the case so there is no case of
changing a default that people might be depending on.  So they aren't
particularly relevant.

> 
> > If we want to make this configuration problem more easy to detect, maybe
> > we should log unprivileged port access (beyond the few requests for
> > which it can make sense).
> > 
> 
> I don't see any benefit in that at all. If someone wants to do that,
> they can get that via tracepoints.

You reported that a configuration error was hard to debug.  I suggested
a way to make the configuration error more visible (and hence easier to
debug).  You cannot see the benefit.......  clearly I didn't explain
myself well - sorry.

> > Ignoring source ports makes no sense at all unless you enforce some other
> > authentication, like krb5 or TLS, or unless you *know* that there are no
> > unprivileged processes running on any client machines.
> > 
> 
> Paying attention to source ports makes no sense at all. In the modern
> age, all sorts of middleware boxes can change the source port on a
> connection. It is essentially meaningless outside of a few tightly
> controlled environments. Those environments can always enable "secure"
> if they require it.

But they are currently using the default in the knowledge that it is
"secure" and you want to change the default for *everyone*.

Sure - change the default for yourself if that is what you want.  Update
your script which generates /etc/exports or add some new option to
/etc/nfs.conf, but don't impose your choice on everyone without asking
them (and of course you cannot ask everyone).

NeilBrown

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

[Chuck Lever]

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.


>>>> 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).


> If we want to make this configuration problem more easy to detect, maybe
> we should log unprivileged port access (beyond the few requests for
> which it can make sense).

Logging this would be a potential DoS: A simple user space program could
connect to 2049 repeatedly and fill the server's log.

But again, not worth the trouble: desktop file browsers connect from
ephemeral ports. Why log those harmless accesses?


>> Note that Solaris' NFS server stopped checking source ports many years
>> ago. We're only doing this now because we followed suit from how they
>> behaved in the 90s and never changed it.
> 
> I wonder why Sun went out of business.....

It certainly wasn't due to the Solaris NFS server's port checking
behavior. This is a red herring.

I see very few CVEs or other security advisories that describe the
Solaris NFS server behavior as an active exploit. That suggests to me
that source port checking is not valuable as a security mechanism.


> Ignoring source ports makes no sense at all unless you enforce some other
> authentication, like krb5 or TLS, or unless you *know* that there are no
> unprivileged processes running on any client machines.

I'd be in favor of, first:

* exportfs emitting a message when neither "secure" nor "insecure" is
  specified for one or more exports

* Updating the description of "secure" in exports(8) to explain that
  this option provides little to no security, and strongly recommending
  the deployment of cryptographic security mechanisms (as described in
  the "RPCSEC_GSS security" section

Then later change the default to "insecure".


-- 
Chuck Lever

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

[NeilBrown]

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.


NeilBrown

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

[Chuck Lever]

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

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

[NeilBrown]

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.  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.

> 
> 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.

Thanks,
NeilBrown

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

[Chuck Lever]

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

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

[NeilBrown]

On Fri, 16 May 2025, Chuck Lever wrote:
> 
> Fair enough. We'll focus on improving the man page text for now.
> 

Has anyone volunteered to do that?

Here are some words that might be useful.  I haven't tried to structure
them to fit well into the man page.
---------------
sec=sys (also known as AUTH_SYS) is only safe to specify for clients
that are connected to the server by a secure network - either physically
secure such as in a locked room, or cryptographically secure such as
with a VPN where the client hardware is also secure (locked cage or
secure-boot etc).

When such physical and/or crypto security is in place sec=sys can
safely be used and there is an extra configuration option available in
a choice between the "secure" and "insecure" export options.  

"insecure" means that all software running in the client node is fully
trusted to only access files on the NFS exports that it is expected to
access.  In this case the server will accept connections from any TCP
port on the client (and messages from any UDP port) - as they can
equally be trusted.

"secure" means that the clients are Unix-like systems and that only
"admin" software such as the kernel and administrative software running
as "root" can be trusted to access files appropriately.  All other
software, which includes all user-space software running with a UID
other than zero, should be treated with caution and not given direct
access to the NFS server.  In this case the server will reject
connections from TCP ports on the client with numbers not less than 1024
(and UDP messages from ports not less than 1024) as such connections an
messages may be from an untrusted process.  Note that on Unix-like
systems only privileged processes can send from ports below 1024.

The "secure" option is enabled by default as it is least likely to give
away undesired access.  Note that the names of the options do not
clearly match the descriptions given.

-------------

I haven't added anything about mtls as I couldn't find out how nfsd
interprets the identity presented in the client-side certificate.  If
the identity is a "machine identity" then sec=sys would make sense on
that connection.  If the identity is for a specific user and can map to
a uid, the all_squash,anon=UID should be imposed on that connection.

Can you point me to any documentation about how the client certificate
is interpreted by nfsd?

Thanks,
NeilBrown

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

[Jeff Layton]

On Mon, 2025-05-19 at 16:02 +1000, NeilBrown wrote:
> On Fri, 16 May 2025, Chuck Lever wrote:
> > 
> > Fair enough. We'll focus on improving the man page text for now.
> > 
> 
> Has anyone volunteered to do that?
>
> Here are some words that might be useful.  I haven't tried to structure
> them to fit well into the man page.

Thanks Neil.

I was planning to write up a manpage patch for this once the dust had
settled from this discussion. I'll plan to incorporate something like
what you've written below.

> ---------------
> sec=sys (also known as AUTH_SYS) is only safe to specify for clients
> that are connected to the server by a secure network - either physically
> secure such as in a locked room, or cryptographically secure such as
> with a VPN where the client hardware is also secure (locked cage or
> secure-boot etc).
> 
> When such physical and/or crypto security is in place sec=sys can
> safely be used and there is an extra configuration option available in
> a choice between the "secure" and "insecure" export options.  
> 
> "insecure" means that all software running in the client node is fully
> trusted to only access files on the NFS exports that it is expected to
> access.  In this case the server will accept connections from any TCP
> port on the client (and messages from any UDP port) - as they can
> equally be trusted.
> 
> "secure" means that the clients are Unix-like systems and that only
> "admin" software such as the kernel and administrative software running
> as "root" can be trusted to access files appropriately.  All other
> software, which includes all user-space software running with a UID
> other than zero, should be treated with caution and not given direct
> access to the NFS server.  In this case the server will reject
> connections from TCP ports on the client with numbers not less than 1024
> (and UDP messages from ports not less than 1024) as such connections an
> messages may be from an untrusted process.  Note that on Unix-like
> systems only privileged processes can send from ports below 1024.
> 
> The "secure" option is enabled by default as it is least likely to give
> away undesired access.  Note that the names of the options do not
> clearly match the descriptions given.
> 
> -------------
> 
> I haven't added anything about mtls as I couldn't find out how nfsd
> interprets the identity presented in the client-side certificate.  If
> the identity is a "machine identity" then sec=sys would make sense on
> that connection.  If the identity is for a specific user and can map to
> a uid, the all_squash,anon=UID should be imposed on that connection.
> 
> Can you point me to any documentation about how the client certificate
> is interpreted by nfsd?


-- 
Jeff Layton <jlayton@kernel.org>

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

[Chuck Lever]

On 5/19/25 2:02 AM, NeilBrown wrote:
> On Fri, 16 May 2025, Chuck Lever wrote:
>>
>> Fair enough. We'll focus on improving the man page text for now.
>>
> 
> Has anyone volunteered to do that?

Jeff has, but thank you for the text!


> I haven't added anything about mtls as I couldn't find out how nfsd
> interprets the identity presented in the client-side certificate.  If
> the identity is a "machine identity" then sec=sys would make sense on
> that connection.  If the identity is for a specific user and can map to
> a uid, the all_squash,anon=UID should be imposed on that connection.
> 
> Can you point me to any documentation about how the client certificate
> is interpreted by nfsd?

A TLS handshake is rejected if the server does not recognize the client
certificate's trust chain, as is standard practice for TLS with other
upper layer protocols. Therefore, when an export requires mtls, the
client must present a certificate and the server must recognize the
granting CA for that cert. In recent nfs-utils, there is a "Transport
layer security" section in exports(5) that might be updated to include
that information.

According to RFC 9289, client certificates are machine identities. To
identify a squash user, we plan to adopt the FreeBSD mechanism where
user squashing instructions can be included in the client certificate as
part of the Subject Alternate Name. This is not documented because it is
not yet implemented in Linux (but FreeBSD client and server do currently
implement this mechanism).


-- 
Chuck Lever

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

[Chuck Lever]

On 5/19/25 3:35 PM, Rik Theys wrote:
> Hi,
> 
> On 5/19/25 4:16 PM, Chuck Lever wrote:
>>> Can you point me to any documentation about how the client certificate
>>> is interpreted by nfsd?
>> A TLS handshake is rejected if the server does not recognize the client
>> certificate's trust chain, as is standard practice for TLS with other
>> upper layer protocols. Therefore, when an export requires mtls, the
>> client must present a certificate and the server must recognize the
>> granting CA for that cert.
> 
> In the man page for tlshd.conf, I only see options to configure the CA
> and certificate. I don't see any options to configure a CRL? What's the
> procedure to prevent a specific client certificate from accessing the
> server if the certificate is believed to be stolen?

It isn't clear to me that CRLs are the preferred mechanism to reject a
certificate. But in any event, that support can be added to tlshd if
gnuTLS itself doesn't already handle that under the library API.

-- 
Chuck Lever

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

[Rick Macklem]

On Mon, May 19, 2025 at 7:16 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca.
>
>
> On 5/19/25 2:02 AM, NeilBrown wrote:
> > On Fri, 16 May 2025, Chuck Lever wrote:
> >>
> >> Fair enough. We'll focus on improving the man page text for now.
> >>
> >
> > Has anyone volunteered to do that?
>
> Jeff has, but thank you for the text!
>
>
> > I haven't added anything about mtls as I couldn't find out how nfsd
> > interprets the identity presented in the client-side certificate.  If
> > the identity is a "machine identity" then sec=sys would make sense on
> > that connection.  If the identity is for a specific user and can map to
> > a uid, the all_squash,anon=UID should be imposed on that connection.
> >
> > Can you point me to any documentation about how the client certificate
> > is interpreted by nfsd?
>
> A TLS handshake is rejected if the server does not recognize the client
> certificate's trust chain, as is standard practice for TLS with other
> upper layer protocols. Therefore, when an export requires mtls, the
> client must present a certificate and the server must recognize the
> granting CA for that cert. In recent nfs-utils, there is a "Transport
> layer security" section in exports(5) that might be updated to include
> that information.
Do you also have some configurable settings for if/how the DNS
field in the client's X.509 cert is checked?
The range is, imho:
- Don't check it at all, so the client can have any IP/DNS name (a mobile
  device). The least secure, but still pretty good, since the ert. verified.
- DNS matches a wildcard like *.umich.edu for the reverse DNS name for
   the client's IP host address.
- DNS matches exactly what reverse DNS gets for the client's IP host address.

Wildcards are discouraged by some RFC, but are still supported by OpenSSL.

rick

>
> According to RFC 9289, client certificates are machine identities. To
> identify a squash user, we plan to adopt the FreeBSD mechanism where
> user squashing instructions can be included in the client certificate as
> part of the Subject Alternate Name. This is not documented because it is
> not yet implemented in Linux (but FreeBSD client and server do currently
> implement this mechanism).
>
>
> --
> Chuck Lever
>

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

[Chuck Lever]

Hiya Rick -

On 5/19/25 9:44 PM, Rick Macklem wrote:

> Do you also have some configurable settings for if/how the DNS
> field in the client's X.509 cert is checked?
> The range is, imho:
> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>   device). The least secure, but still pretty good, since the ert. verified.
> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>    the client's IP host address.
> - DNS matches exactly what reverse DNS gets for the client's IP host address.

I've been told repeatedly that certificate verification must not depend
on DNS because DNS can be easily spoofed. To date, the Linux
implementation of RPC-with-TLS depends on having the peer's IP address
in the certificate's SAN.

I recognize that tlshd will need to bend a little for clients that use
a dynamically allocated IP address, but I haven't looked into it yet.
Perhaps client certificates do not need to contain their peer IP
address, but server certificates do, in order to enable mounting by IP
instead of by hostname.


> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.

I would prefer that we follow the guidance of RFCs where possible,
rather than a particular implementation that might have historical
reasons to permit a lack of security.

I'll need to find out what flexibility gnuTLS offers. tlshd on Linux
cannot use OpenSSL because its license is incompatible with GPLv2,
which is the license the Linux kernel uses.


-- 
Chuck Lever

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

[Chuck Lever]

On 5/20/25 9:20 AM, Chuck Lever wrote:
> Hiya Rick -
> 
> On 5/19/25 9:44 PM, Rick Macklem wrote:
> 
>> Do you also have some configurable settings for if/how the DNS
>> field in the client's X.509 cert is checked?
>> The range is, imho:
>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>   device). The least secure, but still pretty good, since the ert. verified.
>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>    the client's IP host address.
>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> 
> I've been told repeatedly that certificate verification must not depend
> on DNS because DNS can be easily spoofed. To date, the Linux
> implementation of RPC-with-TLS depends on having the peer's IP address
> in the certificate's SAN.
> 
> I recognize that tlshd will need to bend a little for clients that use
> a dynamically allocated IP address, but I haven't looked into it yet.
> Perhaps client certificates do not need to contain their peer IP
> address, but server certificates do, in order to enable mounting by IP
> instead of by hostname.
> 
> 
>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> 
> I would prefer that we follow the guidance of RFCs where possible,
> rather than a particular implementation that might have historical
> reasons to permit a lack of security.

Let me follow up on this.

We have an open issue against tlshd that has suggested that, rather
than looking at DNS query results, the NFS server should authorize
access by looking at the client certificate's CN. The server's
administrator should be able to specify a list of one or more CN
wildcards that can be used to authorize access, much in the same way
that NFSD currently uses netgroups and hostnames per export.

So, after validating the client's CA trust chain, an NFS server can
match the client certificate's CN against its list of authorized CNs,
and if the client's CN fails to match, fail the handshake (or whatever
we need to do).

I favor this approach over using DNS labels, which are often
untrustworthy, and IP addresses, which can be dynamically reassigned.

What do you think?

-- 
Chuck Lever

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

[NeilBrown]

On Mon, 26 May 2025, Chuck Lever wrote:
> On 5/20/25 9:20 AM, Chuck Lever wrote:
> > Hiya Rick -
> > 
> > On 5/19/25 9:44 PM, Rick Macklem wrote:
> > 
> >> Do you also have some configurable settings for if/how the DNS
> >> field in the client's X.509 cert is checked?
> >> The range is, imho:
> >> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>   device). The least secure, but still pretty good, since the ert. verified.
> >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>    the client's IP host address.
> >> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > 
> > I've been told repeatedly that certificate verification must not depend
> > on DNS because DNS can be easily spoofed. To date, the Linux
> > implementation of RPC-with-TLS depends on having the peer's IP address
> > in the certificate's SAN.
> > 
> > I recognize that tlshd will need to bend a little for clients that use
> > a dynamically allocated IP address, but I haven't looked into it yet.
> > Perhaps client certificates do not need to contain their peer IP
> > address, but server certificates do, in order to enable mounting by IP
> > instead of by hostname.
> > 
> > 
> >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > 
> > I would prefer that we follow the guidance of RFCs where possible,
> > rather than a particular implementation that might have historical
> > reasons to permit a lack of security.
> 
> Let me follow up on this.
> 
> We have an open issue against tlshd that has suggested that, rather
> than looking at DNS query results, the NFS server should authorize
> access by looking at the client certificate's CN. The server's
> administrator should be able to specify a list of one or more CN
> wildcards that can be used to authorize access, much in the same way
> that NFSD currently uses netgroups and hostnames per export.
> 
> So, after validating the client's CA trust chain, an NFS server can
> match the client certificate's CN against its list of authorized CNs,
> and if the client's CN fails to match, fail the handshake (or whatever
> we need to do).
> 
> I favor this approach over using DNS labels, which are often
> untrustworthy, and IP addresses, which can be dynamically reassigned.
> 
> What do you think?

I completely agree with this.  IP address and DNS identity of the client
is irrelevant when mTLS is used.  What matters is whether the client has
authority to act as one of the the names given when the filesystem was
exported (e.g. in /etc/exports).  His is exacly what you said.

Ideally it would be more than just the CN.  We want to know both the
domain in which the peer has authority (e.g.  example.com) and the type
of authority (e.g.  serve-web-pages or proxy-file-access or
act-as-neilb).
I don't know internal details of certificates so I don't know if there
is some other field that can say "This peer is authorised to proxy file
access requests for all users in the given domain" or if we need a hack
like exporting to nfs-client.example.com.

But if the admin has full control of what names to export to, it is
possible that the distinction doesn't matter.  I wouldn't want the
certificate used to authenticate my web server to have authority to
access all files on my NFS server just because the same domain name
applies to both.

Thanks,
NeilBrown

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

[Rick Macklem]

On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
>
> On Mon, 26 May 2025, Chuck Lever wrote:
> > On 5/20/25 9:20 AM, Chuck Lever wrote:
> > > Hiya Rick -
> > >
> > > On 5/19/25 9:44 PM, Rick Macklem wrote:
> > >
> > >> Do you also have some configurable settings for if/how the DNS
> > >> field in the client's X.509 cert is checked?
> > >> The range is, imho:
> > >> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> > >>   device). The least secure, but still pretty good, since the ert. verified.
> > >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> > >>    the client's IP host address.
> > >> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > >
> > > I've been told repeatedly that certificate verification must not depend
> > > on DNS because DNS can be easily spoofed. To date, the Linux
> > > implementation of RPC-with-TLS depends on having the peer's IP address
> > > in the certificate's SAN.
> > >
> > > I recognize that tlshd will need to bend a little for clients that use
> > > a dynamically allocated IP address, but I haven't looked into it yet.
> > > Perhaps client certificates do not need to contain their peer IP
> > > address, but server certificates do, in order to enable mounting by IP
> > > instead of by hostname.
> > >
> > >
> > >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > >
> > > I would prefer that we follow the guidance of RFCs where possible,
> > > rather than a particular implementation that might have historical
> > > reasons to permit a lack of security.
> >
> > Let me follow up on this.
> >
> > We have an open issue against tlshd that has suggested that, rather
> > than looking at DNS query results, the NFS server should authorize
> > access by looking at the client certificate's CN. The server's
> > administrator should be able to specify a list of one or more CN
> > wildcards that can be used to authorize access, much in the same way
> > that NFSD currently uses netgroups and hostnames per export.
> >
> > So, after validating the client's CA trust chain, an NFS server can
> > match the client certificate's CN against its list of authorized CNs,
> > and if the client's CN fails to match, fail the handshake (or whatever
> > we need to do).
> >
> > I favor this approach over using DNS labels, which are often
> > untrustworthy, and IP addresses, which can be dynamically reassigned.
> >
> > What do you think?
>
> I completely agree with this.  IP address and DNS identity of the client
> is irrelevant when mTLS is used.  What matters is whether the client has
> authority to act as one of the the names given when the filesystem was
> exported (e.g. in /etc/exports).  His is exacly what you said.
Well, what happens when someone naughty copies the cert. to a different
system?
--> It is true that verification will show that the cert. is valid, but is it
      valid for that client system?
     (Not checking the reverse DNS name makes the check somewhat weaker,
       imho. Now, is having the IP address in the cert. and checking
that stronger.
       Well, maybe. The hassle is that the certs. all have to be replaced when
       some network type decides to reconfigure the LANs or move the system
       onto a different subnet for some reason.)

Another way a cert. can be protected from being moved to a different client
by someone naughty is adding a passphrase to it (the -aes256 option on
the openssl command line when creating the CSR). The hassle is that
someone has to type the passphrase in when the system is started/rebooted.

There is no perfect solution (or security is not a binary value, if
you prefer), so
I chose to provide as many options as I could, so that sysadmins could choose
what works for them. (Of course, they need to understand what is going on and
documenting that can be a challenge.)

rick

>
> Ideally it would be more than just the CN.  We want to know both the
> domain in which the peer has authority (e.g.  example.com) and the type
> of authority (e.g.  serve-web-pages or proxy-file-access or
> act-as-neilb).
> I don't know internal details of certificates so I don't know if there
> is some other field that can say "This peer is authorised to proxy file
> access requests for all users in the given domain" or if we need a hack
> like exporting to nfs-client.example.com.
>
> But if the admin has full control of what names to export to, it is
> possible that the distinction doesn't matter.  I wouldn't want the
> certificate used to authenticate my web server to have authority to
> access all files on my NFS server just because the same domain name
> applies to both.
>
> Thanks,
> NeilBrown

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

[Rick Macklem]

On Sun, May 25, 2025 at 6:47 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
> >
> > On Mon, 26 May 2025, Chuck Lever wrote:
> > > On 5/20/25 9:20 AM, Chuck Lever wrote:
> > > > Hiya Rick -
> > > >
> > > > On 5/19/25 9:44 PM, Rick Macklem wrote:
> > > >
> > > >> Do you also have some configurable settings for if/how the DNS
> > > >> field in the client's X.509 cert is checked?
> > > >> The range is, imho:
> > > >> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> > > >>   device). The least secure, but still pretty good, since the ert. verified.
> > > >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> > > >>    the client's IP host address.
> > > >> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > > >
> > > > I've been told repeatedly that certificate verification must not depend
> > > > on DNS because DNS can be easily spoofed. To date, the Linux
> > > > implementation of RPC-with-TLS depends on having the peer's IP address
> > > > in the certificate's SAN.
> > > >
> > > > I recognize that tlshd will need to bend a little for clients that use
> > > > a dynamically allocated IP address, but I haven't looked into it yet.
> > > > Perhaps client certificates do not need to contain their peer IP
> > > > address, but server certificates do, in order to enable mounting by IP
> > > > instead of by hostname.
> > > >
> > > >
> > > >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > > >
> > > > I would prefer that we follow the guidance of RFCs where possible,
> > > > rather than a particular implementation that might have historical
> > > > reasons to permit a lack of security.
> > >
> > > Let me follow up on this.
> > >
> > > We have an open issue against tlshd that has suggested that, rather
> > > than looking at DNS query results, the NFS server should authorize
> > > access by looking at the client certificate's CN. The server's
> > > administrator should be able to specify a list of one or more CN
> > > wildcards that can be used to authorize access, much in the same way
> > > that NFSD currently uses netgroups and hostnames per export.
> > >
> > > So, after validating the client's CA trust chain, an NFS server can
> > > match the client certificate's CN against its list of authorized CNs,
> > > and if the client's CN fails to match, fail the handshake (or whatever
> > > we need to do).
> > >
> > > I favor this approach over using DNS labels, which are often
> > > untrustworthy, and IP addresses, which can be dynamically reassigned.
> > >
> > > What do you think?
> >
> > I completely agree with this.  IP address and DNS identity of the client
> > is irrelevant when mTLS is used.  What matters is whether the client has
> > authority to act as one of the the names given when the filesystem was
> > exported (e.g. in /etc/exports).  His is exacly what you said.
> Well, what happens when someone naughty copies the cert. to a different
> system?
> --> It is true that verification will show that the cert. is valid, but is it
>       valid for that client system?
>      (Not checking the reverse DNS name makes the check somewhat weaker,
>        imho.
I should have said "reverse name lookup" and not reverse DNS. Important fqdn
names can be put in /etc/hosts and the system configured to look there before
DNS. If that is done on the NFS server end, a problem with DNS spoofing should
be avoided, I think?

rick

>        Now, is having the IP address in the cert. and checking
>        that stronger.
>        Well, maybe. The hassle is that the certs. all have to be replaced when
>        some network type decides to reconfigure the LANs or move the system
>        onto a different subnet for some reason.)
>
> Another way a cert. can be protected from being moved to a different client
> by someone naughty is adding a passphrase to it (the -aes256 option on
> the openssl command line when creating the CSR). The hassle is that
> someone has to type the passphrase in when the system is started/rebooted.
>
> There is no perfect solution (or security is not a binary value, if
> you prefer), so
> I chose to provide as many options as I could, so that sysadmins could choose
> what works for them. (Of course, they need to understand what is going on and
> documenting that can be a challenge.)
>
> rick
>
> >
> > Ideally it would be more than just the CN.  We want to know both the
> > domain in which the peer has authority (e.g.  example.com) and the type
> > of authority (e.g.  serve-web-pages or proxy-file-access or
> > act-as-neilb).
> > I don't know internal details of certificates so I don't know if there
> > is some other field that can say "This peer is authorised to proxy file
> > access requests for all users in the given domain" or if we need a hack
> > like exporting to nfs-client.example.com.
> >
> > But if the admin has full control of what names to export to, it is
> > possible that the distinction doesn't matter.  I wouldn't want the
> > certificate used to authenticate my web server to have authority to
> > access all files on my NFS server just because the same domain name
> > applies to both.
> >
> > Thanks,
> > NeilBrown

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

[NeilBrown]

On Mon, 26 May 2025, Rick Macklem wrote:
> On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
> >
> > On Mon, 26 May 2025, Chuck Lever wrote:
> > > On 5/20/25 9:20 AM, Chuck Lever wrote:
> > > > Hiya Rick -
> > > >
> > > > On 5/19/25 9:44 PM, Rick Macklem wrote:
> > > >
> > > >> Do you also have some configurable settings for if/how the DNS
> > > >> field in the client's X.509 cert is checked?
> > > >> The range is, imho:
> > > >> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> > > >>   device). The least secure, but still pretty good, since the ert. verified.
> > > >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> > > >>    the client's IP host address.
> > > >> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > > >
> > > > I've been told repeatedly that certificate verification must not depend
> > > > on DNS because DNS can be easily spoofed. To date, the Linux
> > > > implementation of RPC-with-TLS depends on having the peer's IP address
> > > > in the certificate's SAN.
> > > >
> > > > I recognize that tlshd will need to bend a little for clients that use
> > > > a dynamically allocated IP address, but I haven't looked into it yet.
> > > > Perhaps client certificates do not need to contain their peer IP
> > > > address, but server certificates do, in order to enable mounting by IP
> > > > instead of by hostname.
> > > >
> > > >
> > > >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > > >
> > > > I would prefer that we follow the guidance of RFCs where possible,
> > > > rather than a particular implementation that might have historical
> > > > reasons to permit a lack of security.
> > >
> > > Let me follow up on this.
> > >
> > > We have an open issue against tlshd that has suggested that, rather
> > > than looking at DNS query results, the NFS server should authorize
> > > access by looking at the client certificate's CN. The server's
> > > administrator should be able to specify a list of one or more CN
> > > wildcards that can be used to authorize access, much in the same way
> > > that NFSD currently uses netgroups and hostnames per export.
> > >
> > > So, after validating the client's CA trust chain, an NFS server can
> > > match the client certificate's CN against its list of authorized CNs,
> > > and if the client's CN fails to match, fail the handshake (or whatever
> > > we need to do).
> > >
> > > I favor this approach over using DNS labels, which are often
> > > untrustworthy, and IP addresses, which can be dynamically reassigned.
> > >
> > > What do you think?
> >
> > I completely agree with this.  IP address and DNS identity of the client
> > is irrelevant when mTLS is used.  What matters is whether the client has
> > authority to act as one of the the names given when the filesystem was
> > exported (e.g. in /etc/exports).  His is exacly what you said.
> Well, what happens when someone naughty copies the cert. to a different
> system?

Then you have already lost.  Certificates are like passwords.

I guess 2FA is a thing and maybe it makes sense to check both IP and
certificate.  But I certainly wouldn't want to trust only that the IP
matches the certificate.  I would want to be able to check the
certificate without even considering the IP.
Maybe:
 1/ Is the IP from a permitted subnet - if not, reject.
 2/ is the certificate for an approved CN - if not, reject.
 3/ Does the IP match the CN

1 and 3 could be optional.  2 shouldn't be.

Thanks,
NeilBrown

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

[Rick Macklem]

On Sun, May 25, 2025 at 7:29 PM NeilBrown <neil@brown.name> wrote:
>
> On Mon, 26 May 2025, Rick Macklem wrote:
> > On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
> > >
> > > On Mon, 26 May 2025, Chuck Lever wrote:
> > > > On 5/20/25 9:20 AM, Chuck Lever wrote:
> > > > > Hiya Rick -
> > > > >
> > > > > On 5/19/25 9:44 PM, Rick Macklem wrote:
> > > > >
> > > > >> Do you also have some configurable settings for if/how the DNS
> > > > >> field in the client's X.509 cert is checked?
> > > > >> The range is, imho:
> > > > >> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> > > > >>   device). The least secure, but still pretty good, since the ert. verified.
> > > > >> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> > > > >>    the client's IP host address.
> > > > >> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > > > >
> > > > > I've been told repeatedly that certificate verification must not depend
> > > > > on DNS because DNS can be easily spoofed. To date, the Linux
> > > > > implementation of RPC-with-TLS depends on having the peer's IP address
> > > > > in the certificate's SAN.
> > > > >
> > > > > I recognize that tlshd will need to bend a little for clients that use
> > > > > a dynamically allocated IP address, but I haven't looked into it yet.
> > > > > Perhaps client certificates do not need to contain their peer IP
> > > > > address, but server certificates do, in order to enable mounting by IP
> > > > > instead of by hostname.
> > > > >
> > > > >
> > > > >> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > > > >
> > > > > I would prefer that we follow the guidance of RFCs where possible,
> > > > > rather than a particular implementation that might have historical
> > > > > reasons to permit a lack of security.
> > > >
> > > > Let me follow up on this.
> > > >
> > > > We have an open issue against tlshd that has suggested that, rather
> > > > than looking at DNS query results, the NFS server should authorize
> > > > access by looking at the client certificate's CN. The server's
> > > > administrator should be able to specify a list of one or more CN
> > > > wildcards that can be used to authorize access, much in the same way
> > > > that NFSD currently uses netgroups and hostnames per export.
> > > >
> > > > So, after validating the client's CA trust chain, an NFS server can
> > > > match the client certificate's CN against its list of authorized CNs,
> > > > and if the client's CN fails to match, fail the handshake (or whatever
> > > > we need to do).
> > > >
> > > > I favor this approach over using DNS labels, which are often
> > > > untrustworthy, and IP addresses, which can be dynamically reassigned.
> > > >
> > > > What do you think?
> > >
> > > I completely agree with this.  IP address and DNS identity of the client
> > > is irrelevant when mTLS is used.  What matters is whether the client has
> > > authority to act as one of the the names given when the filesystem was
> > > exported (e.g. in /etc/exports).  His is exacly what you said.
> > Well, what happens when someone naughty copies the cert. to a different
> > system?
>
> Then you have already lost.  Certificates are like passwords.
True. But if the IP address must match that of the client's IP host address, it
limits where the cert. (or password, if you like) can be used.
(The subnet where the IP address is supported, for example.)

Without this, a compromised cert. can be used from anywhere.

>
> I guess 2FA is a thing and maybe it makes sense to check both IP and
> certificate.  But I certainly wouldn't want to trust only that the IP
> matches the certificate.  I would want to be able to check the
> certificate without even considering the IP.
> Maybe:
>  1/ Is the IP from a permitted subnet - if not, reject.
>  2/ is the certificate for an approved CN - if not, reject.
>  3/ Does the IP match the CN
>
> 1 and 3 could be optional.  2 shouldn't be.
I'm not sure #2 makes it stronger than just "it verified", since
verified means that the "password" is correct.

Now, I agree that the CN (or cert. serial# or anything else in the cert)
can be used to distinguish which certs. are allowed for which file system
exports. (Saves having different issuers to differentiate the certs.)
--> Put another way, the CN can be used to decide which file systems
      can be accessed and how, but it is not really useful to just say
      that the cert. is valid, since verification has already done that.

I also agree #1 and #3 are optional and their use really depends on
what the network topology for client->server is and ranges from useless
up to useful, I think?

rick

>
> Thanks,
> NeilBrown
>

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

[Chuck Lever]

On 5/25/25 9:47 PM, Rick Macklem wrote:
> On Sun, May 25, 2025 at 5:09 PM NeilBrown <neil@brown.name> wrote:
>>
>> On Mon, 26 May 2025, Chuck Lever wrote:
>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>> Hiya Rick -
>>>>
>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>
>>>>> Do you also have some configurable settings for if/how the DNS
>>>>> field in the client's X.509 cert is checked?
>>>>> The range is, imho:
>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>    the client's IP host address.
>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>
>>>> I've been told repeatedly that certificate verification must not depend
>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>> in the certificate's SAN.
>>>>
>>>> I recognize that tlshd will need to bend a little for clients that use
>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>> Perhaps client certificates do not need to contain their peer IP
>>>> address, but server certificates do, in order to enable mounting by IP
>>>> instead of by hostname.
>>>>
>>>>
>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>
>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>> rather than a particular implementation that might have historical
>>>> reasons to permit a lack of security.
>>>
>>> Let me follow up on this.
>>>
>>> We have an open issue against tlshd that has suggested that, rather
>>> than looking at DNS query results, the NFS server should authorize
>>> access by looking at the client certificate's CN. The server's
>>> administrator should be able to specify a list of one or more CN
>>> wildcards that can be used to authorize access, much in the same way
>>> that NFSD currently uses netgroups and hostnames per export.
>>>
>>> So, after validating the client's CA trust chain, an NFS server can
>>> match the client certificate's CN against its list of authorized CNs,
>>> and if the client's CN fails to match, fail the handshake (or whatever
>>> we need to do).
>>>
>>> I favor this approach over using DNS labels, which are often
>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>
>>> What do you think?
>>
>> I completely agree with this.  IP address and DNS identity of the client
>> is irrelevant when mTLS is used.  What matters is whether the client has
>> authority to act as one of the the names given when the filesystem was
>> exported (e.g. in /etc/exports).  His is exacly what you said.
> Well, what happens when someone naughty copies the cert. to a different
> system?

When that copy is discovered, the server can use a CRL to fence the use
of the copied certificate (and as Rik T. pointed out, NFSD does not yet
support that kind of mechanism).


> --> It is true that verification will show that the cert. is valid, but is it
>       valid for that client system?
>      (Not checking the reverse DNS name makes the check somewhat weaker,
>        imho. Now, is having the IP address in the cert. and checking
> that stronger.
>        Well, maybe. The hassle is that the certs. all have to be replaced when
>        some network type decides to reconfigure the LANs or move the system
>        onto a different subnet for some reason.)

None of that works for NFS clients whose name and address are
dynamically assigned.


> Another way a cert. can be protected from being moved to a different client
> by someone naughty is adding a passphrase to it (the -aes256 option on
> the openssl command line when creating the CSR). The hassle is that
> someone has to type the passphrase in when the system is started/rebooted.
> 
> There is no perfect solution (or security is not a binary value, if
> you prefer), so
> I chose to provide as many options as I could, so that sysadmins could choose
> what works for them. (Of course, they need to understand what is going on and
> documenting that can be a challenge.)

Fair. Our implementations might differ in this regard.


> rick
> 
>>
>> Ideally it would be more than just the CN.  We want to know both the
>> domain in which the peer has authority (e.g.  example.com) and the type
>> of authority (e.g.  serve-web-pages or proxy-file-access or
>> act-as-neilb).
>> I don't know internal details of certificates so I don't know if there
>> is some other field that can say "This peer is authorised to proxy file
>> access requests for all users in the given domain" or if we need a hack
>> like exporting to nfs-client.example.com.
>>
>> But if the admin has full control of what names to export to, it is
>> possible that the distinction doesn't matter.  I wouldn't want the
>> certificate used to authenticate my web server to have authority to
>> access all files on my NFS server just because the same domain name
>> applies to both.
>>
>> Thanks,
>> NeilBrown


-- 
Chuck Lever

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

[Chuck Lever]

On 5/25/25 8:09 PM, NeilBrown wrote:
> On Mon, 26 May 2025, Chuck Lever wrote:
>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>> Hiya Rick -
>>>
>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>
>>>> Do you also have some configurable settings for if/how the DNS
>>>> field in the client's X.509 cert is checked?
>>>> The range is, imho:
>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>    the client's IP host address.
>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>
>>> I've been told repeatedly that certificate verification must not depend
>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>> in the certificate's SAN.
>>>
>>> I recognize that tlshd will need to bend a little for clients that use
>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>> Perhaps client certificates do not need to contain their peer IP
>>> address, but server certificates do, in order to enable mounting by IP
>>> instead of by hostname.
>>>
>>>
>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>
>>> I would prefer that we follow the guidance of RFCs where possible,
>>> rather than a particular implementation that might have historical
>>> reasons to permit a lack of security.
>>
>> Let me follow up on this.
>>
>> We have an open issue against tlshd that has suggested that, rather
>> than looking at DNS query results, the NFS server should authorize
>> access by looking at the client certificate's CN. The server's
>> administrator should be able to specify a list of one or more CN
>> wildcards that can be used to authorize access, much in the same way
>> that NFSD currently uses netgroups and hostnames per export.
>>
>> So, after validating the client's CA trust chain, an NFS server can
>> match the client certificate's CN against its list of authorized CNs,
>> and if the client's CN fails to match, fail the handshake (or whatever
>> we need to do).
>>
>> I favor this approach over using DNS labels, which are often
>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>
>> What do you think?
> 
> I completely agree with this.  IP address and DNS identity of the client
> is irrelevant when mTLS is used.  What matters is whether the client has
> authority to act as one of the the names given when the filesystem was
> exported (e.g. in /etc/exports).  His is exacly what you said.
> 
> Ideally it would be more than just the CN.  We want to know both the
> domain in which the peer has authority (e.g.  example.com) and the type
> of authority (e.g.  serve-web-pages or proxy-file-access or
> act-as-neilb).
> I don't know internal details of certificates so I don't know if there
> is some other field that can say "This peer is authorised to proxy file
> access requests for all users in the given domain" or if we need a hack
> like exporting to nfs-client.example.com.
> 
> But if the admin has full control of what names to export to, it is
> possible that the distinction doesn't matter.  I wouldn't want the
> certificate used to authenticate my web server to have authority to
> access all files on my NFS server just because the same domain name
> applies to both.

My thought is that, for each handshake, there would be two stages:

1. Does the NFS server trust the certificate? This is purely a chain-of-
   trust issue, so validating the certificate presented by the client is
   the order of the day.

2. Does the NFS server authorize this client to access the export? This
   is a check very similar to the hostname/netgroup/IP address check
   that is done today, but it could be done just once at handshake time.
   Match the certificate's fields against a per-export filter.

I would take tlshd out of the picture for stage 2, and let NFSD make its
own authorization decisions. Because an NFS client might be authorized
to access some exports but not others.

So:

How does the server indicate to clients that yes, your cert is trusted,
but no, you are not authorized to access this file system? I guess that
is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.

What certificate fields should we implement matches for? CN is obvious.
But what about SAN? Any others? I say start with only CN, but I'd like
to think about ways to make it possible to match against other fields in
the future.

What would the administrative interface look like? Could be the machine
name in /etc/exports, for instance:

*,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42

But I worry that will not be flexible enough. A more general filter
mechanism might need something like the ini file format used to create
CSRs.


What about pre-shared keys? No certificate fields there.


-- 
Chuck Lever

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

[Rick Macklem]

On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 5/25/25 8:09 PM, NeilBrown wrote:
> > On Mon, 26 May 2025, Chuck Lever wrote:
> >> On 5/20/25 9:20 AM, Chuck Lever wrote:
> >>> Hiya Rick -
> >>>
> >>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> >>>
> >>>> Do you also have some configurable settings for if/how the DNS
> >>>> field in the client's X.509 cert is checked?
> >>>> The range is, imho:
> >>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>>>   device). The least secure, but still pretty good, since the ert. verified.
> >>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>>>    the client's IP host address.
> >>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> >>>
> >>> I've been told repeatedly that certificate verification must not depend
> >>> on DNS because DNS can be easily spoofed. To date, the Linux
> >>> implementation of RPC-with-TLS depends on having the peer's IP address
> >>> in the certificate's SAN.
> >>>
> >>> I recognize that tlshd will need to bend a little for clients that use
> >>> a dynamically allocated IP address, but I haven't looked into it yet.
> >>> Perhaps client certificates do not need to contain their peer IP
> >>> address, but server certificates do, in order to enable mounting by IP
> >>> instead of by hostname.
> >>>
> >>>
> >>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> >>>
> >>> I would prefer that we follow the guidance of RFCs where possible,
> >>> rather than a particular implementation that might have historical
> >>> reasons to permit a lack of security.
> >>
> >> Let me follow up on this.
> >>
> >> We have an open issue against tlshd that has suggested that, rather
> >> than looking at DNS query results, the NFS server should authorize
> >> access by looking at the client certificate's CN. The server's
> >> administrator should be able to specify a list of one or more CN
> >> wildcards that can be used to authorize access, much in the same way
> >> that NFSD currently uses netgroups and hostnames per export.
> >>
> >> So, after validating the client's CA trust chain, an NFS server can
> >> match the client certificate's CN against its list of authorized CNs,
> >> and if the client's CN fails to match, fail the handshake (or whatever
> >> we need to do).
> >>
> >> I favor this approach over using DNS labels, which are often
> >> untrustworthy, and IP addresses, which can be dynamically reassigned.
> >>
> >> What do you think?
> >
> > I completely agree with this.  IP address and DNS identity of the client
> > is irrelevant when mTLS is used.  What matters is whether the client has
> > authority to act as one of the the names given when the filesystem was
> > exported (e.g. in /etc/exports).  His is exacly what you said.
> >
> > Ideally it would be more than just the CN.  We want to know both the
> > domain in which the peer has authority (e.g.  example.com) and the type
> > of authority (e.g.  serve-web-pages or proxy-file-access or
> > act-as-neilb).
> > I don't know internal details of certificates so I don't know if there
> > is some other field that can say "This peer is authorised to proxy file
> > access requests for all users in the given domain" or if we need a hack
> > like exporting to nfs-client.example.com.
> >
> > But if the admin has full control of what names to export to, it is
> > possible that the distinction doesn't matter.  I wouldn't want the
> > certificate used to authenticate my web server to have authority to
> > access all files on my NFS server just because the same domain name
> > applies to both.
>
> My thought is that, for each handshake, there would be two stages:
>
> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>    trust issue, so validating the certificate presented by the client is
>    the order of the day.
>
> 2. Does the NFS server authorize this client to access the export? This
>    is a check very similar to the hostname/netgroup/IP address check
>    that is done today, but it could be done just once at handshake time.
>    Match the certificate's fields against a per-export filter.
>
> I would take tlshd out of the picture for stage 2, and let NFSD make its
> own authorization decisions. Because an NFS client might be authorized
> to access some exports but not others.
>
> So:
>
> How does the server indicate to clients that yes, your cert is trusted,
> but no, you are not authorized to access this file system? I guess that
> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>
> What certificate fields should we implement matches for? CN is obvious.
> But what about SAN? Any others? I say start with only CN, but I'd like
> to think about ways to make it possible to match against other fields in
> the future.
>
> What would the administrative interface look like? Could be the machine
> name in /etc/exports, for instance:
>
> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>
> But I worry that will not be flexible enough. A more general filter
> mechanism might need something like the ini file format used to create
> CSRs.
One thing you might want to consider as well is the case of compounds not
associated  with files (such as the initial EXCHANGEID, CREATESESSION).
- A naughty client can do a pretty good job of a DOS with those.

Right now there is SP4_NONE and SP4_MACH_CRED for Kerberos.
I have tried to suggest to the NFSv4 working group that SP4_MACH_CRED
should be allowed for the mtls case as well, although I'm not sure it has
gained traction. (Something might be buried in David Noveck's security
draft. I haven't gotten around to looking at it lately.)

rick

>
>
> What about pre-shared keys? No certificate fields there.
>
>
> --
> Chuck Lever

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

[Rick Macklem]

On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 5/25/25 8:09 PM, NeilBrown wrote:
> > On Mon, 26 May 2025, Chuck Lever wrote:
> >> On 5/20/25 9:20 AM, Chuck Lever wrote:
> >>> Hiya Rick -
> >>>
> >>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> >>>
> >>>> Do you also have some configurable settings for if/how the DNS
> >>>> field in the client's X.509 cert is checked?
> >>>> The range is, imho:
> >>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>>>   device). The least secure, but still pretty good, since the ert. verified.
> >>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>>>    the client's IP host address.
> >>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> >>>
> >>> I've been told repeatedly that certificate verification must not depend
> >>> on DNS because DNS can be easily spoofed. To date, the Linux
> >>> implementation of RPC-with-TLS depends on having the peer's IP address
> >>> in the certificate's SAN.
> >>>
> >>> I recognize that tlshd will need to bend a little for clients that use
> >>> a dynamically allocated IP address, but I haven't looked into it yet.
> >>> Perhaps client certificates do not need to contain their peer IP
> >>> address, but server certificates do, in order to enable mounting by IP
> >>> instead of by hostname.
> >>>
> >>>
> >>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> >>>
> >>> I would prefer that we follow the guidance of RFCs where possible,
> >>> rather than a particular implementation that might have historical
> >>> reasons to permit a lack of security.
> >>
> >> Let me follow up on this.
> >>
> >> We have an open issue against tlshd that has suggested that, rather
> >> than looking at DNS query results, the NFS server should authorize
> >> access by looking at the client certificate's CN. The server's
> >> administrator should be able to specify a list of one or more CN
> >> wildcards that can be used to authorize access, much in the same way
> >> that NFSD currently uses netgroups and hostnames per export.
> >>
> >> So, after validating the client's CA trust chain, an NFS server can
> >> match the client certificate's CN against its list of authorized CNs,
> >> and if the client's CN fails to match, fail the handshake (or whatever
> >> we need to do).
> >>
> >> I favor this approach over using DNS labels, which are often
> >> untrustworthy, and IP addresses, which can be dynamically reassigned.
> >>
> >> What do you think?
> >
> > I completely agree with this.  IP address and DNS identity of the client
> > is irrelevant when mTLS is used.  What matters is whether the client has
> > authority to act as one of the the names given when the filesystem was
> > exported (e.g. in /etc/exports).  His is exacly what you said.
> >
> > Ideally it would be more than just the CN.  We want to know both the
> > domain in which the peer has authority (e.g.  example.com) and the type
> > of authority (e.g.  serve-web-pages or proxy-file-access or
> > act-as-neilb).
> > I don't know internal details of certificates so I don't know if there
> > is some other field that can say "This peer is authorised to proxy file
> > access requests for all users in the given domain" or if we need a hack
> > like exporting to nfs-client.example.com.
> >
> > But if the admin has full control of what names to export to, it is
> > possible that the distinction doesn't matter.  I wouldn't want the
> > certificate used to authenticate my web server to have authority to
> > access all files on my NFS server just because the same domain name
> > applies to both.
>
> My thought is that, for each handshake, there would be two stages:
>
> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>    trust issue, so validating the certificate presented by the client is
>    the order of the day.
>
> 2. Does the NFS server authorize this client to access the export? This
>    is a check very similar to the hostname/netgroup/IP address check
>    that is done today, but it could be done just once at handshake time.
>    Match the certificate's fields against a per-export filter.
>
> I would take tlshd out of the picture for stage 2, and let NFSD make its
> own authorization decisions. Because an NFS client might be authorized
> to access some exports but not others.
>
> So:
>
> How does the server indicate to clients that yes, your cert is trusted,
> but no, you are not authorized to access this file system? I guess that
> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>
> What certificate fields should we implement matches for? CN is obvious.
> But what about SAN? Any others? I say start with only CN, but I'd like
> to think about ways to make it possible to match against other fields in
> the future.
Just fyi, here's an example where filtering on the DNS or IP field in the
SAN (SubjectAltName) could improve security..
(Dusting off my CS sysadmin hat.)

Suppose I had a file system where student grades and exam questions
were stored.
The mount was restricted to faculty offices, where their machines had fixed
well known IP addresses and FQDNs assigned.
However, as it was for my case, the building their offices were in also had
student labs and the building was assigned a subnet by the campus
networking folk.
--> As such, a student could easily come in off hours (when the faculty were not
     around and, as such, had their office computers shut down) and
plug into the
     subnet (they just had to find an RJ45 jack somewhere that they
could access).
     --> They could then set their laptop up with the same IP address
as a faculty
           member's office computer and defeat ordinary /etc/exports
filtering based
           on client IP address.

However, these students would not have the X.509 cert. with a DNS or IP field
set to the correct address in it. (They might have a valid cert. so
their laptop can
mount the file systems students have coursework assignments on, but it would
not have the DNS or IP of a faculty member's office computer.)
--> This additional filtering would stop them from accessing the
marks/exam question
      file system (or at least make it a lot harder for them to do so).

As already discussed, there is a tradeoff between using DNS or IP. (I'll admit
FreeBSD doesn't currently support the IP case, but it probably should.)

rick

>
> What would the administrative interface look like? Could be the machine
> name in /etc/exports, for instance:
>
> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>
> But I worry that will not be flexible enough. A more general filter
> mechanism might need something like the ini file format used to create
> CSRs.
>
>
> What about pre-shared keys? No certificate fields there.
>
>
> --
> Chuck Lever

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

[Chuck Lever]

On 5/27/25 12:29 PM, Rick Macklem wrote:
> On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On 5/25/25 8:09 PM, NeilBrown wrote:
>>> On Mon, 26 May 2025, Chuck Lever wrote:
>>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>>> Hiya Rick -
>>>>>
>>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>>
>>>>>> Do you also have some configurable settings for if/how the DNS
>>>>>> field in the client's X.509 cert is checked?
>>>>>> The range is, imho:
>>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>>    the client's IP host address.
>>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>>
>>>>> I've been told repeatedly that certificate verification must not depend
>>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>>> in the certificate's SAN.
>>>>>
>>>>> I recognize that tlshd will need to bend a little for clients that use
>>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>>> Perhaps client certificates do not need to contain their peer IP
>>>>> address, but server certificates do, in order to enable mounting by IP
>>>>> instead of by hostname.
>>>>>
>>>>>
>>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>>
>>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>>> rather than a particular implementation that might have historical
>>>>> reasons to permit a lack of security.
>>>>
>>>> Let me follow up on this.
>>>>
>>>> We have an open issue against tlshd that has suggested that, rather
>>>> than looking at DNS query results, the NFS server should authorize
>>>> access by looking at the client certificate's CN. The server's
>>>> administrator should be able to specify a list of one or more CN
>>>> wildcards that can be used to authorize access, much in the same way
>>>> that NFSD currently uses netgroups and hostnames per export.
>>>>
>>>> So, after validating the client's CA trust chain, an NFS server can
>>>> match the client certificate's CN against its list of authorized CNs,
>>>> and if the client's CN fails to match, fail the handshake (or whatever
>>>> we need to do).
>>>>
>>>> I favor this approach over using DNS labels, which are often
>>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>>
>>>> What do you think?
>>>
>>> I completely agree with this.  IP address and DNS identity of the client
>>> is irrelevant when mTLS is used.  What matters is whether the client has
>>> authority to act as one of the the names given when the filesystem was
>>> exported (e.g. in /etc/exports).  His is exacly what you said.
>>>
>>> Ideally it would be more than just the CN.  We want to know both the
>>> domain in which the peer has authority (e.g.  example.com) and the type
>>> of authority (e.g.  serve-web-pages or proxy-file-access or
>>> act-as-neilb).
>>> I don't know internal details of certificates so I don't know if there
>>> is some other field that can say "This peer is authorised to proxy file
>>> access requests for all users in the given domain" or if we need a hack
>>> like exporting to nfs-client.example.com.
>>>
>>> But if the admin has full control of what names to export to, it is
>>> possible that the distinction doesn't matter.  I wouldn't want the
>>> certificate used to authenticate my web server to have authority to
>>> access all files on my NFS server just because the same domain name
>>> applies to both.
>>
>> My thought is that, for each handshake, there would be two stages:
>>
>> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>>    trust issue, so validating the certificate presented by the client is
>>    the order of the day.
>>
>> 2. Does the NFS server authorize this client to access the export? This
>>    is a check very similar to the hostname/netgroup/IP address check
>>    that is done today, but it could be done just once at handshake time.
>>    Match the certificate's fields against a per-export filter.
>>
>> I would take tlshd out of the picture for stage 2, and let NFSD make its
>> own authorization decisions. Because an NFS client might be authorized
>> to access some exports but not others.
>>
>> So:
>>
>> How does the server indicate to clients that yes, your cert is trusted,
>> but no, you are not authorized to access this file system? I guess that
>> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>>
>> What certificate fields should we implement matches for? CN is obvious.
>> But what about SAN? Any others? I say start with only CN, but I'd like
>> to think about ways to make it possible to match against other fields in
>> the future.
> Just fyi, here's an example where filtering on the DNS or IP field in the
> SAN (SubjectAltName) could improve security..
> (Dusting off my CS sysadmin hat.)
> 
> Suppose I had a file system where student grades and exam questions
> were stored.
> The mount was restricted to faculty offices, where their machines had fixed
> well known IP addresses and FQDNs assigned.
> However, as it was for my case, the building their offices were in also had
> student labs and the building was assigned a subnet by the campus
> networking folk.
> --> As such, a student could easily come in off hours (when the faculty were not
>      around and, as such, had their office computers shut down) and
> plug into the
>      subnet (they just had to find an RJ45 jack somewhere that they
> could access).
>      --> They could then set their laptop up with the same IP address
> as a faculty
>            member's office computer and defeat ordinary /etc/exports
> filtering based
>            on client IP address.
> 
> However, these students would not have the X.509 cert. with a DNS or IP field
> set to the correct address in it. (They might have a valid cert. so
> their laptop can
> mount the file systems students have coursework assignments on, but it would
> not have the DNS or IP of a faculty member's office computer.)
> --> This additional filtering would stop them from accessing the
> marks/exam question
>       file system (or at least make it a lot harder for them to do so).
> 
> As already discussed, there is a tradeoff between using DNS or IP. (I'll admit
> FreeBSD doesn't currently support the IP case, but it probably should.)

To be clear, there is a marked difference between relying on reverse DNS
queries versus relying on a DNS hostname or IP address contained in a
client certificate's SAN field. DNS queries are untrustworthy, but
fields in a certificate (once its trust chain has been validated) are OK
to use, IMO.

But I would like NFSD's administrative interface to be unambiguous about
which DNS/IP information is being matched against.


> rick
> 
>>
>> What would the administrative interface look like? Could be the machine
>> name in /etc/exports, for instance:
>>
>> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>>
>> But I worry that will not be flexible enough. A more general filter
>> mechanism might need something like the ini file format used to create
>> CSRs.
>>
>>
>> What about pre-shared keys? No certificate fields there.
>>
>>
>> --
>> Chuck Lever


-- 
Chuck Lever

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

[Rick Macklem]

On Tue, May 27, 2025 at 9:58 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> On 5/27/25 12:29 PM, Rick Macklem wrote:
> > On Tue, May 27, 2025 at 8:05 AM Chuck Lever <chuck.lever@oracle.com> wrote:
> >>
> >> On 5/25/25 8:09 PM, NeilBrown wrote:
> >>> On Mon, 26 May 2025, Chuck Lever wrote:
> >>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
> >>>>> Hiya Rick -
> >>>>>
> >>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> >>>>>
> >>>>>> Do you also have some configurable settings for if/how the DNS
> >>>>>> field in the client's X.509 cert is checked?
> >>>>>> The range is, imho:
> >>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>>>>>   device). The least secure, but still pretty good, since the ert. verified.
> >>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>>>>>    the client's IP host address.
> >>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> >>>>>
> >>>>> I've been told repeatedly that certificate verification must not depend
> >>>>> on DNS because DNS can be easily spoofed. To date, the Linux
> >>>>> implementation of RPC-with-TLS depends on having the peer's IP address
> >>>>> in the certificate's SAN.
> >>>>>
> >>>>> I recognize that tlshd will need to bend a little for clients that use
> >>>>> a dynamically allocated IP address, but I haven't looked into it yet.
> >>>>> Perhaps client certificates do not need to contain their peer IP
> >>>>> address, but server certificates do, in order to enable mounting by IP
> >>>>> instead of by hostname.
> >>>>>
> >>>>>
> >>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> >>>>>
> >>>>> I would prefer that we follow the guidance of RFCs where possible,
> >>>>> rather than a particular implementation that might have historical
> >>>>> reasons to permit a lack of security.
> >>>>
> >>>> Let me follow up on this.
> >>>>
> >>>> We have an open issue against tlshd that has suggested that, rather
> >>>> than looking at DNS query results, the NFS server should authorize
> >>>> access by looking at the client certificate's CN. The server's
> >>>> administrator should be able to specify a list of one or more CN
> >>>> wildcards that can be used to authorize access, much in the same way
> >>>> that NFSD currently uses netgroups and hostnames per export.
> >>>>
> >>>> So, after validating the client's CA trust chain, an NFS server can
> >>>> match the client certificate's CN against its list of authorized CNs,
> >>>> and if the client's CN fails to match, fail the handshake (or whatever
> >>>> we need to do).
> >>>>
> >>>> I favor this approach over using DNS labels, which are often
> >>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
> >>>>
> >>>> What do you think?
> >>>
> >>> I completely agree with this.  IP address and DNS identity of the client
> >>> is irrelevant when mTLS is used.  What matters is whether the client has
> >>> authority to act as one of the the names given when the filesystem was
> >>> exported (e.g. in /etc/exports).  His is exacly what you said.
> >>>
> >>> Ideally it would be more than just the CN.  We want to know both the
> >>> domain in which the peer has authority (e.g.  example.com) and the type
> >>> of authority (e.g.  serve-web-pages or proxy-file-access or
> >>> act-as-neilb).
> >>> I don't know internal details of certificates so I don't know if there
> >>> is some other field that can say "This peer is authorised to proxy file
> >>> access requests for all users in the given domain" or if we need a hack
> >>> like exporting to nfs-client.example.com.
> >>>
> >>> But if the admin has full control of what names to export to, it is
> >>> possible that the distinction doesn't matter.  I wouldn't want the
> >>> certificate used to authenticate my web server to have authority to
> >>> access all files on my NFS server just because the same domain name
> >>> applies to both.
> >>
> >> My thought is that, for each handshake, there would be two stages:
> >>
> >> 1. Does the NFS server trust the certificate? This is purely a chain-of-
> >>    trust issue, so validating the certificate presented by the client is
> >>    the order of the day.
> >>
> >> 2. Does the NFS server authorize this client to access the export? This
> >>    is a check very similar to the hostname/netgroup/IP address check
> >>    that is done today, but it could be done just once at handshake time.
> >>    Match the certificate's fields against a per-export filter.
> >>
> >> I would take tlshd out of the picture for stage 2, and let NFSD make its
> >> own authorization decisions. Because an NFS client might be authorized
> >> to access some exports but not others.
> >>
> >> So:
> >>
> >> How does the server indicate to clients that yes, your cert is trusted,
> >> but no, you are not authorized to access this file system? I guess that
> >> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
> >>
> >> What certificate fields should we implement matches for? CN is obvious.
> >> But what about SAN? Any others? I say start with only CN, but I'd like
> >> to think about ways to make it possible to match against other fields in
> >> the future.
> > Just fyi, here's an example where filtering on the DNS or IP field in the
> > SAN (SubjectAltName) could improve security..
> > (Dusting off my CS sysadmin hat.)
> >
> > Suppose I had a file system where student grades and exam questions
> > were stored.
> > The mount was restricted to faculty offices, where their machines had fixed
> > well known IP addresses and FQDNs assigned.
> > However, as it was for my case, the building their offices were in also had
> > student labs and the building was assigned a subnet by the campus
> > networking folk.
> > --> As such, a student could easily come in off hours (when the faculty were not
> >      around and, as such, had their office computers shut down) and
> > plug into the
> >      subnet (they just had to find an RJ45 jack somewhere that they
> > could access).
> >      --> They could then set their laptop up with the same IP address
> > as a faculty
> >            member's office computer and defeat ordinary /etc/exports
> > filtering based
> >            on client IP address.
> >
> > However, these students would not have the X.509 cert. with a DNS or IP field
> > set to the correct address in it. (They might have a valid cert. so
> > their laptop can
> > mount the file systems students have coursework assignments on, but it would
> > not have the DNS or IP of a faculty member's office computer.)
> > --> This additional filtering would stop them from accessing the
> > marks/exam question
> >       file system (or at least make it a lot harder for them to do so).
> >
> > As already discussed, there is a tradeoff between using DNS or IP. (I'll admit
> > FreeBSD doesn't currently support the IP case, but it probably should.)
>
> To be clear, there is a marked difference between relying on reverse DNS
> queries versus relying on a DNS hostname or IP address contained in a
> client certificate's SAN field. DNS queries are untrustworthy, but
> fields in a certificate (once its trust chain has been validated) are OK
> to use, IMO.
Yes, after sending this (an early morning brain fart;-) I realized I actually
just demonstrated a case where the IP or DNS field matching the client's
host IP address was not useful.
--> For the above example, it only shows that certs. can be differentiated
      between student and faculty.

However, having the IP/DNS match work limits the use of a compromised
cert. to the subnet it was meant to be used on.
Or, put another way, if the faculty offices are on a separate subnet from
the student labs, the students would have difficulties using a compromised
cert. before it ends up in a CRL. (Admittedly, for separate subnets, just
filtering on client host IP address as /etc/exports now does can work, as well.)

Another advantage of using client certs is the "identity squashing" case,
where the cert. identifies the user, avoiding any need for Kerberos.
(Then, if the compromised cert. cannot be used outside of the subnet
it was issued for, you are in a better place than if the compromised cert.
can be used from anywhere.)

I do think CRLs should be supported, but it takes a while for someone
to realize a cert. has been compromised and then do what it takes to
get it into a CRL (notifying the sysadmin or ??).

rick

>
> But I would like NFSD's administrative interface to be unambiguous about
> which DNS/IP information is being matched against.
>
>
> > rick
> >
> >>
> >> What would the administrative interface look like? Could be the machine
> >> name in /etc/exports, for instance:
> >>
> >> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
> >>
> >> But I worry that will not be flexible enough. A more general filter
> >> mechanism might need something like the ini file format used to create
> >> CSRs.
> >>
> >>
> >> What about pre-shared keys? No certificate fields there.
> >>
> >>
> >> --
> >> Chuck Lever
>
>
> --
> Chuck Lever

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

[Benjamin Coddington]

On 27 May 2025, at 11:05, Chuck Lever wrote:

> On 5/25/25 8:09 PM, NeilBrown wrote:
>> On Mon, 26 May 2025, Chuck Lever wrote:
>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>> Hiya Rick -
>>>>
>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>
>>>>> Do you also have some configurable settings for if/how the DNS
>>>>> field in the client's X.509 cert is checked?
>>>>> The range is, imho:
>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>    the client's IP host address.
>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>
>>>> I've been told repeatedly that certificate verification must not depend
>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>> in the certificate's SAN.
>>>>
>>>> I recognize that tlshd will need to bend a little for clients that use
>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>> Perhaps client certificates do not need to contain their peer IP
>>>> address, but server certificates do, in order to enable mounting by IP
>>>> instead of by hostname.
>>>>
>>>>
>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>
>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>> rather than a particular implementation that might have historical
>>>> reasons to permit a lack of security.
>>>
>>> Let me follow up on this.
>>>
>>> We have an open issue against tlshd that has suggested that, rather
>>> than looking at DNS query results, the NFS server should authorize
>>> access by looking at the client certificate's CN. The server's
>>> administrator should be able to specify a list of one or more CN
>>> wildcards that can be used to authorize access, much in the same way
>>> that NFSD currently uses netgroups and hostnames per export.
>>>
>>> So, after validating the client's CA trust chain, an NFS server can
>>> match the client certificate's CN against its list of authorized CNs,
>>> and if the client's CN fails to match, fail the handshake (or whatever
>>> we need to do).
>>>
>>> I favor this approach over using DNS labels, which are often
>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>
>>> What do you think?
>>
>> I completely agree with this.  IP address and DNS identity of the client
>> is irrelevant when mTLS is used.  What matters is whether the client has
>> authority to act as one of the the names given when the filesystem was
>> exported (e.g. in /etc/exports).  His is exacly what you said.
>>
>> Ideally it would be more than just the CN.  We want to know both the
>> domain in which the peer has authority (e.g.  example.com) and the type
>> of authority (e.g.  serve-web-pages or proxy-file-access or
>> act-as-neilb).
>> I don't know internal details of certificates so I don't know if there
>> is some other field that can say "This peer is authorised to proxy file
>> access requests for all users in the given domain" or if we need a hack
>> like exporting to nfs-client.example.com.
>>
>> But if the admin has full control of what names to export to, it is
>> possible that the distinction doesn't matter.  I wouldn't want the
>> certificate used to authenticate my web server to have authority to
>> access all files on my NFS server just because the same domain name
>> applies to both.
>
> My thought is that, for each handshake, there would be two stages:
>
> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>    trust issue, so validating the certificate presented by the client is
>    the order of the day.
>
> 2. Does the NFS server authorize this client to access the export? This
>    is a check very similar to the hostname/netgroup/IP address check
>    that is done today, but it could be done just once at handshake time.
>    Match the certificate's fields against a per-export filter.
>
> I would take tlshd out of the picture for stage 2, and let NFSD make its
> own authorization decisions. Because an NFS client might be authorized
> to access some exports but not others.
>
> So:
>
> How does the server indicate to clients that yes, your cert is trusted,
> but no, you are not authorized to access this file system? I guess that
> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>
> What certificate fields should we implement matches for? CN is obvious.
> But what about SAN? Any others? I say start with only CN, but I'd like
> to think about ways to make it possible to match against other fields in
> the future.
>
> What would the administrative interface look like? Could be the machine
> name in /etc/exports, for instance:
>
> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>
> But I worry that will not be flexible enough. A more general filter
> mechanism might need something like the ini file format used to create
> CSRs.

It might be useful to make the kernel's authorization based on mapping to a
keyword that tlshd passes back after the handshake, and keep the more
complicated logic of parsing certificate fields and using config files up in
ktls-utils userspace.  I'm imagining something like this in /etc/exports:

/exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
/exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)

.. and then tlshd would do the work to create a map of authorized
certificate identities mapped to a keyword, something like:

CN=*                any
CN=*.nfsv4bat.org   users
SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob

I imagine more flexible or complex rule logic might be desired in the
future, and having that work land in ktls-utils would be nicer than having
to do kernel work or handling various bits of certificate logic or reverse
lookups in-kernel.

> What about pre-shared keys? No certificate fields there.

Same idea would work for those - list/map them to a keyword set on the
export.

Ben

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

[Chuck Lever]

On 5/27/25 3:18 PM, Benjamin Coddington wrote:
> On 27 May 2025, at 11:05, Chuck Lever wrote:
> 
>> On 5/25/25 8:09 PM, NeilBrown wrote:
>>> On Mon, 26 May 2025, Chuck Lever wrote:
>>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>>> Hiya Rick -
>>>>>
>>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>>
>>>>>> Do you also have some configurable settings for if/how the DNS
>>>>>> field in the client's X.509 cert is checked?
>>>>>> The range is, imho:
>>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>>    the client's IP host address.
>>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>>
>>>>> I've been told repeatedly that certificate verification must not depend
>>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>>> in the certificate's SAN.
>>>>>
>>>>> I recognize that tlshd will need to bend a little for clients that use
>>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>>> Perhaps client certificates do not need to contain their peer IP
>>>>> address, but server certificates do, in order to enable mounting by IP
>>>>> instead of by hostname.
>>>>>
>>>>>
>>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>>
>>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>>> rather than a particular implementation that might have historical
>>>>> reasons to permit a lack of security.
>>>>
>>>> Let me follow up on this.
>>>>
>>>> We have an open issue against tlshd that has suggested that, rather
>>>> than looking at DNS query results, the NFS server should authorize
>>>> access by looking at the client certificate's CN. The server's
>>>> administrator should be able to specify a list of one or more CN
>>>> wildcards that can be used to authorize access, much in the same way
>>>> that NFSD currently uses netgroups and hostnames per export.
>>>>
>>>> So, after validating the client's CA trust chain, an NFS server can
>>>> match the client certificate's CN against its list of authorized CNs,
>>>> and if the client's CN fails to match, fail the handshake (or whatever
>>>> we need to do).
>>>>
>>>> I favor this approach over using DNS labels, which are often
>>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>>
>>>> What do you think?
>>>
>>> I completely agree with this.  IP address and DNS identity of the client
>>> is irrelevant when mTLS is used.  What matters is whether the client has
>>> authority to act as one of the the names given when the filesystem was
>>> exported (e.g. in /etc/exports).  His is exacly what you said.
>>>
>>> Ideally it would be more than just the CN.  We want to know both the
>>> domain in which the peer has authority (e.g.  example.com) and the type
>>> of authority (e.g.  serve-web-pages or proxy-file-access or
>>> act-as-neilb).
>>> I don't know internal details of certificates so I don't know if there
>>> is some other field that can say "This peer is authorised to proxy file
>>> access requests for all users in the given domain" or if we need a hack
>>> like exporting to nfs-client.example.com.
>>>
>>> But if the admin has full control of what names to export to, it is
>>> possible that the distinction doesn't matter.  I wouldn't want the
>>> certificate used to authenticate my web server to have authority to
>>> access all files on my NFS server just because the same domain name
>>> applies to both.
>>
>> My thought is that, for each handshake, there would be two stages:
>>
>> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>>    trust issue, so validating the certificate presented by the client is
>>    the order of the day.
>>
>> 2. Does the NFS server authorize this client to access the export? This
>>    is a check very similar to the hostname/netgroup/IP address check
>>    that is done today, but it could be done just once at handshake time.
>>    Match the certificate's fields against a per-export filter.
>>
>> I would take tlshd out of the picture for stage 2, and let NFSD make its
>> own authorization decisions. Because an NFS client might be authorized
>> to access some exports but not others.
>>
>> So:
>>
>> How does the server indicate to clients that yes, your cert is trusted,
>> but no, you are not authorized to access this file system? I guess that
>> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>>
>> What certificate fields should we implement matches for? CN is obvious.
>> But what about SAN? Any others? I say start with only CN, but I'd like
>> to think about ways to make it possible to match against other fields in
>> the future.
>>
>> What would the administrative interface look like? Could be the machine
>> name in /etc/exports, for instance:
>>
>> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>>
>> But I worry that will not be flexible enough. A more general filter
>> mechanism might need something like the ini file format used to create
>> CSRs.
> 
> It might be useful to make the kernel's authorization based on mapping to a
> keyword that tlshd passes back after the handshake, and keep the more
> complicated logic of parsing certificate fields and using config files up in
> ktls-utils userspace.

I agree that the kernel can't do the filtering.

But it's not possible that tlshd knows what export the client wants to
access during the TLS handshake; no NFS traffic has been exchanged yet.
Thus parsing per-export security settings during the handshake is not
possible; it can happen only once tlshd passes the connected socket back
to the kernel.

And remember that ktls-utils is shared with NVMe and now QUIC as well.
tlshd doesn't know anything about the upper layer protocols. Therefore
adding NFS-specific authorization policy settings to ktls-utils is a
layering violation.

What makes the most sense is that the handshake succeeds, then NFSD
permits the client to access any export resources that the server's
per-export security policy allows, based on the client's cert.


> I'm imagining something like this in /etc/exports:
> 
> /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
> /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
> 
> .. and then tlshd would do the work to create a map of authorized
> certificate identities mapped to a keyword, something like:
> 
> CN=*                any
> CN=*.nfsv4bat.org   users
> SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob

I think mountd is going to have to do that, somehow. It already knows
about netgroups, for example, and this is very similar.


> I imagine more flexible or complex rule logic might be desired in the
> future, and having that work land in ktls-utils would be nicer than having
> to do kernel work or handling various bits of certificate logic or reverse
> lookups in-kernel.

I agree that the kernel will have to be hands off (or, it will act as a
pipe between the user space pieces that actually handle the security
policy, if you will).


-- 
Chuck Lever

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

[Benjamin Coddington]

On 27 May 2025, at 15:41, Chuck Lever wrote:

> On 5/27/25 3:18 PM, Benjamin Coddington wrote:
>> On 27 May 2025, at 11:05, Chuck Lever wrote:
>>
>>> On 5/25/25 8:09 PM, NeilBrown wrote:
>>>> On Mon, 26 May 2025, Chuck Lever wrote:
>>>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>>>> Hiya Rick -
>>>>>>
>>>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>>>
>>>>>>> Do you also have some configurable settings for if/how the DNS
>>>>>>> field in the client's X.509 cert is checked?
>>>>>>> The range is, imho:
>>>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>>>    the client's IP host address.
>>>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>>>
>>>>>> I've been told repeatedly that certificate verification must not depend
>>>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>>>> in the certificate's SAN.
>>>>>>
>>>>>> I recognize that tlshd will need to bend a little for clients that use
>>>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>>>> Perhaps client certificates do not need to contain their peer IP
>>>>>> address, but server certificates do, in order to enable mounting by IP
>>>>>> instead of by hostname.
>>>>>>
>>>>>>
>>>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>>>
>>>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>>>> rather than a particular implementation that might have historical
>>>>>> reasons to permit a lack of security.
>>>>>
>>>>> Let me follow up on this.
>>>>>
>>>>> We have an open issue against tlshd that has suggested that, rather
>>>>> than looking at DNS query results, the NFS server should authorize
>>>>> access by looking at the client certificate's CN. The server's
>>>>> administrator should be able to specify a list of one or more CN
>>>>> wildcards that can be used to authorize access, much in the same way
>>>>> that NFSD currently uses netgroups and hostnames per export.
>>>>>
>>>>> So, after validating the client's CA trust chain, an NFS server can
>>>>> match the client certificate's CN against its list of authorized CNs,
>>>>> and if the client's CN fails to match, fail the handshake (or whatever
>>>>> we need to do).
>>>>>
>>>>> I favor this approach over using DNS labels, which are often
>>>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>>>
>>>>> What do you think?
>>>>
>>>> I completely agree with this.  IP address and DNS identity of the client
>>>> is irrelevant when mTLS is used.  What matters is whether the client has
>>>> authority to act as one of the the names given when the filesystem was
>>>> exported (e.g. in /etc/exports).  His is exacly what you said.
>>>>
>>>> Ideally it would be more than just the CN.  We want to know both the
>>>> domain in which the peer has authority (e.g.  example.com) and the type
>>>> of authority (e.g.  serve-web-pages or proxy-file-access or
>>>> act-as-neilb).
>>>> I don't know internal details of certificates so I don't know if there
>>>> is some other field that can say "This peer is authorised to proxy file
>>>> access requests for all users in the given domain" or if we need a hack
>>>> like exporting to nfs-client.example.com.
>>>>
>>>> But if the admin has full control of what names to export to, it is
>>>> possible that the distinction doesn't matter.  I wouldn't want the
>>>> certificate used to authenticate my web server to have authority to
>>>> access all files on my NFS server just because the same domain name
>>>> applies to both.
>>>
>>> My thought is that, for each handshake, there would be two stages:
>>>
>>> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>>>    trust issue, so validating the certificate presented by the client is
>>>    the order of the day.
>>>
>>> 2. Does the NFS server authorize this client to access the export? This
>>>    is a check very similar to the hostname/netgroup/IP address check
>>>    that is done today, but it could be done just once at handshake time.
>>>    Match the certificate's fields against a per-export filter.
>>>
>>> I would take tlshd out of the picture for stage 2, and let NFSD make its
>>> own authorization decisions. Because an NFS client might be authorized
>>> to access some exports but not others.
>>>
>>> So:
>>>
>>> How does the server indicate to clients that yes, your cert is trusted,
>>> but no, you are not authorized to access this file system? I guess that
>>> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>>>
>>> What certificate fields should we implement matches for? CN is obvious.
>>> But what about SAN? Any others? I say start with only CN, but I'd like
>>> to think about ways to make it possible to match against other fields in
>>> the future.
>>>
>>> What would the administrative interface look like? Could be the machine
>>> name in /etc/exports, for instance:
>>>
>>> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>>>
>>> But I worry that will not be flexible enough. A more general filter
>>> mechanism might need something like the ini file format used to create
>>> CSRs.
>>
>> It might be useful to make the kernel's authorization based on mapping to a
>> keyword that tlshd passes back after the handshake, and keep the more
>> complicated logic of parsing certificate fields and using config files up in
>> ktls-utils userspace.
>
> I agree that the kernel can't do the filtering.
>
> But it's not possible that tlshd knows what export the client wants to
> access during the TLS handshake; no NFS traffic has been exchanged yet.
> Thus parsing per-export security settings during the handshake is not
> possible; it can happen only once tlshd passes the connected socket back
> to the kernel.
>
> And remember that ktls-utils is shared with NVMe and now QUIC as well.
> tlshd doesn't know anything about the upper layer protocols. Therefore
> adding NFS-specific authorization policy settings to ktls-utils is a
> layering violation.

Here tlshd doesn't need to know anything about the upper layer protocols, it
merely uses its mapping rules to match the certificate to a keyword it
passes back to the kernel in the successful handshake downcall.  The kernel
then can decide what that keyword means.  If not implemented in-kernel it
can merely be ignored.

> What makes the most sense is that the handshake succeeds, then NFSD
> permits the client to access any export resources that the server's
> per-export security policy allows, based on the client's cert.
>
>
>> I'm imagining something like this in /etc/exports:
>>
>> /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
>> /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
>>
>> .. and then tlshd would do the work to create a map of authorized
>> certificate identities mapped to a keyword, something like:
>>
>> CN=*                any
>> CN=*.nfsv4bat.org   users
>> SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob
>
> I think mountd is going to have to do that, somehow. It already knows
> about netgroups, for example, and this is very similar.

That sounds.. complicated.

Ben

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

[Chuck Lever]

On 5/27/25 4:25 PM, Benjamin Coddington wrote:
> On 27 May 2025, at 15:41, Chuck Lever wrote:
> 
>> On 5/27/25 3:18 PM, Benjamin Coddington wrote:
>>> On 27 May 2025, at 11:05, Chuck Lever wrote:
>>>
>>>> On 5/25/25 8:09 PM, NeilBrown wrote:
>>>>> On Mon, 26 May 2025, Chuck Lever wrote:
>>>>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
>>>>>>> Hiya Rick -
>>>>>>>
>>>>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
>>>>>>>
>>>>>>>> Do you also have some configurable settings for if/how the DNS
>>>>>>>> field in the client's X.509 cert is checked?
>>>>>>>> The range is, imho:
>>>>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
>>>>>>>>   device). The least secure, but still pretty good, since the ert. verified.
>>>>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
>>>>>>>>    the client's IP host address.
>>>>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
>>>>>>>
>>>>>>> I've been told repeatedly that certificate verification must not depend
>>>>>>> on DNS because DNS can be easily spoofed. To date, the Linux
>>>>>>> implementation of RPC-with-TLS depends on having the peer's IP address
>>>>>>> in the certificate's SAN.
>>>>>>>
>>>>>>> I recognize that tlshd will need to bend a little for clients that use
>>>>>>> a dynamically allocated IP address, but I haven't looked into it yet.
>>>>>>> Perhaps client certificates do not need to contain their peer IP
>>>>>>> address, but server certificates do, in order to enable mounting by IP
>>>>>>> instead of by hostname.
>>>>>>>
>>>>>>>
>>>>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
>>>>>>>
>>>>>>> I would prefer that we follow the guidance of RFCs where possible,
>>>>>>> rather than a particular implementation that might have historical
>>>>>>> reasons to permit a lack of security.
>>>>>>
>>>>>> Let me follow up on this.
>>>>>>
>>>>>> We have an open issue against tlshd that has suggested that, rather
>>>>>> than looking at DNS query results, the NFS server should authorize
>>>>>> access by looking at the client certificate's CN. The server's
>>>>>> administrator should be able to specify a list of one or more CN
>>>>>> wildcards that can be used to authorize access, much in the same way
>>>>>> that NFSD currently uses netgroups and hostnames per export.
>>>>>>
>>>>>> So, after validating the client's CA trust chain, an NFS server can
>>>>>> match the client certificate's CN against its list of authorized CNs,
>>>>>> and if the client's CN fails to match, fail the handshake (or whatever
>>>>>> we need to do).
>>>>>>
>>>>>> I favor this approach over using DNS labels, which are often
>>>>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
>>>>>>
>>>>>> What do you think?
>>>>>
>>>>> I completely agree with this.  IP address and DNS identity of the client
>>>>> is irrelevant when mTLS is used.  What matters is whether the client has
>>>>> authority to act as one of the the names given when the filesystem was
>>>>> exported (e.g. in /etc/exports).  His is exacly what you said.
>>>>>
>>>>> Ideally it would be more than just the CN.  We want to know both the
>>>>> domain in which the peer has authority (e.g.  example.com) and the type
>>>>> of authority (e.g.  serve-web-pages or proxy-file-access or
>>>>> act-as-neilb).
>>>>> I don't know internal details of certificates so I don't know if there
>>>>> is some other field that can say "This peer is authorised to proxy file
>>>>> access requests for all users in the given domain" or if we need a hack
>>>>> like exporting to nfs-client.example.com.
>>>>>
>>>>> But if the admin has full control of what names to export to, it is
>>>>> possible that the distinction doesn't matter.  I wouldn't want the
>>>>> certificate used to authenticate my web server to have authority to
>>>>> access all files on my NFS server just because the same domain name
>>>>> applies to both.
>>>>
>>>> My thought is that, for each handshake, there would be two stages:
>>>>
>>>> 1. Does the NFS server trust the certificate? This is purely a chain-of-
>>>>    trust issue, so validating the certificate presented by the client is
>>>>    the order of the day.
>>>>
>>>> 2. Does the NFS server authorize this client to access the export? This
>>>>    is a check very similar to the hostname/netgroup/IP address check
>>>>    that is done today, but it could be done just once at handshake time.
>>>>    Match the certificate's fields against a per-export filter.
>>>>
>>>> I would take tlshd out of the picture for stage 2, and let NFSD make its
>>>> own authorization decisions. Because an NFS client might be authorized
>>>> to access some exports but not others.
>>>>
>>>> So:
>>>>
>>>> How does the server indicate to clients that yes, your cert is trusted,
>>>> but no, you are not authorized to access this file system? I guess that
>>>> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
>>>>
>>>> What certificate fields should we implement matches for? CN is obvious.
>>>> But what about SAN? Any others? I say start with only CN, but I'd like
>>>> to think about ways to make it possible to match against other fields in
>>>> the future.
>>>>
>>>> What would the administrative interface look like? Could be the machine
>>>> name in /etc/exports, for instance:
>>>>
>>>> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
>>>>
>>>> But I worry that will not be flexible enough. A more general filter
>>>> mechanism might need something like the ini file format used to create
>>>> CSRs.
>>>
>>> It might be useful to make the kernel's authorization based on mapping to a
>>> keyword that tlshd passes back after the handshake, and keep the more
>>> complicated logic of parsing certificate fields and using config files up in
>>> ktls-utils userspace.
>>
>> I agree that the kernel can't do the filtering.
>>
>> But it's not possible that tlshd knows what export the client wants to
>> access during the TLS handshake; no NFS traffic has been exchanged yet.
>> Thus parsing per-export security settings during the handshake is not
>> possible; it can happen only once tlshd passes the connected socket back
>> to the kernel.
>>
>> And remember that ktls-utils is shared with NVMe and now QUIC as well.
>> tlshd doesn't know anything about the upper layer protocols. Therefore
>> adding NFS-specific authorization policy settings to ktls-utils is a
>> layering violation.
> 
> Here tlshd doesn't need to know anything about the upper layer protocols, it
> merely uses its mapping rules to match the certificate to a keyword it
> passes back to the kernel in the successful handshake downcall.  The kernel
> then can decide what that keyword means.  If not implemented in-kernel it
> can merely be ignored.

Actually this sounds close to what I was imagining.

Following the NIS netgroups metaphor, some other user space system would
define groups, and then /etc/exports could use those to define security
policy. tlshd would know nothing of NFS, and mountd would know nothing
of certificates.

Here, tlshd would match a list of groups that the client certificate
belongs to, and return that list to the kernel as part of a successful
handshake. That list could be either passed to mountd, or mountd could
provide the group list on the export and let the kernel match on that.

I guess the TLS groups would be defined in /etc/tlshd.conf. Any upper
layer protocol can use or ignore them.

TLS groups would be wildcards that might include CN, SAN, certificate
serial no., etc. So NFSD could still filter by the IP or hostname in the
certificate presented by the client.

Then, would TLS groups be specified in the export entry's machine name,
like netgroups today, or would we add a new export option? I'm still
mulling Rick's suggestion about continuing to restrict mtls access by
actual IP.


>> What makes the most sense is that the handshake succeeds, then NFSD
>> permits the client to access any export resources that the server's
>> per-export security policy allows, based on the client's cert.
>>
>>
>>> I'm imagining something like this in /etc/exports:
>>>
>>> /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
>>> /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
>>>
>>> .. and then tlshd would do the work to create a map of authorized
>>> certificate identities mapped to a keyword, something like:
>>>
>>> CN=*                any
>>> CN=*.nfsv4bat.org   users
>>> SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob
>>
>> I think mountd is going to have to do that, somehow. It already knows
>> about netgroups, for example, and this is very similar.
> 
> That sounds.. complicated.
> 
> Ben
> 


-- 
Chuck Lever

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

[NeilBrown]

On Wed, 28 May 2025, Chuck Lever wrote:
> On 5/27/25 3:18 PM, Benjamin Coddington wrote:
> > On 27 May 2025, at 11:05, Chuck Lever wrote:
> > 
> >> On 5/25/25 8:09 PM, NeilBrown wrote:
> >>> On Mon, 26 May 2025, Chuck Lever wrote:
> >>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
> >>>>> Hiya Rick -
> >>>>>
> >>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> >>>>>
> >>>>>> Do you also have some configurable settings for if/how the DNS
> >>>>>> field in the client's X.509 cert is checked?
> >>>>>> The range is, imho:
> >>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> >>>>>>   device). The least secure, but still pretty good, since the ert. verified.
> >>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> >>>>>>    the client's IP host address.
> >>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> >>>>>
> >>>>> I've been told repeatedly that certificate verification must not depend
> >>>>> on DNS because DNS can be easily spoofed. To date, the Linux
> >>>>> implementation of RPC-with-TLS depends on having the peer's IP address
> >>>>> in the certificate's SAN.
> >>>>>
> >>>>> I recognize that tlshd will need to bend a little for clients that use
> >>>>> a dynamically allocated IP address, but I haven't looked into it yet.
> >>>>> Perhaps client certificates do not need to contain their peer IP
> >>>>> address, but server certificates do, in order to enable mounting by IP
> >>>>> instead of by hostname.
> >>>>>
> >>>>>
> >>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> >>>>>
> >>>>> I would prefer that we follow the guidance of RFCs where possible,
> >>>>> rather than a particular implementation that might have historical
> >>>>> reasons to permit a lack of security.
> >>>>
> >>>> Let me follow up on this.
> >>>>
> >>>> We have an open issue against tlshd that has suggested that, rather
> >>>> than looking at DNS query results, the NFS server should authorize
> >>>> access by looking at the client certificate's CN. The server's
> >>>> administrator should be able to specify a list of one or more CN
> >>>> wildcards that can be used to authorize access, much in the same way
> >>>> that NFSD currently uses netgroups and hostnames per export.
> >>>>
> >>>> So, after validating the client's CA trust chain, an NFS server can
> >>>> match the client certificate's CN against its list of authorized CNs,
> >>>> and if the client's CN fails to match, fail the handshake (or whatever
> >>>> we need to do).
> >>>>
> >>>> I favor this approach over using DNS labels, which are often
> >>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
> >>>>
> >>>> What do you think?
> >>>
> >>> I completely agree with this.  IP address and DNS identity of the client
> >>> is irrelevant when mTLS is used.  What matters is whether the client has
> >>> authority to act as one of the the names given when the filesystem was
> >>> exported (e.g. in /etc/exports).  His is exacly what you said.
> >>>
> >>> Ideally it would be more than just the CN.  We want to know both the
> >>> domain in which the peer has authority (e.g.  example.com) and the type
> >>> of authority (e.g.  serve-web-pages or proxy-file-access or
> >>> act-as-neilb).
> >>> I don't know internal details of certificates so I don't know if there
> >>> is some other field that can say "This peer is authorised to proxy file
> >>> access requests for all users in the given domain" or if we need a hack
> >>> like exporting to nfs-client.example.com.
> >>>
> >>> But if the admin has full control of what names to export to, it is
> >>> possible that the distinction doesn't matter.  I wouldn't want the
> >>> certificate used to authenticate my web server to have authority to
> >>> access all files on my NFS server just because the same domain name
> >>> applies to both.
> >>
> >> My thought is that, for each handshake, there would be two stages:
> >>
> >> 1. Does the NFS server trust the certificate? This is purely a chain-of-
> >>    trust issue, so validating the certificate presented by the client is
> >>    the order of the day.
> >>
> >> 2. Does the NFS server authorize this client to access the export? This
> >>    is a check very similar to the hostname/netgroup/IP address check
> >>    that is done today, but it could be done just once at handshake time.
> >>    Match the certificate's fields against a per-export filter.
> >>
> >> I would take tlshd out of the picture for stage 2, and let NFSD make its
> >> own authorization decisions. Because an NFS client might be authorized
> >> to access some exports but not others.
> >>
> >> So:
> >>
> >> How does the server indicate to clients that yes, your cert is trusted,
> >> but no, you are not authorized to access this file system? I guess that
> >> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
> >>
> >> What certificate fields should we implement matches for? CN is obvious.
> >> But what about SAN? Any others? I say start with only CN, but I'd like
> >> to think about ways to make it possible to match against other fields in
> >> the future.
> >>
> >> What would the administrative interface look like? Could be the machine
> >> name in /etc/exports, for instance:
> >>
> >> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
> >>
> >> But I worry that will not be flexible enough. A more general filter
> >> mechanism might need something like the ini file format used to create
> >> CSRs.
> > 
> > It might be useful to make the kernel's authorization based on mapping to a
> > keyword that tlshd passes back after the handshake, and keep the more
> > complicated logic of parsing certificate fields and using config files up in
> > ktls-utils userspace.
> 
> I agree that the kernel can't do the filtering.
> 
> But it's not possible that tlshd knows what export the client wants to
> access during the TLS handshake; no NFS traffic has been exchanged yet.
> Thus parsing per-export security settings during the handshake is not
> possible; it can happen only once tlshd passes the connected socket back
> to the kernel.
> 
> And remember that ktls-utils is shared with NVMe and now QUIC as well.
> tlshd doesn't know anything about the upper layer protocols. Therefore
> adding NFS-specific authorization policy settings to ktls-utils is a
> layering violation.
> 
> What makes the most sense is that the handshake succeeds, then NFSD
> permits the client to access any export resources that the server's
> per-export security policy allows, based on the client's cert.

We certainly need a mapping between content of the certificate and an
"auth_domain" as understood by net/sunrpc, then a mapping from
auth_domain and filesystem to export options - we already have the
latter.

There seem to be two option for the first mapping.
1/ tlshd can pass the "important" parts of the certificate (and the PSK
  info) to the sunrpc module much as the IP layer currently passes the IP
  address and port number to the sunrpc module.  sunrpc then passes this up to
  mountd which does whatever mapping magic we want and passes down an
  auth_domain which is then used for further lookup.

2/ tlshd can do some initial interpretation of the certificate (and PSK)
  and determine one or more tags which serve to sufficiently classify the
  certificate for local needs.  It passes them to sunrpc and thence to
  mountd which gives relevant details to nfsd.

So the core question is: what sort of info do we want to pass from tlshd
to mountd (via sunrpc) and where is the processing easiest.  Or maybe:
which part of the processing can usefully be shared with other clients
of tlshd and which are truly nfsd-specific?

I'd be inclined to keep as much understanding of the various details of
certificates in tlshd as possible.  It has to deal with some of that
complexity, and mountd really doesn't.

> 
> 
> > I'm imagining something like this in /etc/exports:
> > 
> > /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
> > /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
> > 
> > .. and then tlshd would do the work to create a map of authorized
> > certificate identities mapped to a keyword, something like:
> > 
> > CN=*                any
> > CN=*.nfsv4bat.org   users
> > SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob
> 
> I think mountd is going to have to do that, somehow. It already knows
> about netgroups, for example, and this is very similar.

netgroups is a good example.  mountd knows what a netgroup is but
doesn't really know about the internal details.  There is a function
"innetgr()" which it calls to do the required magic.  We similarly want
a simple way for mountd to know that a given certificate matches a given
tlsgroup.  A library function would be OK.  strcmp would be good too.

We export to a netgroups as: 
        /path @netgroup(options)
could we export to a certificate as
        /path &tlsgroup(options)
??

It's always seems weird to me have the "sec=" in the options list.
The authentication bit comes before the options.  An IP address or
hostname meand AUTH_SYS. A krb5 indicator means krb5 etc.... 
But that isn't the way we went .... unfortunately??

Thanks,
NeilBrown


> 
> 
> > I imagine more flexible or complex rule logic might be desired in the
> > future, and having that work land in ktls-utils would be nicer than having
> > to do kernel work or handling various bits of certificate logic or reverse
> > lookups in-kernel.
> 
> I agree that the kernel will have to be hands off (or, it will act as a
> pipe between the user space pieces that actually handle the security
> policy, if you will).
> 
> 
> -- 
> Chuck Lever
> 

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

[Rick Macklem]

On Tue, May 27, 2025 at 6:24 PM NeilBrown <neil@brown.name> wrote:
>
> On Wed, 28 May 2025, Chuck Lever wrote:
> > On 5/27/25 3:18 PM, Benjamin Coddington wrote:
> > > On 27 May 2025, at 11:05, Chuck Lever wrote:
> > >
> > >> On 5/25/25 8:09 PM, NeilBrown wrote:
> > >>> On Mon, 26 May 2025, Chuck Lever wrote:
> > >>>> On 5/20/25 9:20 AM, Chuck Lever wrote:
> > >>>>> Hiya Rick -
> > >>>>>
> > >>>>> On 5/19/25 9:44 PM, Rick Macklem wrote:
> > >>>>>
> > >>>>>> Do you also have some configurable settings for if/how the DNS
> > >>>>>> field in the client's X.509 cert is checked?
> > >>>>>> The range is, imho:
> > >>>>>> - Don't check it at all, so the client can have any IP/DNS name (a mobile
> > >>>>>>   device). The least secure, but still pretty good, since the ert. verified.
> > >>>>>> - DNS matches a wildcard like *.umich.edu for the reverse DNS name for
> > >>>>>>    the client's IP host address.
> > >>>>>> - DNS matches exactly what reverse DNS gets for the client's IP host address.
> > >>>>>
> > >>>>> I've been told repeatedly that certificate verification must not depend
> > >>>>> on DNS because DNS can be easily spoofed. To date, the Linux
> > >>>>> implementation of RPC-with-TLS depends on having the peer's IP address
> > >>>>> in the certificate's SAN.
> > >>>>>
> > >>>>> I recognize that tlshd will need to bend a little for clients that use
> > >>>>> a dynamically allocated IP address, but I haven't looked into it yet.
> > >>>>> Perhaps client certificates do not need to contain their peer IP
> > >>>>> address, but server certificates do, in order to enable mounting by IP
> > >>>>> instead of by hostname.
> > >>>>>
> > >>>>>
> > >>>>>> Wildcards are discouraged by some RFC, but are still supported by OpenSSL.
> > >>>>>
> > >>>>> I would prefer that we follow the guidance of RFCs where possible,
> > >>>>> rather than a particular implementation that might have historical
> > >>>>> reasons to permit a lack of security.
> > >>>>
> > >>>> Let me follow up on this.
> > >>>>
> > >>>> We have an open issue against tlshd that has suggested that, rather
> > >>>> than looking at DNS query results, the NFS server should authorize
> > >>>> access by looking at the client certificate's CN. The server's
> > >>>> administrator should be able to specify a list of one or more CN
> > >>>> wildcards that can be used to authorize access, much in the same way
> > >>>> that NFSD currently uses netgroups and hostnames per export.
> > >>>>
> > >>>> So, after validating the client's CA trust chain, an NFS server can
> > >>>> match the client certificate's CN against its list of authorized CNs,
> > >>>> and if the client's CN fails to match, fail the handshake (or whatever
> > >>>> we need to do).
> > >>>>
> > >>>> I favor this approach over using DNS labels, which are often
> > >>>> untrustworthy, and IP addresses, which can be dynamically reassigned.
> > >>>>
> > >>>> What do you think?
> > >>>
> > >>> I completely agree with this.  IP address and DNS identity of the client
> > >>> is irrelevant when mTLS is used.  What matters is whether the client has
> > >>> authority to act as one of the the names given when the filesystem was
> > >>> exported (e.g. in /etc/exports).  His is exacly what you said.
> > >>>
> > >>> Ideally it would be more than just the CN.  We want to know both the
> > >>> domain in which the peer has authority (e.g.  example.com) and the type
> > >>> of authority (e.g.  serve-web-pages or proxy-file-access or
> > >>> act-as-neilb).
> > >>> I don't know internal details of certificates so I don't know if there
> > >>> is some other field that can say "This peer is authorised to proxy file
> > >>> access requests for all users in the given domain" or if we need a hack
> > >>> like exporting to nfs-client.example.com.
> > >>>
> > >>> But if the admin has full control of what names to export to, it is
> > >>> possible that the distinction doesn't matter.  I wouldn't want the
> > >>> certificate used to authenticate my web server to have authority to
> > >>> access all files on my NFS server just because the same domain name
> > >>> applies to both.
> > >>
> > >> My thought is that, for each handshake, there would be two stages:
> > >>
> > >> 1. Does the NFS server trust the certificate? This is purely a chain-of-
> > >>    trust issue, so validating the certificate presented by the client is
> > >>    the order of the day.
> > >>
> > >> 2. Does the NFS server authorize this client to access the export? This
> > >>    is a check very similar to the hostname/netgroup/IP address check
> > >>    that is done today, but it could be done just once at handshake time.
> > >>    Match the certificate's fields against a per-export filter.
> > >>
> > >> I would take tlshd out of the picture for stage 2, and let NFSD make its
> > >> own authorization decisions. Because an NFS client might be authorized
> > >> to access some exports but not others.
> > >>
> > >> So:
> > >>
> > >> How does the server indicate to clients that yes, your cert is trusted,
> > >> but no, you are not authorized to access this file system? I guess that
> > >> is an NFS error like NFSERR_STALE or NFS4ERR_WRONGSEC.
> > >>
> > >> What certificate fields should we implement matches for? CN is obvious.
> > >> But what about SAN? Any others? I say start with only CN, but I'd like
> > >> to think about ways to make it possible to match against other fields in
> > >> the future.
> > >>
> > >> What would the administrative interface look like? Could be the machine
> > >> name in /etc/exports, for instance:
> > >>
> > >> *,OU="NFS Bake-a-thon",*   rw,sec=sys,xprtsec=mtls,fsid=42
> > >>
> > >> But I worry that will not be flexible enough. A more general filter
> > >> mechanism might need something like the ini file format used to create
> > >> CSRs.
> > >
> > > It might be useful to make the kernel's authorization based on mapping to a
> > > keyword that tlshd passes back after the handshake, and keep the more
> > > complicated logic of parsing certificate fields and using config files up in
> > > ktls-utils userspace.
> >
> > I agree that the kernel can't do the filtering.
> >
> > But it's not possible that tlshd knows what export the client wants to
> > access during the TLS handshake; no NFS traffic has been exchanged yet.
> > Thus parsing per-export security settings during the handshake is not
> > possible; it can happen only once tlshd passes the connected socket back
> > to the kernel.
> >
> > And remember that ktls-utils is shared with NVMe and now QUIC as well.
> > tlshd doesn't know anything about the upper layer protocols. Therefore
> > adding NFS-specific authorization policy settings to ktls-utils is a
> > layering violation.
> >
> > What makes the most sense is that the handshake succeeds, then NFSD
> > permits the client to access any export resources that the server's
> > per-export security policy allows, based on the client's cert.
>
> We certainly need a mapping between content of the certificate and an
> "auth_domain" as understood by net/sunrpc, then a mapping from
> auth_domain and filesystem to export options - we already have the
> latter.
>
> There seem to be two option for the first mapping.
> 1/ tlshd can pass the "important" parts of the certificate (and the PSK
>   info) to the sunrpc module much as the IP layer currently passes the IP
>   address and port number to the sunrpc module.  sunrpc then passes this up to
>   mountd which does whatever mapping magic we want and passes down an
>   auth_domain which is then used for further lookup.
>
> 2/ tlshd can do some initial interpretation of the certificate (and PSK)
>   and determine one or more tags which serve to sufficiently classify the
>   certificate for local needs.  It passes them to sunrpc and thence to
>   mountd which gives relevant details to nfsd.
>
> So the core question is: what sort of info do we want to pass from tlshd
> to mountd (via sunrpc) and where is the processing easiest.  Or maybe:
> which part of the processing can usefully be shared with other clients
> of tlshd and which are truly nfsd-specific?
I'm a simple minded guy, so here's a simple minded suggestion...
Define CNs using a DNS like syntax. For example:
alice.faculty.cis.uoguelph.ca
bob.student.cis.uoguelph.ca

When a handshake gets the cert., extract the above CN and push it
into the kernel, associated with the TCP connection.

Then in /etc/exports, specify a CN or a wildcarded suffix. For example:
/exports/faculty/alice
(rw,sec=sys,xprtsec=mtls,cn=alice.faculty.cis.uoguelph.ca)
/exports/faculty/data (rw,sec=sys,xprtsec=mtls,cn=*.faculty.cis.uoguelph.ca)
/exports/students (rw,sec=sys,xprtsec=mtls,cn=*.student.cis.uoguelph.ca)

Then whatever processes /etc/exports pushes the cn strings into the kernel,
associating them with the file systems.

Then, when an RPC request arrives on the TCP connection, tag it with the
CN string (alice.faculty.cis.uoguelph.ca or bob.student.cis.uoguelph.ca)
and when exports need to be checked for a file system, it is just a string
compare (either the whole string or a suffix when wildcarded).

You can use the same string comparison rules as DNS names. Ascii case
independent and Puny encoding for non-ascii chars.

rick


>
> I'd be inclined to keep as much understanding of the various details of
> certificates in tlshd as possible.  It has to deal with some of that
> complexity, and mountd really doesn't.
>
> >
> >
> > > I'm imagining something like this in /etc/exports:
> > >
> > > /exports *(rw,sec=sys,xprtsec=mtls,tlsauth=any)
> > > /exports/home *(rw,sec=sys,xprtsec=mtls,tlsauth=users)
> > >
> > > .. and then tlshd would do the work to create a map of authorized
> > > certificate identities mapped to a keyword, something like:
> > >
> > > CN=*                any
> > > CN=*.nfsv4bat.org   users
> > > SHA1=4EB6D578499B1CCF5F581EAD56BE3D9B6744A5E5   bob
> >
> > I think mountd is going to have to do that, somehow. It already knows
> > about netgroups, for example, and this is very similar.
>
> netgroups is a good example.  mountd knows what a netgroup is but
> doesn't really know about the internal details.  There is a function
> "innetgr()" which it calls to do the required magic.  We similarly want
> a simple way for mountd to know that a given certificate matches a given
> tlsgroup.  A library function would be OK.  strcmp would be good too.
>
> We export to a netgroups as:
>         /path @netgroup(options)
> could we export to a certificate as
>         /path &tlsgroup(options)
> ??
>
> It's always seems weird to me have the "sec=" in the options list.
> The authentication bit comes before the options.  An IP address or
> hostname meand AUTH_SYS. A krb5 indicator means krb5 etc....
> But that isn't the way we went .... unfortunately??
>
> Thanks,
> NeilBrown
>
>
> >
> >
> > > I imagine more flexible or complex rule logic might be desired in the
> > > future, and having that work land in ktls-utils would be nicer than having
> > > to do kernel work or handling various bits of certificate logic or reverse
> > > lookups in-kernel.
> >
> > I agree that the kernel will have to be hands off (or, it will act as a
> > pipe between the user space pieces that actually handle the security
> > policy, if you will).
> >
> >
> > --
> > Chuck Lever
> >
>
>

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

[Chuck Lever]

On 5/13/25 10:28 PM, NeilBrown wrote:
> On Wed, 14 May 2025, NeilBrown wrote:
>> On Tue, 13 May 2025, Jeff Layton 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.
>>
>> But who is going to export any filesystem to their laptop?
>>
>>>
>>> Make the default be "insecure" when creating exports.
>>
>> So you want to break lots of configurations that are working perfectly
>> well?
> 
> Sorry - I was wrong.  You aren't breaking working configurations, but
> you are removing a protection that people might be expecting.  It might
> not be much protection, but it is not zero.

I beg to differ. It really is no protection at all in the modern era,
and it is actively inconvenient for deployments with desktop file
browsers or NAT routers.

As a community we should be encouraging secure deployments out of the
shrink wrap. Making cryptographic security easy should be (and is for
me) job number one. This export option is nothing more than theater.

I agree that a warning would be useful if neither "secure" nor
"insecure" is specified for an export.


>> I don't see any really motivation for this change.  Could you provide it
>> please?
> 
> Or to put it another way: who benefits?
> 
> Thanks,
> NeilBrown
> 
> 
>>
>> Thanks,
>> NeilBrown
>>
>>>
>>> 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.
>>> ---
>>>  support/nfs/exports.c      | 7 +++++--
>>>  utils/exportfs/exports.man | 4 ++--
>>>  2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>>> --- a/support/nfs/exports.c
>>> +++ b/support/nfs/exports.c
>>> @@ -34,8 +34,11 @@
>>>  #include "reexport.h"
>>>  #include "nfsd_path.h"
>>>  
>>> -#define EXPORT_DEFAULT_FLAGS	\
>>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>>> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
>>> +				 NFSEXP_ROOTSQUASH |	\
>>> +				 NFSEXP_GATHERED_WRITES |\
>>> +				 NFSEXP_NOSUBTREECHECK | \
>>> +				 NFSEXP_INSECURE_PORT)
>>>  
>>>  struct flav_info flav_map[] = {
>>>  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
>>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>>> --- a/utils/exportfs/exports.man
>>> +++ b/utils/exportfs/exports.man
>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>  .TP
>>>  .IR secure
>>>  This option requires that requests not using gss originate on an
>>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>>> -To turn it off, specify
>>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>>> +but can be explicitly disabled by specifying
>>>  .IR insecure .
>>>  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>>>  requirement on gss requests as well.)
>>>
>>> ---
>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>> change-id: 20250513-master-89974087bb04
>>>
>>> Best regards,
>>> -- 
>>> Jeff Layton <jlayton@kernel.org>
>>>
>>>
>>>
>>
>>
>>
> 
> 


-- 
Chuck Lever

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

[Thomas Haynes]

> On May 13, 2025, at 10:16 PM, NeilBrown <neil@brown.name> wrote:
> 
> On Tue, 13 May 2025, Jeff Layton 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.
> 
> But who is going to export any filesystem to their laptop?
> 
>> 
>> Make the default be "insecure" when creating exports.
> 
> So you want to break lots of configurations that are working perfectly
> well?
> 
> I don't see any really motivation for this change.  Could you provide it
> please?


Consider a pNFS Flex File deployment with 1000s of data servers. The
metadata server needs access to each data server. If it needs to be on
a secure port, then the metadata server can easily run out of room.




> 
> Thanks,
> NeilBrown
> 
>> 
>> 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.
>> ---
>> support/nfs/exports.c      | 7 +++++--
>> utils/exportfs/exports.man | 4 ++--
>> 2 files changed, 7 insertions(+), 4 deletions(-)
>> 
>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>> --- a/support/nfs/exports.c
>> +++ b/support/nfs/exports.c
>> @@ -34,8 +34,11 @@
>> #include "reexport.h"
>> #include "nfsd_path.h"
>> 
>> -#define EXPORT_DEFAULT_FLAGS \
>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>> +#define EXPORT_DEFAULT_FLAGS (NFSEXP_READONLY | \
>> + NFSEXP_ROOTSQUASH | \
>> + NFSEXP_GATHERED_WRITES |\
>> + NFSEXP_NOSUBTREECHECK | \
>> + NFSEXP_INSECURE_PORT)
>> 
>> struct flav_info flav_map[] = {
>> { "krb5", RPC_AUTH_GSS_KRB5, 1},
>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>> --- a/utils/exportfs/exports.man
>> +++ b/utils/exportfs/exports.man
>> @@ -180,8 +180,8 @@ understands the following export options:
>> .TP
>> .IR secure
>> This option requires that requests not using gss originate on an
>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>> -To turn it off, specify
>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>> +but can be explicitly disabled by specifying
>> .IR insecure .
>> (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>> requirement on gss requests as well.)
>> 
>> ---
>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>> change-id: 20250513-master-89974087bb04
>> 
>> Best regards,
>> -- 
>> Jeff Layton <jlayton@kernel.org>
>> 
>> 
>> 
> 

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

[NeilBrown]

On Wed, 14 May 2025, Thomas Haynes wrote:
> 
> > On May 13, 2025, at 10:16 PM, NeilBrown <neil@brown.name> wrote:
> > 
> > On Tue, 13 May 2025, Jeff Layton 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.
> > 
> > But who is going to export any filesystem to their laptop?
> > 
> >> 
> >> Make the default be "insecure" when creating exports.
> > 
> > So you want to break lots of configurations that are working perfectly
> > well?
> > 
> > I don't see any really motivation for this change.  Could you provide it
> > please?
> 
> 
> Consider a pNFS Flex File deployment with 1000s of data servers. The
> metadata server needs access to each data server. If it needs to be on
> a secure port, then the metadata server can easily run out of room.
> 

What is the cost of specifying "insecure" on each export line?

If this really is a burden, I suggest adding a "default-export-options"
or similar to /etc/nfs.conf.  Then you can put 
    default-export-options = secure
in your /etc/nfs.conf and be happy.

Thanks,
NeilBrown

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

[NeilBrown]

On Tue, 13 May 2025, Jeff Layton 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.
> ---
>  support/nfs/exports.c      | 7 +++++--
>  utils/exportfs/exports.man | 4 ++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> --- a/support/nfs/exports.c
> +++ b/support/nfs/exports.c
> @@ -34,8 +34,11 @@
>  #include "reexport.h"
>  #include "nfsd_path.h"
>  
> -#define EXPORT_DEFAULT_FLAGS	\
> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> +				 NFSEXP_ROOTSQUASH |	\
> +				 NFSEXP_GATHERED_WRITES |\
> +				 NFSEXP_NOSUBTREECHECK | \
> +				 NFSEXP_INSECURE_PORT)
>  
>  struct flav_info flav_map[] = {
>  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> --- a/utils/exportfs/exports.man
> +++ b/utils/exportfs/exports.man
> @@ -180,8 +180,8 @@ understands the following export options:
>  .TP
>  .IR secure
>  This option requires that requests not using gss originate on an
> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> -To turn it off, specify
> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> +but can be explicitly disabled by specifying
>  .IR insecure .

I think you mean "can be explicit enabled if desired" or similar.

If you really want to do this, you should require either "insecure" or
"secure" and generate a warning like we did when changing other defaults
in the past.  After a period of time you can remove that requirement.

NeilBrown


>  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>  requirement on gss requests as well.)
> 
> ---
> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> change-id: 20250513-master-89974087bb04
> 
> Best regards,
> -- 
> Jeff Layton <jlayton@kernel.org>
> 
> 
> 

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

[Jeff Layton]

On Wed, 2025-05-14 at 12:38 +1000, NeilBrown wrote:
> On Tue, 13 May 2025, Jeff Layton 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.
> > ---
> >  support/nfs/exports.c      | 7 +++++--
> >  utils/exportfs/exports.man | 4 ++--
> >  2 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > --- a/support/nfs/exports.c
> > +++ b/support/nfs/exports.c
> > @@ -34,8 +34,11 @@
> >  #include "reexport.h"
> >  #include "nfsd_path.h"
> >  
> > -#define EXPORT_DEFAULT_FLAGS	\
> > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > +				 NFSEXP_ROOTSQUASH |	\
> > +				 NFSEXP_GATHERED_WRITES |\
> > +				 NFSEXP_NOSUBTREECHECK | \
> > +				 NFSEXP_INSECURE_PORT)
> >  
> >  struct flav_info flav_map[] = {
> >  	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > --- a/utils/exportfs/exports.man
> > +++ b/utils/exportfs/exports.man
> > @@ -180,8 +180,8 @@ understands the following export options:
> >  .TP
> >  .IR secure
> >  This option requires that requests not using gss originate on an
> > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > -To turn it off, specify
> > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > +but can be explicitly disabled by specifying
> >  .IR insecure .
> 
> I think you mean "can be explicit enabled if desired" or similar.
> 

Yeah, it is a little awkward. I want to keep "insecure" in the manpage
so that people know what the option is (and don't try to use something
like "nosecure"). I'll see if I can rephrase that.

> If you really want to do this, you should require either "insecure" or
> "secure" and generate a warning like we did when changing other defaults
> in the past.  After a period of time you can remove that requirement.
> 
> NeilBrown
> 

Requiring the option _would_ break existing setups, so I'd be against
that plan.

One thing we could do is have exportfs log a warning to syslog when
neither option is specified. Admins could specify it either way to
silence the message. Would that overcome your objection?

> 
> >  (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> >  requirement on gss requests as well.)
> > 
> > ---
> > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > change-id: 20250513-master-89974087bb04
> > 
> > Best regards,
> > -- 
> > Jeff Layton <jlayton@kernel.org>
> > 
> > 
> > 
> 

-- 
Jeff Layton <jlayton@kernel.org>

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

[Christopher Bii]

Just want to weigh in on this briefly,

Firstly:

Yes, people have arbitrary access to low ports on their systems, but
such privileges are voided behind a NAT. Meaning a, possibly accidental,
publicly facing server may indeed benefit from such a check.

Secondly:

Even if NAT's didn't exist and you needed no system capabilities to bind
to any port. It is entirely legitimate for server/client applications,
let alone ones living in the kernel, to restrict client access based on
any criterion that may (de)legitimize them. Look at smtp. Yes there are
workarounds to everything, but goal isn't to stop bad actors in whole,
or even in large part. If such a thing can deter a small portion of
malicious traffic, it worked.

Thirdly:

Kinda goes with the above. Evaluating the efficiency of individual
components of a larger system can often lead to false conclusions.

Unless this has actively caused any issues for people where they would
rather it be opt-in, I think this should remain unchanged. If anything,
I'd say the argument to take it out completely is much more compelling.

It's a simple toggle option, those likely to need the change can easily
do so. If we assume zero user knowledge, they are likely incapable of
stepping outside the default ports used by client/server. Meaning, best
case scenario, the connection from port 60000 may be the vacuum cleaner.

Regards,
Christopher Bii

Jeff Layton wrote:
> On Wed, 2025-05-14 at 12:38 +1000, NeilBrown wrote:
>> On Tue, 13 May 2025, Jeff Layton 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.
>>> ---
>>>   support/nfs/exports.c      | 7 +++++--
>>>   utils/exportfs/exports.man | 4 ++--
>>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>>> --- a/support/nfs/exports.c
>>> +++ b/support/nfs/exports.c
>>> @@ -34,8 +34,11 @@
>>>   #include "reexport.h"
>>>   #include "nfsd_path.h"
>>>   
>>> -#define EXPORT_DEFAULT_FLAGS	\
>>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>>> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
>>> +				 NFSEXP_ROOTSQUASH |	\
>>> +				 NFSEXP_GATHERED_WRITES |\
>>> +				 NFSEXP_NOSUBTREECHECK | \
>>> +				 NFSEXP_INSECURE_PORT)
>>>   
>>>   struct flav_info flav_map[] = {
>>>   	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
>>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>>> --- a/utils/exportfs/exports.man
>>> +++ b/utils/exportfs/exports.man
>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>   .TP
>>>   .IR secure
>>>   This option requires that requests not using gss originate on an
>>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>>> -To turn it off, specify
>>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>>> +but can be explicitly disabled by specifying
>>>   .IR insecure .
>>
>> I think you mean "can be explicit enabled if desired" or similar.
>>
> 
> Yeah, it is a little awkward. I want to keep "insecure" in the manpage
> so that people know what the option is (and don't try to use something
> like "nosecure"). I'll see if I can rephrase that.
> 
>> If you really want to do this, you should require either "insecure" or
>> "secure" and generate a warning like we did when changing other defaults
>> in the past.  After a period of time you can remove that requirement.
>>
>> NeilBrown
>>
> 
> Requiring the option _would_ break existing setups, so I'd be against
> that plan.
> 
> One thing we could do is have exportfs log a warning to syslog when
> neither option is specified. Admins could specify it either way to
> silence the message. Would that overcome your objection?
> 
>>
>>>   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>>>   requirement on gss requests as well.)
>>>
>>> ---
>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>> change-id: 20250513-master-89974087bb04
>>>
>>> Best regards,
>>> -- 
>>> Jeff Layton <jlayton@kernel.org>
>>>
>>>
>>>
>>
> 

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

[Sebastian Feld]

On Tue, May 13, 2025 at 3:50 PM 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.

I made a poll webpage for our sysadmins about what they think about this change.

Out of 26 people allowed to vote 24 voted "BAD idea, keep the secure
option the default", and two didn't vote.

So this is a change which is virtually 100% hated by the people
primarily affected by such a change.

Sebi
-- 
Sebastian Feld - IT security consultant

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

[Jeff Layton]

On Wed, 2025-05-21 at 11:06 +0200, Sebastian Feld wrote:
> On Tue, May 13, 2025 at 3:50 PM 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.
> 
> I made a poll webpage for our sysadmins about what they think about this change.
> 
> Out of 26 people allowed to vote 24 voted "BAD idea, keep the secure
> option the default", and two didn't vote.
> 
> So this is a change which is virtually 100% hated by the people
> primarily affected by such a change.
> 
> 

Polling is all about the question being asked. What was the question?
Did it explain that despite the name, the "secure" option offers
virtually nothing in the way of security?

I'd like at ask these same admins why they care about the source port,
because I find it really hard to believe that there are environments
out there in 2025 where one simply doesn't have to worry about a random
user contacting the server from an unmanaged laptop, or worry about
someone rebooting an existing host on the network with a USB stick.

Once someone does that, any protection that "secure" gives you is
defeated. To wit, if the server is _at_all_ reachable over wifi then
this option is likely already worthless.

Are there really that many administrators that are running NFS in
hermetically-sealed environments? Or are are they just fooling
themselves?

I think it more likely that most of the people who object to this
didn't read beyond the subject line. If this export option were named
_anything_ else (e.g. "privilegedport" or something), we wouldn't be
having this discussion.
-- 
Jeff Layton <jlayton@kernel.org>

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

[Chuck Lever]

On 5/21/25 5:06 AM, Sebastian Feld wrote:
> On Tue, May 13, 2025 at 3:50 PM 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.
> 
> I made a poll webpage for our sysadmins about what they think about this change.

Who are "our sysadmins" and what did you do to compensate for various
cognitive biases?


> Out of 26 people allowed to vote 24 voted "BAD idea, keep the secure
> option the default", and two didn't vote.
> 
> So this is a change which is virtually 100% hated by the people
> primarily affected by such a change.

I'm interested in understanding why changing the default behavior is a
problem. Is explicitly adding the "secure" export option on the exports
where it matters a heavy lift? If so, why?


-- 
Chuck Lever

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

[Chuck Lever]

On 5/21/25 9:14 AM, Chuck Lever wrote:
> On 5/21/25 5:06 AM, Sebastian Feld wrote:
>> On Tue, May 13, 2025 at 3:50 PM 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.
>>
>> I made a poll webpage for our sysadmins about what they think about this change.
> 
> Who are "our sysadmins" and what did you do to compensate for various
> cognitive biases?
> 
> 
>> Out of 26 people allowed to vote 24 voted "BAD idea, keep the secure
>> option the default", and two didn't vote.
>>
>> So this is a change which is virtually 100% hated by the people
>> primarily affected by such a change.
> 
> I'm interested in understanding why changing the default behavior is a
> problem. Is explicitly adding the "secure" export option on the exports
> where it matters a heavy lift? If so, why?

To be clear: asking around is a sensible thing to do. However I'd like
to see more nuanced feedback than "BAD idea".


-- 
Chuck Lever

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

[Cedric Blancher]

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.

I'd request that you also rename the darn thing to "resvport" and
"noresvport", and keep "insecure"+"secure" as a depreciated alias
around.

if you do that you'll get a Reviewed-by: Cedric Blancher
<cedric.blancher@gmail.com>

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Steve Dickson]

Hello all,

On 5/13/25 9:50 AM, Jeff Layton 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.
> ---
>   support/nfs/exports.c      | 7 +++++--
>   utils/exportfs/exports.man | 4 ++--
>   2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> --- a/support/nfs/exports.c
> +++ b/support/nfs/exports.c
> @@ -34,8 +34,11 @@
>   #include "reexport.h"
>   #include "nfsd_path.h"
>   
> -#define EXPORT_DEFAULT_FLAGS	\
> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> +				 NFSEXP_ROOTSQUASH |	\
> +				 NFSEXP_GATHERED_WRITES |\
> +				 NFSEXP_NOSUBTREECHECK | \
> +				 NFSEXP_INSECURE_PORT)
>   
>   struct flav_info flav_map[] = {
>   	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> --- a/utils/exportfs/exports.man
> +++ b/utils/exportfs/exports.man
> @@ -180,8 +180,8 @@ understands the following export options:
>   .TP
>   .IR secure
>   This option requires that requests not using gss originate on an
> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> -To turn it off, specify
> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> +but can be explicitly disabled by specifying
>   .IR insecure .
>   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>   requirement on gss requests as well.)
> 
> ---
> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> change-id: 20250513-master-89974087bb04
> 
> Best regards,
My apologies but I got a bit lost in the fairly large thread
What as is consensus on this patch? Thumbs up or down.
Will there be a V2?

I'm wondering what type documentation impact this would
have on all docs out there that say one has to be root
to do the mount.

I guess I'm not against the patch but as Neil pointed
out making things insecure is a different direction
that the rest of the world is going.

my two cents,

steved.

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

[Cedric Blancher]

On Wed, 4 Jun 2025 at 20:26, Steve Dickson <steved@redhat.com> wrote:
>
> Hello all,
>
> On 5/13/25 9:50 AM, Jeff Layton 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.
> > ---
> >   support/nfs/exports.c      | 7 +++++--
> >   utils/exportfs/exports.man | 4 ++--
> >   2 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > --- a/support/nfs/exports.c
> > +++ b/support/nfs/exports.c
> > @@ -34,8 +34,11 @@
> >   #include "reexport.h"
> >   #include "nfsd_path.h"
> >
> > -#define EXPORT_DEFAULT_FLAGS \
> > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > +#define EXPORT_DEFAULT_FLAGS (NFSEXP_READONLY |      \
> > +                              NFSEXP_ROOTSQUASH |    \
> > +                              NFSEXP_GATHERED_WRITES |\
> > +                              NFSEXP_NOSUBTREECHECK | \
> > +                              NFSEXP_INSECURE_PORT)
> >
> >   struct flav_info flav_map[] = {
> >       { "krb5",       RPC_AUTH_GSS_KRB5,      1},
> > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > --- a/utils/exportfs/exports.man
> > +++ b/utils/exportfs/exports.man
> > @@ -180,8 +180,8 @@ understands the following export options:
> >   .TP
> >   .IR secure
> >   This option requires that requests not using gss originate on an
> > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > -To turn it off, specify
> > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > +but can be explicitly disabled by specifying
> >   .IR insecure .
> >   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> >   requirement on gss requests as well.)
> >
> > ---
> > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > change-id: 20250513-master-89974087bb04
> >
> > Best regards,
> My apologies but I got a bit lost in the fairly large thread
> What as is consensus on this patch? Thumbs up or down.

Thumbs up for a V2, which renames the darn option "resvport" and
"noresvport" (like Solaris, Windows, ...), and keeping
"insecure"+"secure" as a depreciated alias around.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Jeff Layton]

On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
> Hello all,
> 
> On 5/13/25 9:50 AM, Jeff Layton 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.
> > ---
> >   support/nfs/exports.c      | 7 +++++--
> >   utils/exportfs/exports.man | 4 ++--
> >   2 files changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > --- a/support/nfs/exports.c
> > +++ b/support/nfs/exports.c
> > @@ -34,8 +34,11 @@
> >   #include "reexport.h"
> >   #include "nfsd_path.h"
> >   
> > -#define EXPORT_DEFAULT_FLAGS	\
> > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > +				 NFSEXP_ROOTSQUASH |	\
> > +				 NFSEXP_GATHERED_WRITES |\
> > +				 NFSEXP_NOSUBTREECHECK | \
> > +				 NFSEXP_INSECURE_PORT)
> >   
> >   struct flav_info flav_map[] = {
> >   	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > --- a/utils/exportfs/exports.man
> > +++ b/utils/exportfs/exports.man
> > @@ -180,8 +180,8 @@ understands the following export options:
> >   .TP
> >   .IR secure
> >   This option requires that requests not using gss originate on an
> > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > -To turn it off, specify
> > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > +but can be explicitly disabled by specifying
> >   .IR insecure .
> >   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> >   requirement on gss requests as well.)
> > 
> > ---
> > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > change-id: 20250513-master-89974087bb04
> > 
> > Best regards,
> My apologies but I got a bit lost in the fairly large thread
> What as is consensus on this patch? Thumbs up or down.
> Will there be a V2?
> 
> I'm wondering what type documentation impact this would
> have on all docs out there that say one has to be root
> to do the mount.
> 
> I guess I'm not against the patch but as Neil pointed
> out making things insecure is a different direction
> that the rest of the world is going.
> 
> my two cents,
> 
> 

Thumbs down for now. Neil argued for a more measured approach to
changing this.

I started work on a manpage patch for exports(5) but it's not quite
ready yet. I also want to look at converting some manpages to asciidoc
as we go, to make future updates easier.
-- 
Jeff Layton <jlayton@kernel.org>

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

[Steve Dickson]

On 6/4/25 3:17 PM, Jeff Layton wrote:
> On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
>> Hello all,
>>
>> On 5/13/25 9:50 AM, Jeff Layton 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.
>>> ---
>>>    support/nfs/exports.c      | 7 +++++--
>>>    utils/exportfs/exports.man | 4 ++--
>>>    2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>>> --- a/support/nfs/exports.c
>>> +++ b/support/nfs/exports.c
>>> @@ -34,8 +34,11 @@
>>>    #include "reexport.h"
>>>    #include "nfsd_path.h"
>>>    
>>> -#define EXPORT_DEFAULT_FLAGS	\
>>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>>> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
>>> +				 NFSEXP_ROOTSQUASH |	\
>>> +				 NFSEXP_GATHERED_WRITES |\
>>> +				 NFSEXP_NOSUBTREECHECK | \
>>> +				 NFSEXP_INSECURE_PORT)
>>>    
>>>    struct flav_info flav_map[] = {
>>>    	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
>>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>>> --- a/utils/exportfs/exports.man
>>> +++ b/utils/exportfs/exports.man
>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>    .TP
>>>    .IR secure
>>>    This option requires that requests not using gss originate on an
>>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>>> -To turn it off, specify
>>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>>> +but can be explicitly disabled by specifying
>>>    .IR insecure .
>>>    (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>>>    requirement on gss requests as well.)
>>>
>>> ---
>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>> change-id: 20250513-master-89974087bb04
>>>
>>> Best regards,
>> My apologies but I got a bit lost in the fairly large thread
>> What as is consensus on this patch? Thumbs up or down.
>> Will there be a V2?
>>
>> I'm wondering what type documentation impact this would
>> have on all docs out there that say one has to be root
>> to do the mount.
>>
>> I guess I'm not against the patch but as Neil pointed
>> out making things insecure is a different direction
>> that the rest of the world is going.
>>
>> my two cents,
>>
>>
> 
> Thumbs down for now. Neil argued for a more measured approach to
> changing this.
> 
> I started work on a manpage patch for exports(5) but it's not quite
> ready yet. I also want to look at converting some manpages to asciidoc
> as we go, to make future updates easier.
Sounds like a plan... Thanks!

steved.

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

[Trond Myklebust]

On Wed, 2025-06-04 at 15:53 -0400, Steve Dickson wrote:
> 
> 
> On 6/4/25 3:17 PM, Jeff Layton wrote:
> > On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
> > > Hello all,
> > > 
> > > On 5/13/25 9:50 AM, Jeff Layton 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.
> > > > ---
> > > >    support/nfs/exports.c      | 7 +++++--
> > > >    utils/exportfs/exports.man | 4 ++--
> > > >    2 files changed, 7 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > > > index
> > > > 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef
> > > > 287ca0685af3e70ed0b 100644
> > > > --- a/support/nfs/exports.c
> > > > +++ b/support/nfs/exports.c
> > > > @@ -34,8 +34,11 @@
> > > >    #include "reexport.h"
> > > >    #include "nfsd_path.h"
> > > >    
> > > > -#define EXPORT_DEFAULT_FLAGS	\
> > > > - 
> > > > (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEX
> > > > P_NOSUBTREECHECK)
> > > > +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
> > > > +				 NFSEXP_ROOTSQUASH |	\
> > > > +				 NFSEXP_GATHERED_WRITES |\
> > > > +				 NFSEXP_NOSUBTREECHECK | \
> > > > +				 NFSEXP_INSECURE_PORT)
> > > >    
> > > >    struct flav_info flav_map[] = {
> > > >    	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
> > > > diff --git a/utils/exportfs/exports.man
> > > > b/utils/exportfs/exports.man
> > > > index
> > > > 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7e
> > > > b84301c4ec97b14d003 100644
> > > > --- a/utils/exportfs/exports.man
> > > > +++ b/utils/exportfs/exports.man
> > > > @@ -180,8 +180,8 @@ understands the following export options:
> > > >    .TP
> > > >    .IR secure
> > > >    This option requires that requests not using gss originate
> > > > on an
> > > > -Internet port less than IPPORT_RESERVED (1024). This option is
> > > > on by default.
> > > > -To turn it off, specify
> > > > +Internet port less than IPPORT_RESERVED (1024). This option is
> > > > off by default
> > > > +but can be explicitly disabled by specifying
> > > >    .IR insecure .
> > > >    (NOTE: older kernels (before upstream kernel version 4.17)
> > > > enforced this
> > > >    requirement on gss requests as well.)
> > > > 
> > > > ---
> > > > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > > > change-id: 20250513-master-89974087bb04
> > > > 
> > > > Best regards,
> > > My apologies but I got a bit lost in the fairly large thread
> > > What as is consensus on this patch? Thumbs up or down.
> > > Will there be a V2?
> > > 
> > > I'm wondering what type documentation impact this would
> > > have on all docs out there that say one has to be root
> > > to do the mount.
> > > 
> > > I guess I'm not against the patch but as Neil pointed
> > > out making things insecure is a different direction
> > > that the rest of the world is going.
> > > 
> > > my two cents,
> > > 
> > > 
> > 
> > Thumbs down for now. Neil argued for a more measured approach to
> > changing this.
> > 
> > I started work on a manpage patch for exports(5) but it's not quite
> > ready yet. I also want to look at converting some manpages to
> > asciidoc
> > as we go, to make future updates easier.
> Sounds like a plan... Thanks!
> 
> steved.
> 
> 

Can we please add an explanation to the manpage to let people know why
this default is set?

It is basically in order to prevent any untrusted Tom, Dick or Harry
from spinning up a userspace NFS client that spoofs a different user.

IOW: The assumption is that you should at least be able to trust the
kernel NFS client to at provide the correct credential for an untrusted
user.
If you can't make that assumption, then your server should probably be
configured to squash any AUTH_SYS credential supplied by this client.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

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

[Chuck Lever]

On 6/5/25 12:48 PM, Trond Myklebust wrote:
> On Wed, 2025-06-04 at 15:53 -0400, Steve Dickson wrote:
>>
>>
>> On 6/4/25 3:17 PM, Jeff Layton wrote:
>>> On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
>>>> Hello all,
>>>>
>>>> On 5/13/25 9:50 AM, Jeff Layton 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.
>>>>> ---
>>>>>    support/nfs/exports.c      | 7 +++++--
>>>>>    utils/exportfs/exports.man | 4 ++--
>>>>>    2 files changed, 7 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>>>> index
>>>>> 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef
>>>>> 287ca0685af3e70ed0b 100644
>>>>> --- a/support/nfs/exports.c
>>>>> +++ b/support/nfs/exports.c
>>>>> @@ -34,8 +34,11 @@
>>>>>    #include "reexport.h"
>>>>>    #include "nfsd_path.h"
>>>>>    
>>>>> -#define EXPORT_DEFAULT_FLAGS	\
>>>>> - 
>>>>> (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEX
>>>>> P_NOSUBTREECHECK)
>>>>> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
>>>>> +				 NFSEXP_ROOTSQUASH |	\
>>>>> +				 NFSEXP_GATHERED_WRITES |\
>>>>> +				 NFSEXP_NOSUBTREECHECK | \
>>>>> +				 NFSEXP_INSECURE_PORT)
>>>>>    
>>>>>    struct flav_info flav_map[] = {
>>>>>    	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
>>>>> diff --git a/utils/exportfs/exports.man
>>>>> b/utils/exportfs/exports.man
>>>>> index
>>>>> 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7e
>>>>> b84301c4ec97b14d003 100644
>>>>> --- a/utils/exportfs/exports.man
>>>>> +++ b/utils/exportfs/exports.man
>>>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>>>    .TP
>>>>>    .IR secure
>>>>>    This option requires that requests not using gss originate
>>>>> on an
>>>>> -Internet port less than IPPORT_RESERVED (1024). This option is
>>>>> on by default.
>>>>> -To turn it off, specify
>>>>> +Internet port less than IPPORT_RESERVED (1024). This option is
>>>>> off by default
>>>>> +but can be explicitly disabled by specifying
>>>>>    .IR insecure .
>>>>>    (NOTE: older kernels (before upstream kernel version 4.17)
>>>>> enforced this
>>>>>    requirement on gss requests as well.)
>>>>>
>>>>> ---
>>>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>>>> change-id: 20250513-master-89974087bb04
>>>>>
>>>>> Best regards,
>>>> My apologies but I got a bit lost in the fairly large thread
>>>> What as is consensus on this patch? Thumbs up or down.
>>>> Will there be a V2?
>>>>
>>>> I'm wondering what type documentation impact this would
>>>> have on all docs out there that say one has to be root
>>>> to do the mount.
>>>>
>>>> I guess I'm not against the patch but as Neil pointed
>>>> out making things insecure is a different direction
>>>> that the rest of the world is going.
>>>>
>>>> my two cents,
>>>>
>>>>
>>>
>>> Thumbs down for now. Neil argued for a more measured approach to
>>> changing this.
>>>
>>> I started work on a manpage patch for exports(5) but it's not quite
>>> ready yet. I also want to look at converting some manpages to
>>> asciidoc
>>> as we go, to make future updates easier.
>> Sounds like a plan... Thanks!
>>
>> steved.
>>
>>
> 
> Can we please add an explanation to the manpage to let people know why
> this default is set?

That's exactly what Jeff is working on right now.


> It is basically in order to prevent any untrusted Tom, Dick or Harry
> from spinning up a userspace NFS client that spoofs a different user.
> 
> IOW: The assumption is that you should at least be able to trust the
> kernel NFS client to at provide the correct credential for an untrusted
> user.
> If you can't make that assumption, then your server should probably be
> configured to squash any AUTH_SYS credential supplied by this client.


-- 
Chuck Lever

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

[Cedric Blancher]

On Wed, 4 Jun 2025 at 21:17, Jeff Layton <jlayton@kernel.org> wrote:
>
> On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
> > Hello all,
> >
> > On 5/13/25 9:50 AM, Jeff Layton 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.
> > > ---
> > >   support/nfs/exports.c      | 7 +++++--
> > >   utils/exportfs/exports.man | 4 ++--
> > >   2 files changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/support/nfs/exports.c b/support/nfs/exports.c
> > > index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
> > > --- a/support/nfs/exports.c
> > > +++ b/support/nfs/exports.c
> > > @@ -34,8 +34,11 @@
> > >   #include "reexport.h"
> > >   #include "nfsd_path.h"
> > >
> > > -#define EXPORT_DEFAULT_FLAGS       \
> > > -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
> > > +#define EXPORT_DEFAULT_FLAGS       (NFSEXP_READONLY |      \
> > > +                            NFSEXP_ROOTSQUASH |    \
> > > +                            NFSEXP_GATHERED_WRITES |\
> > > +                            NFSEXP_NOSUBTREECHECK | \
> > > +                            NFSEXP_INSECURE_PORT)
> > >
> > >   struct flav_info flav_map[] = {
> > >     { "krb5",       RPC_AUTH_GSS_KRB5,      1},
> > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
> > > index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
> > > --- a/utils/exportfs/exports.man
> > > +++ b/utils/exportfs/exports.man
> > > @@ -180,8 +180,8 @@ understands the following export options:
> > >   .TP
> > >   .IR secure
> > >   This option requires that requests not using gss originate on an
> > > -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
> > > -To turn it off, specify
> > > +Internet port less than IPPORT_RESERVED (1024). This option is off by default
> > > +but can be explicitly disabled by specifying
> > >   .IR insecure .
> > >   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
> > >   requirement on gss requests as well.)
> > >
> > > ---
> > > base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
> > > change-id: 20250513-master-89974087bb04
> > >
> > > Best regards,
> > My apologies but I got a bit lost in the fairly large thread
> > What as is consensus on this patch? Thumbs up or down.
> > Will there be a V2?
> >
> > I'm wondering what type documentation impact this would
> > have on all docs out there that say one has to be root
> > to do the mount.
> >
> > I guess I'm not against the patch but as Neil pointed
> > out making things insecure is a different direction
> > that the rest of the world is going.
> >
> > my two cents,
> >
> >
>
> Thumbs down for now. Neil argued for a more measured approach to
> changing this.

What about renaming the option to "resvport" / "noresvport"?

>
> I started work on a manpage patch for exports(5) but it's not quite
> ready yet. I also want to look at converting some manpages to asciidoc
> as we go, to make future updates easier.

Why asciidoc? I think every localisation staff in companies will NOT
be happy with that.
I'd suggest Docbook/XML, as it is more flexible and allows HTML
generation without going to the groff/asciidoc eye of the needle.

Ced
-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

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

[Chuck Lever]

On 6/5/25 4:20 AM, Cedric Blancher wrote:
> On Wed, 4 Jun 2025 at 21:17, Jeff Layton <jlayton@kernel.org> wrote:
>>
>> On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
>>> Hello all,
>>>
>>> On 5/13/25 9:50 AM, Jeff Layton 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.
>>>> ---
>>>>   support/nfs/exports.c      | 7 +++++--
>>>>   utils/exportfs/exports.man | 4 ++--
>>>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>>>> --- a/support/nfs/exports.c
>>>> +++ b/support/nfs/exports.c
>>>> @@ -34,8 +34,11 @@
>>>>   #include "reexport.h"
>>>>   #include "nfsd_path.h"
>>>>
>>>> -#define EXPORT_DEFAULT_FLAGS       \
>>>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>>>> +#define EXPORT_DEFAULT_FLAGS       (NFSEXP_READONLY |      \
>>>> +                            NFSEXP_ROOTSQUASH |    \
>>>> +                            NFSEXP_GATHERED_WRITES |\
>>>> +                            NFSEXP_NOSUBTREECHECK | \
>>>> +                            NFSEXP_INSECURE_PORT)
>>>>
>>>>   struct flav_info flav_map[] = {
>>>>     { "krb5",       RPC_AUTH_GSS_KRB5,      1},
>>>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>>>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>>>> --- a/utils/exportfs/exports.man
>>>> +++ b/utils/exportfs/exports.man
>>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>>   .TP
>>>>   .IR secure
>>>>   This option requires that requests not using gss originate on an
>>>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>>>> -To turn it off, specify
>>>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>>>> +but can be explicitly disabled by specifying
>>>>   .IR insecure .
>>>>   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>>>>   requirement on gss requests as well.)
>>>>
>>>> ---
>>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>>> change-id: 20250513-master-89974087bb04
>>>>
>>>> Best regards,
>>> My apologies but I got a bit lost in the fairly large thread
>>> What as is consensus on this patch? Thumbs up or down.
>>> Will there be a V2?
>>>
>>> I'm wondering what type documentation impact this would
>>> have on all docs out there that say one has to be root
>>> to do the mount.
>>>
>>> I guess I'm not against the patch but as Neil pointed
>>> out making things insecure is a different direction
>>> that the rest of the world is going.
>>>
>>> my two cents,
>>>
>>>
>>
>> Thumbs down for now. Neil argued for a more measured approach to
>> changing this.
> 
> What about renaming the option to "resvport" / "noresvport"?

I've also wondered about renaming the export option. "secure" is
terribly misleading and quite unspecific.

And agreed, after adding the new name, "secure" would need to remain as
a (perhaps hidden) synonym for a while.


-- 
Chuck Lever