Bug 1038097

Already in upstream. In before the upstream crypsetup-1.6.3

Ondrej, I looked into similar bz#1009707#c3 and there's a note


              | /etc/system-fips | no /etc/system-fips
--------------+------------------+----------------------
fips flag     |       enforce    |    no test/no fips
--------------+------------------+------
no fips flag  |       test       |    no test


in case of "no fips flag" X "/etc/system-fips": checksum failures are silent in library constructor. utility issues warning only. 

If I corrupt libcryptsetup hmac file, set fips=0 and leave /etc/system-fips file, I get no warning from the cryptsetup utility. I discussed it over IRC with sgrubb and was pointed at you to give me an explanation and confirmation whether this is right or not into this bz.

Many thanks,
Ladislav

If it would be a problem to implement the warning separately in cryptsetup I think there would be no problem to implement it in the libcryptsetup (either to syslog and/or to stderr as suited better for libcryptsetup). I don't think there is a big risk of libcryptsetup overspamming syslog in such situation.

Tomas, are you going to add the warning so I can move the bug to the verified state? 

Or is it the current behaviour sufficient to move the bug to the verified state?

Thanks.

Ondrej would have to add the warning. I don't think the current behaviour is right.

What is the meaning of libcryptsetup writing to syslog(In reply to Ladislav Jozsa from comment #4)
> Ondrej, I looked into similar bz#1009707#c3 and there's a note
> 
> 
>               | /etc/system-fips | no /etc/system-fips
> --------------+------------------+----------------------
> fips flag     |       enforce    |    no test/no fips
> --------------+------------------+------
> no fips flag  |       test       |    no test
> 
> 
> in case of "no fips flag" X "/etc/system-fips": checksum failures are silent
> in library constructor. utility issues warning only.

Excuse me for my late reply, I missed the bz notification.

It turned out cryptsetup (the utility only) doesn't require to be part of certification process. I just didn't updated the summary of the patch properly. Last time I read about warning path in POST, the libraries weren't recommended to issue warnings. When did that changed?

And yes, cryptsetup library is linked by few third party projects, most by notably systemd. This would generate one warning per encrypted device in system set to be unlocked on boot. Not an issue for a desktop, but...

Is it really such a big deal?

One warning per encrypted device is definitely no spamming so I think it still would be preferable to add the warning to the library. This is different situation than for example openssl or libgcrypt library where such warning could be generated many times as various tools link to it.

Adding table with actual implementation and detailed description. Tomas, can you please verify it's correct?

       | /etc/system-fips | no /etc/system-fips
-------+------------------+----------------------
   kff |     enforce      |    no test/no fips
-------+------------------+----------------------
no kff |   test/no fips   |    no test/no fips

'kff'    : kernel fips flag set to 1
'no kff' : kernel fips flag set to 0

"kff' X /etc/system-fips": POST fails with error if either checksums are missing or don't match. This is the only configuration where cryptsetup library operates under FIPS restrictions if POST pass.

"no kff X /etc/system-fips": Provided checksums are missing or don't match, POST issues same error message as "kff X /etc/system-fips" configuration but it doesn't fail with error. the cryptsetup is not considered to be running in FIPS mode even if it pass POST.

"no /etc/system-fips x kff": POST is skipped completely and the cryptsetup is not considered to be running in FIPS mode (no restrictions on library with regard to FIPS)

"no /etc/system-fips x no kff": same as above

Yes, this is correct.

https://code.google.com/p/cryptsetup/source/detail?r=4f89028c6760b69b5f94aaa44523b0913b586ae6

Reproduced on RHEL-7.0 x86_64 Client.
fips=1 + /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
[  124.420039] alg: self-tests for xts-aes-aesni (xts(aes)) passed
[  127.095944] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=1 + /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
libgcrypt selftest: binary  (0): Selftest failed (/lib64/.libgcrypt.so.11.hmac)
fatal error in libgcrypt, file visibility.c, line 1230, function gcry_randomize: called in non-operational state
Aborted (core dumped)

===================================================================================
fips=1 - /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -[   41.399073] alg: self-tests for xts-aes-aesni (xts(aes)) passed
[   44.066251] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=1 - /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
libgcrypt selftest: binary  (0): Selftest failed (/lib64/.libgcrypt.so.11.hmac)
[   57.456742] bio: create slab <bio-0> at 0
[   60.126338] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=0 + /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -[   54.247768] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=0 + /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
[   67.311380] bio: create slab <bio-0> at 0
[   70.016463] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=0 - /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
[  118.259595] bio: create slab <bio-0> at 0
[  120.981183] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
fips=0 - /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
[   97.855051] bio: create slab <bio-0> at 0
[  100.528524] bio: create slab <bio-0> at 0
Command successful.

===================================================================================
===================================================================================
Verified on RHEL-7.1-20150122.0 x86_64 Client:
fips=1 + /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
Running in FIPS mode.
[   83.790959] alg: self-tests for xts-aes-aesni (xts(aes)) passed
Command successful.

===================================================================================
fips=1 + /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
libgcrypt selftest: binary  (0): Selftest failed (/lib64/.libgcrypt.so.11.hmac)
Running in FIPS mode.
fatal error in libgcrypt, file visibility.c, line 1233, function gcry_randomize: called in non-operational state
[  117.078352] Pid 6660(cryptsetup) over core_pipe_limit
[  117.078989] Skipping core dump
Aborted

===================================================================================
fips=1 - /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
[  248.815506] alg: self-tests for xts-aes-aesni (xts(aes)) passed
Command successful.

===================================================================================
fips=1 - /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
libgcrypt selftest: binary  (0): Selftest failed (/lib64/.libgcrypt.so.11.hmac)
Not compatible PBKDF2 options (using hash algorithm sha1).
Command failed with code 22: Not compatible PBKDF2 options (using hash algorithm sha1).

===================================================================================
fips=0 + /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
Command successful.

===================================================================================
fips=0 + /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
libgcrypt selftest: binary  (0): Selftest failed (/lib64/.libgcrypt.so.11.hmac)
Command successful.

===================================================================================
fips=0 - /etc/system-fips (matching /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
Command successful.

===================================================================================
fips=0 - /etc/system-fips (damaged /usr/lib64/.libgcrypt.so.11.hmac)
# echo 'aaa' | cryptsetup -v luksFormat /dev/loop0 -d -
Command successful.

===================================================================================
===================================================================================

However it unfortunatelly seems, that there's regression in libgcrypt causing failure in scenario with fips=1 without /etc/system-fips and with damaged /usr/lib64/.libgcrypt.so.11.hmac

Tomas, can you please look on this?
Thanks

And what is the problem? fips=1 and no /etc/system-fips is undefined configuration which can do virtually anything (apart from destroying your hardware and data).

So I don't see a problem with the behaviour change which is not related to cryptsetup but to libgcrypt changes anyway.

Ok, great, switching to VERIFIED then.

Thanks

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0511.html