Message-ID: <CAM5tNy79vTM7v_-Cq9mCvudqL7JfrZ-Bc7dLvpNWQ-MkkxmPOA@mail.gmail.com>
Date: Mon, 7 Oct 2024 18:17:59 -0700
From: Rick Macklem <rick.macklem@...il.com>
To: Chuck Lever III <chuck.lever@...cle.com>
Cc: Neil Brown <neilb@...e.de>, Pali Rohár <pali@...nel.org>, 
	Jeff Layton <jlayton@...nel.org>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <dai.ngo@...cle.com>, 
	Tom Talpey <tom@...pey.com>, Linux NFS Mailing List <linux-nfs@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nfsd: Fix NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT

On Mon, Oct 7, 2024 at 8:51 AM Chuck Lever III <chuck.lever@...cle.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@...uelph.ca.
>
>
>
>
> > On Oct 6, 2024, at 7:36 PM, NeilBrown <neilb@...e.de> wrote:
> >
> > On Mon, 07 Oct 2024, Chuck Lever III wrote:
> >>
> >>
> >>> On Oct 6, 2024, at 6:29 PM, Pali Rohár <pali@...nel.org> wrote:
> >>>
> >>> On Monday 07 October 2024 09:13:17 NeilBrown wrote:
> >>>> On Mon, 07 Oct 2024, Chuck Lever wrote:
> >>>>> On Fri, Sep 13, 2024 at 08:52:20AM +1000, NeilBrown wrote:
> >>>>>> On Fri, 13 Sep 2024, Pali Rohár wrote:
> >>>>>>> Currently NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT do not bypass
> >>>>>>> only GSS, but bypass any authentication method. This is problem specially
> >>>>>>> for NFS3 AUTH_NULL-only exports.
> >>>>>>>
> >>>>>>> The purpose of NFSD_MAY_BYPASS_GSS_ON_ROOT is described in RFC 2623,
> >>>>>>> section 2.3.2, to allow mounting NFS2/3 GSS-only export without
> >>>>>>> authentication. So few procedures which do not expose security risk used
> >>>>>>> during mount time can be called also with AUTH_NONE or AUTH_SYS, to allow
> >>>>>>> client mount operation to finish successfully.
> >>>>>>>
> >>>>>>> The problem with current implementation is that for AUTH_NULL-only exports,
> >>>>>>> the NFSD_MAY_BYPASS_GSS_ON_ROOT is active also for NFS3 AUTH_UNIX mount
> >>>>>>> attempts which confuse NFS3 clients, and make them think that AUTH_UNIX is
> >>>>>>> enabled and is working. Linux NFS3 client never switches from AUTH_UNIX to
> >>>>>>> AUTH_NONE on active mount, which makes the mount inaccessible.
> >>>>>>>
> >>>>>>> Fix the NFSD_MAY_BYPASS_GSS and NFSD_MAY_BYPASS_GSS_ON_ROOT implementation
> >>>>>>> and really allow to bypass only exports which have some GSS auth flavor
> >>>>>>> enabled.
> >>>>>>>
> >>>>>>> The result would be: For AUTH_NULL-only export if client attempts to do
> >>>>>>> mount with AUTH_UNIX flavor then it will receive access errors, which
> >>>>>>> instruct client that AUTH_UNIX flavor is not usable and will either try
> >>>>>>> other auth flavor (AUTH_NULL if enabled) or fails mount procedure.
> >>>>>>>
> >>>>>>> This should fix problems with AUTH_NULL-only or AUTH_UNIX-only exports if
> >>>>>>> client attempts to mount it with other auth flavor (e.g. with AUTH_NULL for
> >>>>>>> AUTH_UNIX-only export, or with AUTH_UNIX for AUTH_NULL-only export).
> >>>>>>
> >>>>>> The MAY_BYPASS_GSS flag currently also bypasses TLS restrictions.  With
> >>>>>> your change it doesn't.  I don't think we want to make that change.
> >>>>>
> >>>>> Neil, I'm not seeing this, I must be missing something.
> >>>>>
> >>>>> RPC_AUTH_TLS is used only on NULL procedures.
> >>>>>
> >>>>> The export's xprtsec= setting determines whether a TLS session must
> >>>>> be present to access the files on the export. If the TLS session
> >>>>> meets the xprtsec= policy, then the normal user authentication
> >>>>> settings apply. In other words, I don't think execution gets close
> >>>>> to check_nfsd_access() unless the xprtsec policy setting is met.
> >>>>
> >>>> check_nfsd_access() is literally the ONLY place that ->ex_xprtsec_modes
> >>>> is tested and that seems to be where xprtsec= export settings are stored.
> >>>>
> >>>>>
> >>>>> I'm not convinced check_nfsd_access() needs to care about
> >>>>> RPC_AUTH_TLS. Can you expand a little on your concern?
> >>>>
> >>>> Probably it doesn't care about RPC_AUTH_TLS which as you say is only
> >>>> used on NULL procedures when setting up the TLS connection.
> >>>>
> >>>> But it *does* care about NFS_XPRTSEC_MTLS etc.
> >>>>
> >>>> But I now see that RPC_AUTH_TLS is never reported by OP_SECINFO as an
> >>>> acceptable flavour, so the client cannot dynamically determine that TLS
> >>>> is required.
> >>>
> >>> Why is not RPC_AUTH_TLS announced in NFS4 OP_SECINFO? Should not NFS4
> >>> OP_SECINFO report all possible auth methods for particular filehandle?
> >>
> >> SECINFO reports user authentication flavors and pseudoflavors.
> >>
> >> RPC_AUTH_TLS is not a user authentication flavor, it is merely
> >> a query to see if the server peer supports RPC-with-TLS.
> >>
> >> So far the nfsv4 WG has not been able to come to consensus
> >> about how a server's transport layer security policies should
> >> be reported to clients. There does not seem to be a clean way
> >> to do that with existing NFSv4 protocol elements, so a
> >> protocol extension might be needed.
> >
> > Interesting...
> >
> > The distinction between RPC_AUTH_GSS_KRB5I and RPC_AUTH_GSS_KRB5P is not
> > about user authentication, it is about transport privacy.
>
> RPC_AUTH_GSS_KRB5I is Kerberos user authentication plus
> Kerberos integrity protection.
>
> RPC_AUTH_GSS_KRB5P is Kerberos user authentication plus
> Kerberos confidentiality.
>
> So, both of these pseudoflavors select Kerberos user
> authentication (versus, say, RPC_AUTH_UNIX, which does
> not).
I'd argue they also select on-the-wire protection. It just happens
that they use the session key for a user credential.
I'd agree with Neil, in that the 'p' refers to on-the-wire privacy.
>
>
> > And the distinction between xprtsec=tls and xprtsec=mtls seems to be
> > precisely about user authentication.
>
> No: xprtsec authentication is /peer/ authentication. User
> authentication is still set via sec= . See the final
> paragraph in Section 4.2 of RFC 9289.
True, but for krb5[ip] there is a (mis)use of a user principal for the
client's machine credential. (The user principal that does SetClientID
or ExchangeID.)
--> I'd argue that this user principal is really a client machine (or peer,
if you prefer) credential.
--> I think that the host based service principal in the client's keytab
      is a pita and maybe one of the reasons that krb5[ip] doesn't get
      used that much.

