[PATCH] mount.cifs.rst: add FIPS information

[PATCH] mount.cifs.rst: add FIPS information

[Enzo Matsumiya]

Add FIPS 140-2 compliance information regarding mounting SMB shares.

Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
---
 mount.cifs.rst | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/mount.cifs.rst b/mount.cifs.rst
index 9d4446f035b6..4ca46976fee6 100644
--- a/mount.cifs.rst
+++ b/mount.cifs.rst
@@ -376,6 +376,10 @@ sec=arg
   may be enabled automatically. Packet signing may also be enabled
   automatically if it's enabled in */proc/fs/cifs/SecurityFlags*.
 
+  For environments that requires FIPS 140-2 compliance, only ``sec=krb5`` and
+  ``sec=krb5i`` are valid. See also ``vers``. See section `SECURITY`_
+  for more information.
+
 seal
   Request encryption at the SMB layer. The encryption algorithm used
   is AES-128-CCM. Requires SMB3 or above (see ``vers``).
@@ -624,6 +628,9 @@ vers=arg
   kernels prior to v4.13, the default was ``1.0``. For kernels
   between v4.13 and v4.13.5 the default is ``3.0``.
 
+  For environments that requires FIPS 140-2 compliance, only version ``2.0`` or
+  or newer is allowed. See section `SECURITY`_ for more information.
+
 --verbose
   Print additional debugging information for the mount. Note that this
   parameter must be specified before the ``-o`` . For example::
@@ -923,6 +930,29 @@ by default at mount time. Old dialects such as CIFS (SMB1, ie vers=1.0)
 have much weaker security. Use of CIFS (SMB1) can be disabled by
 modprobe cifs disable_legacy_dialects=y.
 
+For environments that requires FIPS 140-2 compliance, the following applies:
+
+- SMB1 (``vers=1.0``) is not allowed
+- SMB2 and newer are only allowed with ``sec=krb5`` or ``sec=krb5i`` security
+  modes
+
+This is because FIPS 140-2 does not approve MD4/MD5 hashing algorithms, which
+are used either by SMB1 or the other security modes.
+
+When running a kernel in FIPS mode (i.e. with ``fips=1`` in boot command line),
+the above will be enforced, and running ``mount.cifs`` might fail.
+In the failing cases, the following error message (or similar, depending on the
+security mode) will appear in the ring buffer:
+
+  "CIFS VFS: could not allocate crypto hmacmd5"
+
+When not running a kernel in FIPS mode, the above serves only as informational
+purpose as ``mount.cifs`` does not enforce any of that.
+
+References:
+FIPS 140-2 Implementation Guide, G.6
+`https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf<https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf>`_
+
 ****
 BUGS
 ****
-- 
2.34.1

Re: [PATCH] mount.cifs.rst: add FIPS information

[Tom Talpey]

On 3/31/2022 7:52 PM, Enzo Matsumiya wrote:
> Add FIPS 140-2 compliance information regarding mounting SMB shares.
> 
> Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
...
> @@ -624,6 +628,9 @@ vers=arg
>     kernels prior to v4.13, the default was ``1.0``. For kernels
>     between v4.13 and v4.13.5 the default is ``3.0``.
>   
> +  For environments that requires FIPS 140-2 compliance, only version ``2.0`` or
> +  or newer is allowed. See section `SECURITY`_ for more information.

Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
support anything higher is obviously far out of date. I think it
would be better to recommend, or maybe even require, SMB3 here.

Tom.

Re: [PATCH] mount.cifs.rst: add FIPS information

[Enzo Matsumiya]

On 04/01, Tom Talpey wrote:
>Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
>support anything higher is obviously far out of date.

It's more that the crypto stuff used by SMB1 is *not* compliant.
If SMB2 keeps using FIPS-approved hashing/crypto algorightms, I guess it
makes it FIPS compliant, and the burden is on their end to disqualify
older algorithms for their certification.

> I think it
>would be better to recommend, or maybe even require, SMB3 here.

So, I've added a bit in the SECURITY section saying that mount.cifs
doesn't enforce anything, and all crypto blocking/allowing is made on
the kernel.

Do you think we should? An informed user, with particular requirements,
might want to use SMB2 *and* still be FIPS compliant, but we would be
enforcing something (non-SMB3) that's not quite right.

And if the kernel is not in FIPS mode, we should only inform the user,
because we don't actually use/do any crypto computation in mount.cifs.


Cheers,

Enzo

Re: [PATCH] mount.cifs.rst: add FIPS information

[Tom Talpey]

On 4/1/2022 11:25 AM, Enzo Matsumiya wrote:
> On 04/01, Tom Talpey wrote:
>> Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
>> support anything higher is obviously far out of date.
> 
> It's more that the crypto stuff used by SMB1 is *not* compliant.

Sure, but that's not the point here. It's time to simply state
"don't use SMB1".

