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;
Date:   Thu, 12 Aug 2021 20:23:44 -0700
From:   Eric Biggers <ebiggers@kernel.org>
To:     linux-cifs@vger.kernel.org, Steve French <sfrench@samba.org>
Cc:     samba-technical@lists.samba.org, linux-crypto@vger.kernel.org
Subject: Building cifs.ko without any support for insecure crypto?
Message-ID: <YRXlwDBfQql36wJx@sol.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: bulk

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

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?

- Eric