Message-ID: <A247373D-46F3-46F1-8C8C-996A95B1A49B@oracle.com>
Date: Mon, 7 Oct 2024 15:50:35 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Neil Brown <neilb@...e.de>
CC: 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 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).


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


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


> 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