> If SMB2 keeps using FIPS-approved hashing/crypto algorightms, I guess it
> makes it FIPS compliant, and the burden is on their end to disqualify
> older algorithms for their certification.

I don't think the crypto algorithm is enough. SMB2 is vulnerable
to man-in-the-middle attacks and therefore the crypto type is
only a part of the picture. SMB3 is much stronger, even with the
same crypto algs.

>> I think it
>> would be better to recommend, or maybe even require, SMB3 here.
> 
> So, I've added a bit in the SECURITY section saying that mount.cifs
> doesn't enforce anything, and all crypto blocking/allowing is made on
> the kernel.
> 
> Do you think we should? An informed user, with particular requirements,
> might want to use SMB2 *and* still be FIPS compliant, but we would be
> enforcing something (non-SMB3) that's not quite right.

The Microsoft FIPS statement only refers to SMB3, for example:

 
https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation

   Is SMB3 (Server Message Block) FIPS 140 compliant in Windows?

   SMB3 can be FIPS 140 compliant, if Windows is configured to operate in
   FIPS 140 mode on both client and server. In FIPS mode, SMB3 relies on
   the underlying Windows FIPS 140 validated cryptographic modules for
   cryptographic operations.

I think anyone who is serious enough to want FIPS should darn well
be advised that the best security means running the strongest version
of the protocol, and the doc should not waffle around with discussion
of SMB1 or SMB2.

MHO.

Tom.

> And if the kernel is not in FIPS mode, we should only inform the user,
> because we don't actually use/do any crypto computation in mount.cifs.
> 
> 
> Cheers,
> 
> Enzo
> 

Re: [PATCH] mount.cifs.rst: add FIPS information

[Enzo Matsumiya]

On 04/01, Tom Talpey wrote:
>On 4/1/2022 11:25 AM, Enzo Matsumiya wrote:
>>On 04/01, Tom Talpey wrote:
>>>Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
>>>support anything higher is obviously far out of date.
>>
>>It's more that the crypto stuff used by SMB1 is *not* compliant.
>
>Sure, but that's not the point here. It's time to simply state
>"don't use SMB1".

I 100% agree.

But, actually, that's the whole point of my commit. I just wanted to add
what will work with mount.cifs on a FIPS compliant environment. Nothing
else.

Stating "don't use SMB1" (either FIPS or not) could come in a different
commit.

