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@xxxxxxxxxx>
> > > > > ---
> > > > > 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@xxxxxxxxxx>
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> > --
> > Jeff Layton <jlayton@xxxxxxxxxx>
> >
--
Jeff Layton <jlayton@xxxxxxxxxx>
