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