FC12: Hidden files in /usr/bin/*

[Peter Jones]

On 01/22/2010 02:03 PM, Tom Lane wrote:
> Przemek Klosowski <przemek.klosowski at 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.

-- 
        Peter

Obviously, a major malfunction has occurred.
		-- Steve Nesbitt, voice of Mission Control, January 28, 1986