LFS using the cryptoapi hint...

Bryan Breen Bryan.C.Breen.1 at gsfc.nasa.gov
Tue Jul 8 18:03:09 PDT 2003

At 19:53 7/7/03 +0100, DaClink wrote:
>I managed to build lfs CVS20030603 sucessfully on an encrypted partition
>using the hint at http://hints.linuxfromscratch.org/hints/cryptoapi.txt
>It all works superbly except for only little bit... in the hint there is a
>section at the end which states the following:
>>Also, it is a good idea to check the boot partition integrity inside the
>>encrypted partition, in order to spot if someone, say a government agency
>>like the FBI or the NSA, has modified your boot partition so as to grab
>>your password. Add the following lines at the beginning of the system
>>initialisation script:
>>echo -n "Checking master boot record integrity: "
>>if [ "`dd if=/dev/hda count=1 2>/dev/null | md5sum`" = \
>> "e051a4532356709c73b86789acfbdbbd  -" ]
>>    echo "OK."
>>    echo -n "FAILED! press Enter to continue."
>>    read
>>echo -n "Checking bootloader integrity: "
>>if [ "`dd if=/dev/hda1 2>/dev/null | md5sum`" = \
>>"f3686a17fac8a1090d962bef59c86d3b  -" ]
>>    echo "OK."
>>    echo -n "FAILED! press Enter to continue."
>>    read
>The first part that checks the master boot record works fine... but the
>second bit i think is impossible (unless i'm putting the script in the
>wrond place) since the script itself is on the partition that gets
>md5sum'd. Hence changing the script changes the md5sum, meaning u need to
>change the script and so on and so on.
>Does anyone know a way round this? am i putting the script in the wrong
>place (at the moment its in the /loader/sbin/init script)

>From the beginning of the hint:

    1. Setting up the partition layout

Your hard disk should have at least three partitions:

  - one small (~ 8 Mb) unencrypted partition (let's say hda1),
    which will ask the password to mount your encrypted partition.

  - the encrypted partition holding the LFS system (hda2).

  - other temporary partitions for the host distribution.

The second bit of the check is the first partition mentioned in the setup
(hda1). It is unencrypted like the MBR (hda first sector check in the first
part). The place where you check to ensure the md5sums of those two regions
is just as the hint suggests:

>>Also, it is a good idea to check the boot partition integrity inside the
>>encrypted partition, in order to spot if someone, say a government agency

Those check commands given as examples need to be in your init scripts
(very early on to have a valid use) *inside* your encrypted partition (hda2).

For the paranoid, if the md5 checks ever trip a warning, and you hadn't
just changed the boot sector/partition and forgotten to updated the md5sum
values, then you've been made in some way. Someone or something has altered
your unencrypted MBR and boot partition. Virus? Hacker that's gained
previous entry? Who knows for sure (at first). What the hint alludes to is
that it is very possible at that point that a software keystroke logger is
running. At that point, the password you entered to mount your encrypted
partition (that then ran the check on the unencrypted partition) has
probably been "sniffed". Expect the Feds to be knocking at your door with a
search and seizure notice sometime soon. (That's just one really paranoid
example.) At that point, you should really not trust anything that your PC
is doing.

A clean reinstall from a trusted source (CD image stored in a safe for
example loaded after a clean boot off of a trusted boot image such as a
boot-CD) of the suspect partition would certainly be a consideration.
However, one would have to consider the password/phrase of the encrypted
partition compromised at that point. Time to re-encrypt the partition with
some fancy double loop device mounting and dd commands (not a lot of fun
and takes a lot more space and time [the Feds are coming, remember? :) ]
than you might have free if your encrypted partition is big).

Perhaps to be real cautious (and more easily deal with this type of
problem) one would want to create a "double layer" of encrypted partitions
(hda2 and hda3). hda2 would be mounted as in the hint examples and then run
the md5sum checks. If all looks clean and safe, then hda3 would be mounted
and pivot_root'd like hda2 was. hda3 of course would be the big partition
you have all your "private" data in. hda2 would only need to be big enough
to hold the midpoint encrypted check scripts and necessary binaries. hda2
in that case could easily be squeezed in at only a few MBs. If the md5
checks in hda2 then ever detected something amiss with hda or had1, the
"clean up" would be much easier since the password/phrase of your real data
(hda3) would never have been entered insecurely (as far as this setup is
able to detect). Just cleanly reinstall hda and hda1 from a safe copy (CD
image and boot suggestion from before), and then rebuild hda2 with a new
password/phrase to purge the concerns over the old password/phrase being
compromised. Of course, at the end, the md5sum used in hda3's check of the
newly built hda2 would also need to be updated.

Just a little bit more cautious paranoia for the hint, and that's kinda the
point of using an encrypted file system, right?

Christophe Devine might want to consider this as an added suggestion for
the hint, unless someone sees a huge hole in the logic of it.


- Bryan

| Any opinion expressed in |
| this message is my own   |
| and not those of NASA.   |

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message

More information about the blfs-support mailing list