Hi,
On FC12 I found this:
# ls /usr/bin/.*.hmac /usr/bin/.fipscheck.hmac /usr/bin/.ssh.hmac
# rpm -qf /usr/bin/.*.hmac fipscheck-1.2.0-4.fc12.x86_64 openssh-clients-5.2p1-31.fc12.x86_64
Could somebody provide some insight what these files are (I guess some checksums) and why they are being installed to /usr/bin?
Packaging bug ?
Ralf
On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
Hi,
On FC12 I found this:
# ls /usr/bin/.*.hmac /usr/bin/.fipscheck.hmac /usr/bin/.ssh.hmac
# rpm -qf /usr/bin/.*.hmac fipscheck-1.2.0-4.fc12.x86_64 openssh-clients-5.2p1-31.fc12.x86_64
Could somebody provide some insight what these files are (I guess some checksums) and why they are being installed to /usr/bin?
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
Hi,
On FC12 I found this:
# ls /usr/bin/.*.hmac /usr/bin/.fipscheck.hmac /usr/bin/.ssh.hmac
# rpm -qf /usr/bin/.*.hmac fipscheck-1.2.0-4.fc12.x86_64 openssh-clients-5.2p1-31.fc12.x86_64
Could somebody provide some insight what these files are (I guess some checksums) and why they are being installed to /usr/bin?
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
Ralf
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I don't believe so---it's not my line of business but I understand that
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
- on Linux encryption (https, ssh) is handled by OpenSSL, which went through the FIPS certification process
- one of the conditions of FIPS certification is a capability for run-time consistency checks, hence the fipscheck package
- the fipscheck package checks against the checksums stored in the .XXX.hmac files, therefore those files are required if a system needs to be FIPS-compliant.
Having said that, I don't understand how does this scheme prevent someone from subverting the executable and creating a matching .hmac file, so that the fipscheck fails to see the problem. I expect it's handled properly but I don't know how.
On Fri, 2010-01-22 at 10:24 -0500, Przemek Klosowski wrote:
I don't believe so---it's not my line of business but I understand that
in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
on Linux encryption (https, ssh) is handled by OpenSSL, which went through the FIPS certification process
one of the conditions of FIPS certification is a capability for run-time consistency checks, hence the fipscheck package
the fipscheck package checks against the checksums stored in the .XXX.hmac files, therefore those files are required if a system needs to be FIPS-compliant.
Yes, all the above is correct although it does not mean that the packages in Fedora are certified, they just have/use the changes which are necessary for certification.
Having said that, I don't understand how does this scheme prevent someone from subverting the executable and creating a matching .hmac file, so that the fipscheck fails to see the problem. I expect it's handled properly but I don't know how.
No, it does not prevent malicious attacker from subverting the executable. The integrity check prevents just inadvertent modification of the executables/libraries which contain the certified code.
On Fri, Jan 22, 2010 at 5:04 PM, Tomas Mraz tmraz@redhat.com wrote:
No, it does not prevent malicious attacker from subverting the executable. The integrity check prevents just inadvertent modification of the executables/libraries which contain the certified code.
Like prelink? ;-)
m
On Fri, 2010-01-22 at 17:08 +0100, Martin Langhoff wrote:
On Fri, Jan 22, 2010 at 5:04 PM, Tomas Mraz tmraz@redhat.com wrote:
No, it does not prevent malicious attacker from subverting the executable. The integrity check prevents just inadvertent modification of the executables/libraries which contain the certified code.
Like prelink? ;-)
Yes, for example. That's why prelink must be disabled when the machine is running in the FIPS compliant mode.
On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I don't believe so---it's not my line of business but I understand that
I do ... and as a member of the FPC, I do have a strong opinion on this.
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
I don't know this "standard".
on Linux encryption (https, ssh) is handled by OpenSSL, which went through the FIPS certification process
one of the conditions of FIPS certification is a capability for run-time consistency checks, hence the fipscheck package
the fipscheck package checks against the checksums stored in the .XXX.hmac files, therefore those files are required if a system needs to be FIPS-compliant.
Having said that, I don't understand how does this scheme prevent someone from subverting the executable and creating a matching .hmac file, so that the fipscheck fails to see the problem.
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
I expect it's handled properly but I don't know how.
According to the FHS, such files belong somewhere below /usr/share, /usr/lib, /var or even /etc - /usr/bin is reserved for executables.
Package data, package metadata etc. belongs outside of /usr/bin etc.
Ralf
On Fri, Jan 22, 2010 at 4:11 PM, Ralf Corsepius rc040203@freenet.de wrote:
On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
These are checksums required by FIPS-140-2 integrity verification
checks
of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I don't believe so---it's not my line of business but I understand that
I do ... and as a member of the FPC, I do have a strong opinion on this.
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
I don't know this "standard".
on Linux encryption (https, ssh) is handled by OpenSSL, which went through the FIPS certification process
one of the conditions of FIPS certification is a capability for run-time consistency checks, hence the fipscheck package
the fipscheck package checks against the checksums stored in the .XXX.hmac files, therefore those files are required if a system needs to be FIPS-compliant.
Having said that, I don't understand how does this scheme prevent someone from subverting the executable and creating a matching .hmac file, so that the fipscheck fails to see the problem.
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
Google returns http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
It security standard which has nothing to do directly with Linux so its unlikely to refer to the FHS.
Peter
On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius rc040203@freenet.de wrote:
- in some circumstances (government, regulated companies) encryption
must be certified to the FIPS 140-2 standard
I don't know this "standard".
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
FIPS 140-2 is a US government standard for crypto system security. Its full text is available at http://csrc.nist.gov/groups/STM/cmvp/standards.html if you're interested.
I have no idea if it actually requires them to be alongside the executables, but hopefully the link will help.
-- Garrett Holmstrom
On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom gholms.fedora@gmail.com wrote:
On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius rc040203@freenet.de wrote:
- in some circumstances (government, regulated companies) encryption
must be certified to the FIPS 140-2 standard
I don't know this "standard".
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
FIPS 140-2 is a US government standard for crypto system security. Its full text is available at http://csrc.nist.gov/groups/STM/cmvp/standards.html if you're interested.
I have no idea if it actually requires them to be alongside the executables, but hopefully the link will help.
It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to get included in Red Hat Enterprise Linux 5 (a separate review from the Fedora one), and pointed out this same problem, and it was done properly for RHEL5:
$ rpm -ql hmaccalc /usr/bin/sha1hmac /usr/bin/sha256hmac /usr/bin/sha384hmac /usr/bin/sha512hmac /usr/lib64/hmaccalc /usr/lib64/hmaccalc/sha1hmac.hmac /usr/lib64/hmaccalc/sha256hmac.hmac /usr/lib64/hmaccalc/sha384hmac.hmac /usr/lib64/hmaccalc/sha512hmac.hmac /usr/share/doc/hmaccalc-0.9.6 /usr/share/doc/hmaccalc-0.9.6/LICENSE /usr/share/doc/hmaccalc-0.9.6/README /usr/share/man/man8/sha1hmac.8.gz /usr/share/man/man8/sha256hmac.8.gz /usr/share/man/man8/sha384hmac.8.gz /usr/share/man/man8/sha512hmac.8.gz
It should be simple enough to just update the Fedora packages with the changes in RHEL5 and we can all go eat cake. But first, I'm going to go play some pickup soccer...
On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson jarod@wilsonet.com wrote:
On Fri, Jan 22, 2010 at 11:23 AM, Garrett Holmstrom gholms.fedora@gmail.com wrote:
On Fri, Jan 22, 2010 at 10:11 AM, Ralf Corsepius rc040203@freenet.de wrote:
- in some circumstances (government, regulated companies) encryption
must be certified to the FIPS 140-2 standard
I don't know this "standard".
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
Do you have a pointer/reference to this "standard"? Does it really mandate pollution /usr/bin and thus $PATH?
FIPS 140-2 is a US government standard for crypto system security. Its full text is available at http://csrc.nist.gov/groups/STM/cmvp/standards.html if you're interested.
I have no idea if it actually requires them to be alongside the executables, but hopefully the link will help.
It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to get included in Red Hat Enterprise Linux 5 (a separate review from the Fedora one), and pointed out this same problem, and it was done properly for RHEL5:
$ rpm -ql hmaccalc /usr/bin/sha1hmac /usr/bin/sha256hmac /usr/bin/sha384hmac /usr/bin/sha512hmac /usr/lib64/hmaccalc /usr/lib64/hmaccalc/sha1hmac.hmac /usr/lib64/hmaccalc/sha256hmac.hmac /usr/lib64/hmaccalc/sha384hmac.hmac /usr/lib64/hmaccalc/sha512hmac.hmac /usr/share/doc/hmaccalc-0.9.6 /usr/share/doc/hmaccalc-0.9.6/LICENSE /usr/share/doc/hmaccalc-0.9.6/README /usr/share/man/man8/sha1hmac.8.gz /usr/share/man/man8/sha256hmac.8.gz /usr/share/man/man8/sha384hmac.8.gz /usr/share/man/man8/sha512hmac.8.gz
It should be simple enough to just update the Fedora packages with the changes in RHEL5 and we can all go eat cake. But first, I'm going to go play some pickup soccer...
Oh. Wait. Crap. We're talking about packages other than hmaccalc itself that do integrity checks. But I do agree with Ralf here, the checksum files don't belong in /usr/bin/, and there's no standard-based need for them to be there.
On Fri, Jan 22, 2010 at 12:13:06PM -0500, Jarod Wilson wrote:
On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson jarod@wilsonet.com wrote:
I have no idea if it actually requires them to be alongside the executables, but hopefully the link will help.
It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to get included in Red Hat Enterprise Linux 5 (a separate review from the Fedora one), and pointed out this same problem, and it was done properly for RHEL5:
$ rpm -ql hmaccalc /usr/bin/sha1hmac /usr/bin/sha256hmac /usr/bin/sha384hmac /usr/bin/sha512hmac /usr/lib64/hmaccalc /usr/lib64/hmaccalc/sha1hmac.hmac /usr/lib64/hmaccalc/sha256hmac.hmac /usr/lib64/hmaccalc/sha384hmac.hmac /usr/lib64/hmaccalc/sha512hmac.hmac /usr/share/doc/hmaccalc-0.9.6 /usr/share/doc/hmaccalc-0.9.6/LICENSE /usr/share/doc/hmaccalc-0.9.6/README /usr/share/man/man8/sha1hmac.8.gz /usr/share/man/man8/sha256hmac.8.gz /usr/share/man/man8/sha384hmac.8.gz /usr/share/man/man8/sha512hmac.8.gz
It should be simple enough to just update the Fedora packages with the changes in RHEL5 and we can all go eat cake. But first, I'm going to go play some pickup soccer...
Oh. Wait. Crap. We're talking about packages other than hmaccalc itself that do integrity checks. But I do agree with Ralf here, the checksum files don't belong in /usr/bin/, and there's no standard-based need for them to be there.
So few things that need doing here:
1) The present packages need to be fixecd. Sounds like fipscheck, hmaccalc, and openssh. They are violating the FHS which is prohibited by the Guidelines. Ralf, have you opened bugs?
2) We need to decide where to place the files. I don't know what uses them, so I'm not entirely certain about this. Here's some suggestions: * If each binary checks itself then %{_libdir}/%{name}/$PROGNAME.hmac seems reasonable. * If there are one of more programs (fipscheck?) that check the integrity of other binaries then we probably want a directory structure that is namespaced by itself and allows that other program to lookup the checksum for the binary. Something like: %{_libdir}/hmac%{_bindir}/$PROGNAME.hmac %{_libdir}/hmac%{_sbindir}/$PROGNAM2.hmac
The packaging guidelines can be updated to include #2 if necessary so that people needing to install these checksums know where they need to be installed but there's nothing blocking our making the changes now.
-Toshio
On Mon, 1 Feb 2010 13:38:13 -0500 Toshio Kuratomi a.badger@gmail.com wrote:
On Fri, Jan 22, 2010 at 12:13:06PM -0500, Jarod Wilson wrote:
On Fri, Jan 22, 2010 at 12:10 PM, Jarod Wilson jarod@wilsonet.com wrote:
I have no idea if it actually requires them to be alongside the executables, but hopefully the link will help.
It doesn't. Also, ugh. I'm the one who actually reviewed hmaccalc to get included in Red Hat Enterprise Linux 5 (a separate review from the Fedora one), and pointed out this same problem, and it was done properly for RHEL5:
$ rpm -ql hmaccalc /usr/bin/sha1hmac /usr/bin/sha256hmac /usr/bin/sha384hmac /usr/bin/sha512hmac /usr/lib64/hmaccalc /usr/lib64/hmaccalc/sha1hmac.hmac /usr/lib64/hmaccalc/sha256hmac.hmac /usr/lib64/hmaccalc/sha384hmac.hmac /usr/lib64/hmaccalc/sha512hmac.hmac /usr/share/doc/hmaccalc-0.9.6 /usr/share/doc/hmaccalc-0.9.6/LICENSE /usr/share/doc/hmaccalc-0.9.6/README /usr/share/man/man8/sha1hmac.8.gz /usr/share/man/man8/sha256hmac.8.gz /usr/share/man/man8/sha384hmac.8.gz /usr/share/man/man8/sha512hmac.8.gz
It should be simple enough to just update the Fedora packages with the changes in RHEL5 and we can all go eat cake. But first, I'm going to go play some pickup soccer...
Oh. Wait. Crap. We're talking about packages other than hmaccalc itself that do integrity checks. But I do agree with Ralf here, the checksum files don't belong in /usr/bin/, and there's no standard-based need for them to be there.
So few things that need doing here:
- The present packages need to be fixecd. Sounds like fipscheck,
hmaccalc, and openssh. They are violating the FHS which is prohibited by the Guidelines. Ralf, have you opened bugs?
I see:
openssl-0:1.0.0-0.20.beta5.fc13.i686 openssh-clients-0:5.3p1-21.fc13.x86_64 fipscheck-0:1.2.0-4.fc13.x86_64 libgcrypt-0:1.4.5-1.fc13.x86_64 fipscheck-lib-0:1.2.0-4.fc13.i686 openswan-0:2.6.24-1.fc13.x86_64 openssh-server-0:5.3p1-21.fc13.x86_64 fipscheck-lib-0:1.2.0-4.fc13.x86_64 openssl-0:1.0.0-0.20.beta5.fc13.x86_64 libgcrypt-0:1.4.5-1.fc13.i686 hmaccalc-0:0.9.12-1.fc13.x86_64
in rawhide that have *.hmac* files.
kevin
On Mon, Feb 01, 2010 at 01:38:13PM -0500, Toshio Kuratomi wrote:
- The present packages need to be fixecd. Sounds like fipscheck, hmaccalc,
and openssh. They are violating the FHS which is prohibited by the Guidelines. Ralf, have you opened bugs?
- We need to decide where to place the files. I don't know what uses them,
so I'm not entirely certain about this. Here's some suggestions:
- If each binary checks itself then %{_libdir}/%{name}/$PROGNAME.hmac seems reasonable.
- If there are one of more programs (fipscheck?) that check the integrity of other binaries then we probably want a directory structure that is namespaced by itself and allows that other program to lookup the checksum for the binary. Something like: %{_libdir}/hmac%{_bindir}/$PROGNAME.hmac %{_libdir}/hmac%{_sbindir}/$PROGNAM2.hmac
Caught j-rod and pjones on IRC who had the following insights:
* Each binary is supposed to perform an integrity check of itself when it starts. So each binary needs to be able to find its hmac file. * hazy recollection is that fipscheck is meant to check the integrity of any binray with checksums. So we do need to use a directory structure that fipscheck can use to find the checksums.
If I could get some input from the people who actually deal with fipscheck and this standard, that this is the way forward, I'll write up the Guidelines.
-Toshio
On Mon, 2010-02-01 at 14:00 -0500, Toshio Kuratomi wrote:
On Mon, Feb 01, 2010 at 01:38:13PM -0500, Toshio Kuratomi wrote:
- The present packages need to be fixecd. Sounds like fipscheck, hmaccalc,
and openssh. They are violating the FHS which is prohibited by the Guidelines. Ralf, have you opened bugs?
- We need to decide where to place the files. I don't know what uses them,
so I'm not entirely certain about this. Here's some suggestions:
- If each binary checks itself then %{_libdir}/%{name}/$PROGNAME.hmac seems reasonable.
- If there are one of more programs (fipscheck?) that check the integrity of other binaries then we probably want a directory structure that is namespaced by itself and allows that other program to lookup the checksum for the binary. Something like: %{_libdir}/hmac%{_bindir}/$PROGNAME.hmac %{_libdir}/hmac%{_sbindir}/$PROGNAM2.hmac
Caught j-rod and pjones on IRC who had the following insights:
- Each binary is supposed to perform an integrity check of itself when it starts. So each binary needs to be able to find its hmac file.
- hazy recollection is that fipscheck is meant to check the integrity of any binray with checksums. So we do need to use a directory structure that fipscheck can use to find the checksums.
If I could get some input from the people who actually deal with fipscheck and this standard, that this is the way forward, I'll write up the Guidelines.
I am sorry, but I do not see a real need for special guideline for the fipscheck checksums. The policy where these checksums should/will be placed should be decided by the fipscheck package itself. Of course I agree that the files must be moved from the current place to a subdirectory under %{_libdir} especially for the checksums of the binaries in %{_bindir} and %{_sbindir}.
There is still a slight problem with the library checksums especially for the libgcrypt library which currently resides in /%{_lib}. This means that if it looks for the checksum in %{_libdir}/fipscheck the /usr might not be mounted during the checksum verification. The question is whether the checksum in a hidden file in /%{_lib} violates FHS - in my opinion it does not as this is still non-executable arch-dependent file or whether we need to create a fipscheck subdirectory in /%{_lib} as well.
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
I am sorry, but I do not see a real need for special guideline for the fipscheck checksums. The policy where these checksums should/will be placed should be decided by the fipscheck package itself. Of course I
As soon as multiple packages are affected, there should be a guideline to document how something needs to be done to work, e.g. if someone wants to package a new software that contains fips checksums.
Regards Till
On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
I am sorry, but I do not see a real need for special guideline for the fipscheck checksums. The policy where these checksums should/will be placed should be decided by the fipscheck package itself. Of course I
As soon as multiple packages are affected, there should be a guideline to document how something needs to be done to work, e.g. if someone wants to package a new software that contains fips checksums.
Huh, shouldn't reading documentation in fipscheck package be sufficient?
Of course the documentation in the fipscheck package has to be changed to reflect the change.
On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote:
On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
I am sorry, but I do not see a real need for special guideline for the fipscheck checksums. The policy where these checksums should/will be placed should be decided by the fipscheck package itself. Of course I
As soon as multiple packages are affected, there should be a guideline to document how something needs to be done to work, e.g. if someone wants to package a new software that contains fips checksums.
Huh, shouldn't reading documentation in fipscheck package be sufficient?
Afaik, it would be the first packaging documentation that's in a package instead of the wiki. It would probably not be indexed by search engines and not as easy reachable by people building packages for Fedora, who do not run Fedora themselves. But maybe these reasons are not that applicable for fipscheck, because there is only a limited set of packages that make use of it.
Regards Till
On Tue, 2010-02-02 at 21:54 +0100, Till Maas wrote:
On Tue, Feb 02, 2010 at 09:30:44PM +0100, Tomas Mraz wrote:
On Tue, 2010-02-02 at 20:13 +0100, Till Maas wrote:
On Tue, Feb 02, 2010 at 10:28:11AM +0100, Tomas Mraz wrote:
I am sorry, but I do not see a real need for special guideline for the fipscheck checksums. The policy where these checksums should/will be placed should be decided by the fipscheck package itself. Of course I
As soon as multiple packages are affected, there should be a guideline to document how something needs to be done to work, e.g. if someone wants to package a new software that contains fips checksums.
Huh, shouldn't reading documentation in fipscheck package be sufficient?
Afaik, it would be the first packaging documentation that's in a package instead of the wiki. It would probably not be indexed by search engines and not as easy reachable by people building packages for Fedora, who do not run Fedora themselves. But maybe these reasons are not that applicable for fipscheck, because there is only a limited set of packages that make use of it.
Isn't it logical to have it documented in the fipscheck? If you want to use fipscheck you have to know where it looks for the checksums. And yes, I do not think there will be more packages with the .hmac checksums than they are currently in the near future. Of course "never say never" but anyway they will not be widespread because of the costs associated with FIPS module certification which means that it is highly improbable that the number of such modules with support for the certification will raise substantially.
Tomas Mraz wrote:
There is still a slight problem with the library checksums especially for the libgcrypt library which currently resides in /%{_lib}. This means that if it looks for the checksum in %{_libdir}/fipscheck the /usr might not be mounted during the checksum verification.
Will all programs that use Gcrypt stop working if the checksum is unavailable or can the library function without the checksum in an emercency recovery situation? Does anybody know?
Björn Persson
On Tue, 2010-02-02 at 21:04 +0100, Björn Persson wrote:
Tomas Mraz wrote:
There is still a slight problem with the library checksums especially for the libgcrypt library which currently resides in /%{_lib}. This means that if it looks for the checksum in %{_libdir}/fipscheck the /usr might not be mounted during the checksum verification.
Will all programs that use Gcrypt stop working if the checksum is unavailable or can the library function without the checksum in an emercency recovery situation? Does anybody know?
The library will work fine and it will not compute the checksum at all if the FIPS mode is not enabled which is the normal situation.
Tomas Mraz wrote:
The library will work fine and it will not compute the checksum at all if the FIPS mode is not enabled which is the normal situation.
Then perhaps FIPS mode can be left disabled until /usr has been mounted, so that the checksum can be in %{_libdir}/fipscheck?
Björn Persson
On Tue, 2010-02-02 at 22:56 +0100, Björn Persson wrote:
Tomas Mraz wrote:
The library will work fine and it will not compute the checksum at all if the FIPS mode is not enabled which is the normal situation.
Then perhaps FIPS mode can be left disabled until /usr has been mounted, so that the checksum can be in %{_libdir}/fipscheck?
I am not sure this is possible. In following, albeit quite theoretical, scenario libgcrypt would be needed to mount encrypted filesystem holding the /usr tree. Such operation would be probably required to be running with the libgcrypt already in the FIPS mode.
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
On 01/22/2010 04:24 PM, Przemek Klosowski wrote:
On 01/22/2010 07:53 AM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I don't believe so---it's not my line of business but I understand that
I do ... and as a member of the FPC, I do have a strong opinion on this.
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
I don't know this "standard".
http://lmgtfy.com/?q=FIPS-140-2
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
- in some circumstances (government, regulated companies) encryption must be certified to the FIPS 140-2 standard
I don't know this "standard".
Well, FIPS 140-2 is a requirement put out by US federal government that every piece of encryption used by the government (including I think the military) must conform to. Since the US is arguably leading in the 'official' cryptography, FIPS 140-2 is often adopted worldwide whenever a formal cryptography qualification is required. It's not exactly hard to find out about it:
http://en.wikipedia.org/wiki/FIPS_140-2 http://csrc.nist.gov/groups/STM/cmvp/standards.html#02
May-be this "fips standard" collides with the FHS, may-be this standard is defective?
...
Does it really mandate pollution /usr/bin and thus $PATH?
OK, I see, you don't object to the checksums in principle, just to the location of the files. I don't believe that FIPS requires a specific location for the checksums---it's just that they are to be found somewhere. I can see two possible solutions:
- fipscheck looks for the checksum in some standard location, for instance /lib/lib64/hmac/usr/bin/xyz, similar to how it was done in RHEL5
- we find a way to stick the checksum in the executable itself, either by being clever about computing a checksum that will agree with the executable AFTER the checksum is written in (I have no idea how to do that) or by excluding the checksum field from the checksum calculation.
Both seem to be an 'upstream' issues. Question to Jared Wilson: was the RHEL solution you talked about done upstream or as a patch in the RHEL package?
NB, when I try to validate the binaries, I get
[root@localhost]# FIPSCHECK_DEBUG=error fipscheck /usr/bin/fipscheck fipscheck: FIPS_mode_set() failed
with the exit code 14, implying that the self-test of the libfipscheck library failed. Also, the checksums don't match:
[root@localhost]# sha256sum /usr/bin/fipscheck f7a11277bcfb470dba958b9f1c5bc54b9af2bbec2f4e64af96673bb63b51b58a
does not agree with the stored SHA
[root@localhost]# cat /usr/bin/.fipscheck.hmac e817bd09307c10a9d53cca95f73dd694cbf0cefebc452e515406eee0226b11a6
Is my crypto compromised :) ?
Przemek Klosowski przemek.klosowski@nist.gov writes:
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
Does it really mandate pollution /usr/bin and thus $PATH?
OK, I see, you don't object to the checksums in principle, just to the location of the files. I don't believe that FIPS requires a specific location for the checksums---it's just that they are to be found somewhere. I can see two possible solutions:
- fipscheck looks for the checksum in some standard location, for
instance /lib/lib64/hmac/usr/bin/xyz, similar to how it was done in RHEL5
- we find a way to stick the checksum in the executable itself, either
by being clever about computing a checksum that will agree with the executable AFTER the checksum is written in (I have no idea how to do that) or by excluding the checksum field from the checksum calculation.
I'm far from an expert in this, but I thought the intent of the FIPS standard here was to check the executables against some *separately stored* validation information. Standard or not, your second suggestion seems rather pointless --- an embedded checksum is 100% useless from any security perspective, since someone who could modify the file could change the checksum too. (I'm assuming it's just a checksum and not any sort of digital signature.)
The separate /lib directory tree seems the way to go, to me. That way the checksum files could be named the same as what they check, no magic needed.
regards, tom lane
On Fri, Jan 22, 2010 at 8:03 PM, Tom Lane tgl@redhat.com wrote:
The separate /lib directory tree seems the way to go, to me. That way
/usr/share instead of /lib seems more appropriate -
m
Martin Langhoff martin.langhoff@gmail.com writes:
On Fri, Jan 22, 2010 at 8:03 PM, Tom Lane tgl@redhat.com wrote:
The separate /lib directory tree seems the way to go, to me. That way
/usr/share instead of /lib seems more appropriate -
Hardly. Checksums on executables are going to be platform-specific. Putting them under /share is a violation of FHS, not to mention not workable in multilib contexts.
regards, tom lane
On 01/22/2010 02:03 PM, Tom Lane wrote:
Przemek Klosowski przemek.klosowski@nist.gov writes:
On 01/22/2010 11:11 AM, Ralf Corsepius wrote:
Does it really mandate pollution /usr/bin and thus $PATH?
OK, I see, you don't object to the checksums in principle, just to the location of the files. I don't believe that FIPS requires a specific location for the checksums---it's just that they are to be found somewhere. I can see two possible solutions:
- fipscheck looks for the checksum in some standard location, for
instance /lib/lib64/hmac/usr/bin/xyz, similar to how it was done in RHEL5
- we find a way to stick the checksum in the executable itself, either
by being clever about computing a checksum that will agree with the executable AFTER the checksum is written in (I have no idea how to do that) or by excluding the checksum field from the checksum calculation.
I'm far from an expert in this, but I thought the intent of the FIPS standard here was to check the executables against some *separately stored* validation information. Standard or not, your second suggestion seems rather pointless --- an embedded checksum is 100% useless from any security perspective, since someone who could modify the file could change the checksum too. (I'm assuming it's just a checksum and not any sort of digital signature.)
Well, the standard IIRC does want them to be separate, though again it's important to realize that this check isn't meant to protect against an attack, but rather to check against erroneous corruption of the binary. It seems unlikely that such corruption would change the checksum to match the errors ;)
The separate /lib directory tree seems the way to go, to me. That way the checksum files could be named the same as what they check, no magic needed.
Yes.
On Fri, Jan 22, 2010 at 03:06:24PM -0500, Peter Jones wrote:
Well, the standard IIRC does want them to be separate, though again it's important to realize that this check isn't meant to protect against an attack, but rather to check against erroneous corruption of the binary. It seems unlikely that such corruption would change the checksum to match the errors ;)
The separate /lib directory tree seems the way to go, to me. That way the checksum files could be named the same as what they check, no magic needed.
teach fipscheck to ask rpmlib ? rpm -V. We already have this method.
On 01/22/2010 05:30 PM, Matt Domsch wrote:
On Fri, Jan 22, 2010 at 03:06:24PM -0500, Peter Jones wrote:
Well, the standard IIRC does want them to be separate, though again it's important to realize that this check isn't meant to protect against an attack, but rather to check against erroneous corruption of the binary. It seems unlikely that such corruption would change the checksum to match the errors ;)
The separate /lib directory tree seems the way to go, to me. That way the checksum files could be named the same as what they check, no magic needed.
teach fipscheck to ask rpmlib ? rpm -V. We already have this method.
Fipscheck is more sophisticated---it checks its own integrity before checking the binary. It's a cruel world out there.
On 01/22/2010 01:53 PM, Ralf Corsepius wrote:
On 01/22/2010 01:22 PM, Tomas Mraz wrote:
On Fri, 2010-01-22 at 12:41 +0100, Ralf Corsepius wrote:
Hi,
On FC12 I found this:
# ls /usr/bin/.*.hmac /usr/bin/.fipscheck.hmac /usr/bin/.ssh.hmac
# rpm -qf /usr/bin/.*.hmac fipscheck-1.2.0-4.fc12.x86_64 openssh-clients-5.2p1-31.fc12.x86_64
Could somebody provide some insight what these files are (I guess some checksums) and why they are being installed to /usr/bin?
These are checksums required by FIPS-140-2 integrity verification checks of the fipscheck and ssh binaries.
I.e. package data.
=> These packages are non-FHS compliant and qualify as broken.
I think what Ralf means is
- these files should be put somewhere else, and - these files should not be hidden files
to which I agree 100%. So the question is: how much work is required ?
Speaking on funny things in /usr/bin
what about '/usr/bin/[', part of cureutils... had never noticed this one before.
-denis
On 01/22/2010 11:34 AM, Denis Leroy wrote:
Speaking on funny things in /usr/bin
what about '/usr/bin/[', part of cureutils... had never noticed this one before.
-denis
I came across that one day, too, and it seemed weird until I thought about shell scripts:
if [ $foo = "bar" ] then ... fi
See: man test
Josh
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Denis Leroy Sent: Friday, January 22, 2010 8:34 AM To: Development discussions related to Fedora Subject: Re: FC12: Hidden files in /usr/bin/*
*snip*
Speaking on funny things in /usr/bin
what about '/usr/bin/[', part of cureutils... had never noticed this one before.
-denis
Isn't that simply what makes "if [ (blah) ]" work?
Japheth "J.C." Cleaver jcleaver@soe.sony.com
On Fri, Jan 22, 2010 at 11:41 AM, Cleaver, Japheth jcleaver@soe.sony.comwrote:
-----Original Message----- From: devel-bounces@lists.fedoraproject.org [mailto:devel-bounces@lists.fedoraproject.org] On Behalf Of Denis Leroy Sent: Friday, January 22, 2010 8:34 AM To: Development discussions related to Fedora Subject: Re: FC12: Hidden files in /usr/bin/*
*snip*
Speaking on funny things in /usr/bin
what about '/usr/bin/[', part of cureutils... had never noticed this one before.
-denis
Isn't that simply what makes "if [ (blah) ]" work?
Yup! Thats not a hidden file, just a piece of magic. Its not hidden, it just _looks_ likes its obfuscated. :-(
On Fri, 2010-01-22 at 08:41 -0800, Cleaver, Japheth wrote:
Denis Leroy what about '/usr/bin/[', part of cureutils... had never noticed this one before.
-denis
Isn't that simply what makes "if [ (blah) ]" work?
It's cute isn't it? I had the biggest grin the day I realised that '[' was just another command..
Bryn.
On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves bmr@redhat.com wrote:
It's cute isn't it? I had the biggest grin the day I realised that '[' was just another command..
That's the reason [[ can use special characters like < and > without escaping, while [ can't: [[ is a builtin, but [ isn't.
-- Garrett Holmstrom
Garrett Holmstrom gholms@fedoraproject.org writes:
On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves bmr@redhat.com wrote:
It's cute isn't it? I had the biggest grin the day I realised that '[' was just another command..
That's the reason [[ can use special characters like < and > without escaping, while [ can't: [[ is a builtin, but [ isn't.
Well, [ is a builtin too, but [[ is a keyword recognised by the parser, thus it can use special parsing rules.
Andreas.
On Mon, 2010-01-25 at 16:44 +0100, Andreas Schwab wrote:
Garrett Holmstrom gholms@fedoraproject.org writes:
On Mon, Jan 25, 2010 at 6:09 AM, Bryn M. Reeves bmr@redhat.com wrote:
It's cute isn't it? I had the biggest grin the day I realised that '[' was just another command..
That's the reason [[ can use special characters like < and > without escaping, while [ can't: [[ is a builtin, but [ isn't.
Well, [ is a builtin too, but [[ is a keyword recognised by the parser, thus it can use special parsing rules.
<nitpick> [ may be a built in but then again (as its presence in /usr/bin implies) it may not be :). In traditional shells it was a proper command but is often a builtin these days.
[[..]] are one of the syntactic elements the bash provides for building compound commands.
Regards, Bryn.
"Bryn M. Reeves" bmr@redhat.com writes:
<nitpick> [ may be a built in but then again (as its presence in /usr/bin implies) it may not be :).
Like any other command.
Andreas.
On Mon, 2010-01-25 at 17:44 +0100, Andreas Schwab wrote:
"Bryn M. Reeves" bmr@redhat.com writes:
<nitpick> [ may be a built in but then again (as its presence in /usr/bin implies) it may not be :).
Like any other command.
But unlike '[[' which is the point I was replying to. Afaik you can't provide a '[[' binary and have it mimic the builtin exactly.
Regards, Bryn.
"Bryn M. Reeves" bmr@redhat.com writes:
On Mon, 2010-01-25 at 17:44 +0100, Andreas Schwab wrote:
"Bryn M. Reeves" bmr@redhat.com writes:
<nitpick> [ may be a built in but then again (as its presence in /usr/bin implies) it may not be :).
Like any other command.
But unlike '[[' which is the point I was replying to. Afaik you can't provide a '[[' binary and have it mimic the builtin exactly.
Because [[ is not a command, it is a reserved word, part of the shell grammar. That is the key difference, not the built-in property.
Andreas.
Once upon a time, Denis Leroy denis@poolshark.org said:
Speaking on funny things in /usr/bin
what about '/usr/bin/[', part of cureutils... had never noticed this one before.
Welcome to the past! :-) IIRC "[" has been in /bin or /usr/bin since the late 1970s.