[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encrypted root enhancement suggestion
Brad Brad wrote:
> Hi, does placing a seed into the initrg.gz file mean that the only
> way to read off this drive, is to boot off it? I ask because i'd
> like to make it necessary to boot the hard drive and possibly allow
> for the inclusion of "safty traps". There's nothing that can be
> done if the disk is simply mounted in another PC readonly.
You can extract seed from unbooted initrd.gz like this:
mount -t ext2 /dev/hda1 /mnt1 # your /boot partition
gzip -d -c /mnt1/initrd.gz >/mnt1/foo
mount -r -t minix /mnt1/foo /mnt2 -o loop=/dev/loop0
strings -a /mnt2/linuxrc | grep losetup
umount /mnt2
umount /mnt1
Or from booted initrd.gz like this:
strings -a /initrd/linuxrc | grep losetup
> The bootup password prompt could accept a few different passwords.
> If forced, the user gives up a "safety trap" password. This password
> appears to de-crypt fine so the user is off the hook, however this
> password has been setup to run a different bootup script. Possible
> implementations could allow mounting a crafted fake root, or perhaps
> simply running a "rm -rf" script. I think something like this would
> greatly improve the security of an encrypted hard drive solution.
gpgkey= mount option allows many users to mount, each using their own
personal key. build-initrd.sh supports GnuPG encrypted keyfiles just fine.
There is no support for 'alternative' filesystem. If there were such thing,
that could be detected by people who know what they are doing. One way of
doing it would be to create a compiled C program that execve()'s losetup
with -o NNNN if suppled password matches some known criteria. You would then
have 2 file systems on the partition, one with offset 0 and other with
offset NNNN. But that is just security through obscurity.
> Secondly, I'm not sure if the seed is easily recoverable from the
> initrd.gz, i imagine its probably plain (binary) text? Perhaps we
> could take the same approach as an ssh connection where an initial
> encrypted session is engaged before the real encrypted session is
> initiated.
Check gpgkey= mount option.
> At the moment i have an RC script that echo's my password to losetup,
> as long as my system is on its susceptible to unrelated rooting
> exploits that could expose my precious encryption password ( or
> private key )
Even if RC scripts are protected using root partition encryption, it is not
a requirement to setup other partitions in RC scripts. Setting them up is
just convenient as they can be fsck'd using normal RC scripts.
If an attacker roots your box, he can read any loop encryption key that is
set up at the time he has control of your box. Reading them from RC scripts
is easy. Reading them from kernel RAM is more difficult but doable.
Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/