From: ronnie sahlberg <email@example.com>
To: Eric Biggers <firstname.lastname@example.org>
Cc: linux-cifs <email@example.com>,
Steve French <firstname.lastname@example.org>,
Subject: Re: Building cifs.ko without any support for insecure crypto?
Date: Fri, 13 Aug 2021 14:46:21 +1000 [thread overview]
Message-ID: <CAN05THSm5fEcnLKxcsidKPRUC6PVLCkWMBZUW05KNm4uMJNHWw@mail.gmail.com> (raw)
On Fri, Aug 13, 2021 at 1:34 PM Eric Biggers <email@example.com> wrote:
> 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:
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
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
would also want this.
A new CONFIG_INSECURE_CRYPTO=n ?
> - Eric
next prev parent reply other threads:[~2021-08-13 4:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 3:23 Building cifs.ko without any support for insecure crypto? Eric Biggers
2021-08-13 4:46 ` ronnie sahlberg [this message]
2021-08-13 20:19 ` Eric Biggers
2021-08-15 10:38 ` ronnie sahlberg
2021-08-16 22:19 ` Eric Biggers
2021-08-17 5:35 ` Steve French
2021-08-18 11:44 ` Ard Biesheuvel
2021-08-19 3:43 ` ronnie sahlberg
2021-08-19 3:53 ` Andrew Bartlett
2021-08-23 10:04 ` Simo Sorce
2021-08-24 16:41 ` Steve French
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).