>
>
> > I would describe the current pseudo flavours as not "a clean way" to
> > advise the client of security requirements, but they are at least
> > established practice.
> >
> > RPC_AUTH_SYS_TLS  seems to me to be an obvious sort of pseudo flavour.
> >
> > But I suspect all these arguments and more have already been discussed
> > within the working group and people can sensibly have different
> > opinions.
>
> Yes, these arguments were discussed within the WG, and
> I even wrote a draft (now expired) that treated the
> various combinations of TLS and user authentication
> flavors as unique pseudoflavors. The idea was rejected.
I'll encourage NeilBrown to make comments related to the D. Noveck
security draft over on nfsv4@...t.org. (I'll admit I have great difficulty
getting around to reading/commenting on these drafts, but I will try to
get around to the security one one of these days.)

The piece I'd like to see is mtls being accepted as a reasonable
alternative to krb5i/krb5p for SP4_MACH_CRED.

Personally, I think the pseudo-flavors make sense.
Maybe I/Neil can illicit further discussion w.r.t. them, rick

>
>
> > Thanks for helping me understand NFS/TLS a bit better.
> >
> > NeilBrown
> >
> >
> >
> >>
> >>
> >>>> So there is no value in giving non-tls clients access to
> >>>> xprtsec=mtls exports so they can discover that for themselves.  The
> >>>> client needs to explicitly mount with tls, or possibly the client can
> >>>> opportunistically try TLS in every case, and call back.
> >>>>
> >>>> So the original patch is OK.
> >>>>
> >>>> NeilBrown
> >>
> >>
> >> --
> >> Chuck Lever
>
>
> --
> Chuck Lever
>
>

Powered by blists - more mailing lists