linux-kernel - Re: [GIT PULL] cifs/smb3 client fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH2r5mtTLUQa2U=MGHOVk_FsPZg6owMsw+RoTudWxGuoQej41g@mail.gmail.com>
Date:   Tue, 31 Aug 2021 12:08:48 -0500
From:   Steve French <smfrench@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        CIFS <linux-cifs@...r.kernel.org>
Subject: Re: [GIT PULL] cifs/smb3 client fixes

On Tue, Aug 31, 2021 at 11:40 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, Aug 29, 2021 at 10:48 PM Steve French <smfrench@...il.com> wrote:
> >
> > - mostly restructuring to allow disabling less secure algorithms (this
> > will allow eventual removing rc4 and md4 from general use in the
> > kernel)
>
> Well, you should probably have mentioned that you already started on
> this by removing LANMAN support.
>
> I'm sincerely hoping nobody used or depended on that old garbage in
> this day and age any more.
>
> Anyway, entirely unrelated question: you pretty much interchangeably
> use "cifs" or "smb3" for the filesystem, as shown once more by the
> commit messages here (but also the subject line).
>
> The filesystem directory is called "cifs", and I've taken to use that
> in my "Pull cifs updates" thing from you to just avoiding the
> confusion.
>
> And now we have ksmbd (yup, I just merged that pull request too), so
> we have a "cifs client" and a "smb server". Aaarrgh.
>
> I understand that some people may care about the name, may care about
> "smb2 vs smb3", or whatever. But I have to admit finding it a bit
> annoying how the code and the directory layout uses these different
> terms pretty much randomly with no real apparent logic.
>
> Somehow the NFS people had no problem completely changing everything
> about their protocols and then still calling the end result "nfs
> client" vs "nfs server".
>
> Oh well. I'm assuming it's not going to change, and it's not really a
> problem, I just wanted to mention my frustration about how clear as
> mud the naming is.
>              Linus


I (and many at Microsoft and in Samba team etc.) also have a strong
desire to stop
using the word "CIFS" as it has been associated with some very high profile
attacks, and with the introduction of SMB2.1 support (which was far more
secure) in 2009 no one should be using the very old CIFS dialect
(aka "SMB1" dialect).  So if you are ok with renaming the client dir and module
name - we can gradually stop using the word/name "cifs" except for the
parts of code which really are needed to access the (unfortunately
hundreds of millions of) very old devices which require SMB1 ("CIFS").
We could even build two versions of the module "smb3.ko" which does not
include support for the less secure legacy dialects and "cifs.ko" which does
include it.   Is there a precedent for something similar.

Note that with the introduction of various security features
in SMB3 (then even more security features in SMB3.1.1) it seems like it seemed
confusing to users to tell them "mount -t cifs ..." which was why I
added support
for "mount -t smb3 (to cifs.ko)  in the 4.18 kernel/   but I also
would strongly like to
stop using the word "cifs" in module name going forward, even if it does cause
a little bit of extra work for distros (most of which could be handled
in the mount
helper in any case)

If no objections,  we can start moving most things on
the client to "smb.ko" rather than "cifs.ko" ...

Do you have any objections to me renaming the client's source
directory to "fs/smb3"
(or fs/smb) and fs/smb3_common ...?



-- 
Thanks,

Steve