Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <YRXlwDBfQql36wJx@sol.localdomain>
In-Reply-To: <YRXlwDBfQql36wJx@sol.localdomain>
From:   ronnie sahlberg <ronniesahlberg@gmail.com>
Date:   Fri, 13 Aug 2021 14:46:21 +1000
Message-ID: <CAN05THSm5fEcnLKxcsidKPRUC6PVLCkWMBZUW05KNm4uMJNHWw@mail.gmail.com>
Subject: Re: Building cifs.ko without any support for insecure crypto?
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     linux-cifs <linux-cifs@vger.kernel.org>,
        Steve French <sfrench@samba.org>,
        "samba-technical@lists.samba.org" <samba-technical@lists.samba.org>,
        linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Aug 13, 2021 at 1:34 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> Hi!
>
> We should be working to eliminate any uses of insecure crypto algorithms (e.g.
> DES, ARC4, MD4, MD5) from the kernel.  In particular, it should be possible to
> build a kernel for a modern system without including any such algorithms.
>
> Currently, CONFIG_CIFS is problematic because it selects all these algorithms
> (kconfig options: CONFIG_CRYPTO_LIB_DES, CONFIG_CRYPTO_LIB_ARC4,
> CONFIG_CRYPTO_MD4, CONFIG_CRYPTO_MD5).
>
> It looks like these algorithms might only be used by SMB2.0 and earlier, and the
> more modern SMB versions don't use them.  Is that the case?  It mostly looks
> like that, but there's one case I'm not sure about -- there's a call chain which
> appears to use ARC4 and HMAC-MD5 even with the most recent SMB version:
>
>     smb311_operations.sess_setup()
>       SMB2_sess_setup()
>         SMB2_sess_auth_rawntlmssp_authenticate()
>           build_ntlmssp_auth_blob()
>             setup_ntlmv2_rsp()

md4 and md5 are used with the NTLMSSP authentication for all dialects,
including the latest 3.1.1.
The only other authentication mechanism for SMB is krb5.

This means that if we build a kernel without md4/md5 then we can no
longer use NTLMSSP user/password
style authentication, only kerberos.
I guess that the use cases where a kernel without these algorithms are
present are ok with kerberos as the
only authentication mech.

Afaik arc4 is only used for signing in the smb1 case.

>
> Also, there's already an option CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n which
> disables support for SMB2.0 and earlier.  However, it doesn't actually compile
> out the code but rather just prevents it from being used.  That means that the
> DES and ARC4 library interfaces are still depended on at link time, so they
> can't be omitted.  Have there been any considerations towards making
> CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n compile out the code for SMB2.0 and earlier?

I think initially we just wanted to disable its use. If we want to
compile a kernel completely without arc4/md4/md5 I think we would need
to:

1, Change CONFIG_CIFS_ALLOW_INSECURE_LEGACY=n to compile out the code
as you suggests.
This should remove the dependency for arc4. I think this would be a
good thing to do.

2, Have a different CONFIG_... to compile out the use of NTLMSSP
authentication. This must be a different define
since md4/md5 are also used for non-legacy dialects.
And this should remove the dependency of md4/5.

For the latter, I guess we would need a global, i.e. not
cifs-specific, config option for this. I assume other users of
rc4/md4/md5
would also want this.
A new CONFIG_INSECURE_CRYPTO=n ?

Ronnie Sahlberg

>
> - Eric