| Message ID | 20220331235251.4753-1-ematsumiya@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mount.cifs.rst: add FIPS information | expand |
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.
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
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 >
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
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
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
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
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 ****
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(+)