On Fri, Mar 02, 2007 at 09:50:27PM +0100, David Härdeman wrote:
On Fri, Mar 02, 2007 at 06:26:19PM +0100, Josef Wolf wrote:
>On Fri, Mar 02, 2007 at 08:59:01AM +0100, David Härdeman wrote:
[Sorry for the delay, but I had to create a new CD and reinstall from
scratch to find out the version of libklibc just at first reboot]
>>I have verified that mkfs.ext3 does remove the LUKS signature from a
>>device,
>
>This is exactly what I wrote in my previos mail: when I run mke2fs by hand,
>everything works. If I choose "reformat with ext3" in partman, it fails.
Sorry, I should have mentioned also that partman uses mkfs.ext3 to
reformat a partition with ext3.
Maybe partman calls mkfs.ext3 with some special parameters?
I ran the following test yesterday:
Full install, /dev/sda split into /dev/sda1 /dev/sda2, /dev/sda1
unencrypted and containing /boot, /dev/sda2 encrypted and containing a
LVM PV which contained the rest of the filesystems and swap partition.
Can you please try the same test without LVM, but with "cryptsetup
luksFormat" instead? Please note the LUKS. I don't know whether
the problem still happens with LVM (blocks can be remapped, so the
signature might end up on a different position on the partition) or
with different crypt methods (different signature).
>properly. The first reboot (after the base system is installed) fails,
>before any of my scripts are started
>
>If I (while beeing in partman) switch to a different vterm and run
>mke2fs manually, then go back to partman and continue the installation,
>everything works properly. So a manual mke2fs wipes out the luks
>signature, while "format with ext3" in partman fails to wipe it.
Which libklibc version does your installed system use?
1.4.0-0ubuntu3 at first reboot
1.4.0-0ubuntu after apt-get upgrade
Is this _down_graded by apt-get? Or does "dpkg -l" cut off its output?
Do you think libklibc is causing the problem?
>>Anyhow, your approach seems quite fragile and contains some potential for
>>information leaks,
>
>Can you please activate your verbosity mode? ;-) What potential problems
>do you see?
If you install to one unencrypted partition first, things like
/etc/passwd will be written there.
I don't see a problem here. I install with a default password using
d-i passwd/user-password-crypted password <some-hash>
anyway. When the crypted system is booted the first time, it requests
a PW-change.
Then (as far as I've understood from your scripts) you create an
encrypted partition later and move over all the data to that partition.
correct?
Yes...
If so, you must take care to both wipe the old unencrypted partition
(not format it, but wipe it)
Ummm... That is (apart from my added scripts) a default ubuntu install.
No sensitive data there. Why should I take special efforts to wipe
something that you can download from ubuntu.com anyway? The only
sensitive data I can think of are partition information and ssh
host-keys.
Besides, my further plan is to re-use this old partition as (encrypted)
swap space later on. So I will randomize it. But I don't see the need
to shred it or something.
and before the crypted partition is used, it should also be wiped with
random data to make sure that it is not possible to tell which parts are
in use and which are not.
Finally, you got me. I almost forgot about this one. Unfortunately,
/dev/urandom is soooo sloooow. :-(
Maybe "dd if=/dev/zero of=/dev/mapper/xxx" (using dmcrypt to "randomize")
would be faster. But, OTOH, I bet this method would open some
vulnerabilities (known-plaintext attacks).