(Personally, I would've nuked all SMB1 from the kernel altogether :P)

>I don't think the crypto algorithm is enough. SMB2 is vulnerable
>to man-in-the-middle attacks and therefore the crypto type is
>only a part of the picture. SMB3 is much stronger, even with the
>same crypto algs.

Again, I agree. But I'd say it's up to FIPS to mandate that. Even
because their requirements only cover the crypto modules, not
filesystems and/or versions as a whole AFAIK.

>The Microsoft FIPS statement only refers to SMB3, for example:
>
>
>https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation
>
>  Is SMB3 (Server Message Block) FIPS 140 compliant in Windows?
>
>  SMB3 can be FIPS 140 compliant, if Windows is configured to operate in
>  FIPS 140 mode on both client and server. In FIPS mode, SMB3 relies on
>  the underlying Windows FIPS 140 validated cryptographic modules for
>  cryptographic operations.

But that's on a product (OS) level. We're preparing similar
documentation for SUSE as well, for example.

>I think anyone who is serious enough to want FIPS should darn well
>be advised that the best security means running the strongest version
>of the protocol, and the doc should not waffle around with discussion
>of SMB1 or SMB2.

And again, I also agree. My intent was to rather have specified in the
docs what's supported in FIPS mode. Suggesting/enforcing a particular
version or security mode was out of scope of my patch.


Cheers,

Enzo

Re: [PATCH] mount.cifs.rst: add FIPS information

[Steve French]

SMB2.1 or later is probably fine (and we note SMB2.1 or 3) for most
cases in our mount warning message.

But this FIPS compliance issue reminds me that we should get the other
auth mechanisms working that are 'peer to peer' (so not forced to be
domain joined).   krb5 is great, but Macs support 'peer-to-peer
kerberos' and also SCRAM (RFC 7677) so we could also presumably get
FIPS compliant login for peer-to-peer cases if we implement on or both
of those other auth mechanisms.

Anyone have some Macs or Mac VMs to test against ...?

On Fri, Apr 1, 2022 at 12:41 PM Enzo Matsumiya <ematsumiya@suse.de> wrote:
>
> On 04/01, Tom Talpey wrote:
> >On 4/1/2022 11:25 AM, Enzo Matsumiya wrote:
> >>On 04/01, Tom Talpey wrote:
> >>>Is SMB2 really FIPS compliant? Even if it is, a server that doesn't
> >>>support anything higher is obviously far out of date.
> >>
> >>It's more that the crypto stuff used by SMB1 is *not* compliant.
> >
> >Sure, but that's not the point here. It's time to simply state
> >"don't use SMB1".
>
> I 100% agree.
>
> But, actually, that's the whole point of my commit. I just wanted to add
> what will work with mount.cifs on a FIPS compliant environment. Nothing
> else.
>
> Stating "don't use SMB1" (either FIPS or not) could come in a different
> commit.
>
> (Personally, I would've nuked all SMB1 from the kernel altogether :P)
>
> >I don't think the crypto algorithm is enough. SMB2 is vulnerable
> >to man-in-the-middle attacks and therefore the crypto type is
> >only a part of the picture. SMB3 is much stronger, even with the
> >same crypto algs.
>
> Again, I agree. But I'd say it's up to FIPS to mandate that. Even
> because their requirements only cover the crypto modules, not
> filesystems and/or versions as a whole AFAIK.
>
> >The Microsoft FIPS statement only refers to SMB3, for example:
> >
> >
> >https://docs.microsoft.com/en-us/windows/security/threat-protection/fips-140-validation
> >
> >  Is SMB3 (Server Message Block) FIPS 140 compliant in Windows?
> >
> >  SMB3 can be FIPS 140 compliant, if Windows is configured to operate in
> >  FIPS 140 mode on both client and server. In FIPS mode, SMB3 relies on
> >  the underlying Windows FIPS 140 validated cryptographic modules for
> >  cryptographic operations.
>
> But that's on a product (OS) level. We're preparing similar
> documentation for SUSE as well, for example.
>
> >I think anyone who is serious enough to want FIPS should darn well
> >be advised that the best security means running the strongest version
> >of the protocol, and the doc should not waffle around with discussion
> >of SMB1 or SMB2.
>
> And again, I also agree. My intent was to rather have specified in the
> docs what's supported in FIPS mode. Suggesting/enforcing a particular
> version or security mode was out of scope of my patch.
>
>
> Cheers,
>
> Enzo



-- 
Thanks,

Steve

Re: [PATCH] mount.cifs.rst: add FIPS information

[Enzo Matsumiya]

On 04/03, Steve French wrote:
>SMB2.1 or later is probably fine (and we note SMB2.1 or 3) for most
>cases in our mount warning message.
>
>But this FIPS compliance issue reminds me that we should get the other
>auth mechanisms working that are 'peer to peer' (so not forced to be
>domain joined).   krb5 is great, but Macs support 'peer-to-peer
>kerberos' and also SCRAM (RFC 7677) so we could also presumably get
>FIPS compliant login for peer-to-peer cases if we implement on or both
>of those other auth mechanisms.

Thanks, Steve. AFAIK, as I mentioned earlier, I don't see FIPS
disapproving particular auth mechanisms, but if those you mention uses
algorithms that are not on FIPS-validated crypto modules, we're out of
luck there as well.

(full disclosure: I'm not yet familiar with "peer-to-peer kerberos")

On-topic: I'd just like to have this patch merged for informational
purposese only. I then can start working on your's and Tom's
suggestions.

>Anyone have some Macs or Mac VMs to test against ...?

Yes. But let's move this one privately please.


Cheers,

Enzo

Re: [PATCH] mount.cifs.rst: add FIPS information

[Pavel Shilovsky]

Hi Enzo,

Thanks for the patch.

After it is applied, the build fails on my machine:

rst2man --syntax-highlight=none mount.cifs.rst mount.cifs.8
mount.cifs.rst:952: (ERROR/3) Unknown target name:
"https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf<https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf>".

Does it compile on your side?

Best regards,
Pavel Shilovsky

пн, 4 апр. 2022 г. в 19:26, Enzo Matsumiya <ematsumiya@suse.de>:
>
> On 04/03, Steve French wrote:
> >SMB2.1 or later is probably fine (and we note SMB2.1 or 3) for most
> >cases in our mount warning message.
> >
> >But this FIPS compliance issue reminds me that we should get the other
> >auth mechanisms working that are 'peer to peer' (so not forced to be
> >domain joined).   krb5 is great, but Macs support 'peer-to-peer
> >kerberos' and also SCRAM (RFC 7677) so we could also presumably get
> >FIPS compliant login for peer-to-peer cases if we implement on or both
> >of those other auth mechanisms.
>
> Thanks, Steve. AFAIK, as I mentioned earlier, I don't see FIPS
> disapproving particular auth mechanisms, but if those you mention uses
> algorithms that are not on FIPS-validated crypto modules, we're out of
> luck there as well.
>
> (full disclosure: I'm not yet familiar with "peer-to-peer kerberos")
>
> On-topic: I'd just like to have this patch merged for informational
> purposese only. I then can start working on your's and Tom's
> suggestions.
>
> >Anyone have some Macs or Mac VMs to test against ...?
>
> Yes. But let's move this one privately please.
>
>
> Cheers,
>
> Enzo