type one password, get many
Someone referred recently to a scenario in which a human would type in the password for the root partition, and then the passwords for the other partitions would come from a file in /etc.
Could anyone provide some more details about how that would work, and whether it is advisable? Clearly someone with access to the live system could get the passwords for all but root, and someone who, e.g., stole the disk, would only need to crach one password. I think those limits would be acceptable to me; are there others?
It is useful for me to have quite a few partitions (I've just discovered I need more so I can control mount options better), and typing in a whole bunch of passwords on boot is pretty tedious.
Thanks.
Ross Boylan
Quoted 9 lines · Ross Boylan
Someone referred recently to a scenario in which a human would type in the password for the root partition, and then the passwords for the other partitions would come from a file in /etc.
Could anyone provide some more details about how that would work, and whether it is advisable? Clearly someone with access to the live system could get the passwords for all but root, and someone who, e.g., stole the disk, would only need to crach one password. I think those limits would be acceptable to me; are there others?
I think unless I'm careful I'll end up with an unencrypted initrd that includes file with the passwords. So I need either to make the boot partition the one with the user-entered password, or eliminate the file(s) with the secrets from the initrd.
Debian has a file /etc/cryptab that supports automounting, but I'll have to dig around to see how this interacts with the initrd framework (I'm running Lenny).
Moji, thanks for the example.
Ross
Quoted 8 lines
It is useful for me to have quite a few partitions (I've just discovered I need more so I can control mount options better), and typing in a whole bunch of passwords on boot is pretty tedious.
Thanks.
Ross Boylan
Quoted 4 lines · Ross Boylan
I think unless I'm careful I'll end up with an unencrypted initrd that includes file with the passwords. So I need either to make the boot partition the one with the user-entered password, or eliminate the file(s) with the secrets from the initrd.
By inspection, the initrd image does not have crypttab, or even fstab. I can't find any explicit documentation of this, but the behavior seems to be to copy only selected files.
So that's good--nothing sensitive in the initrd.
Not so good is that my root partition is not encrypted. I think I thought this would making booting easier and more robust, but I'm not sure that's really so. /boot is on a separate physical partition (no encryption, RAID, or lvm needed), and that's probably all I need. I'm using grub.
Ross
Quoted 5 lines
Debian has a file
/etc/cryptabthat supports automounting, but I'll have
to dig around to see how this interacts with the initrd framework (I'm running Lenny).
hello,
Quoted 10 lines · On 14/08/2009 Ross Boylan wrote:
Quoted 9 lines · Ross Boylan
Someone referred recently to a scenario in which a human would type in the password for the root partition, and then the passwords for the other partitions would come from a file in /etc.
Could anyone provide some more details about how that would work, and whether it is advisable? Clearly someone with access to the live system could get the passwords for all but root, and someone who, e.g., stole the disk, would only need to crach one password. I think those limits would be acceptable to me; are there others?
Quoted 8 lines
I think unless I'm careful I'll end up with an unencrypted initrd that includes file with the passwords. So I need either to make the boot partition the one with the user-entered password, or eliminate the file(s) with the secrets from the initrd.
Debian has a file
/etc/cryptabthat supports automounting, but I'll have to dig around to see how this interacts with the initrd framework (I'm running Lenny).
neither crypt keys nor passwords are stored in the initramfs. you don't even need cryptsetup magic in the initramfs for encrypted non-root partitions. the only partition that needs to be decrypted within the initramfs is the root partition.
all other partitions are decrypted later in the boot process, when the root filesystem is already mounted. thus storing the keyfiles for encrypted user filesystems on the root filesystem works well.
greetings,
jonas
Quoted 5 lines · Jonas Meurer
neither crypt keys nor passwords are stored in the initramfs. you don't
even need cryptsetup magic in the initramfs for encrypted non-root partitions. the only partition that needs to be decrypted within the initramfs is the root partition.
If I have a LUKS encrypted root partition, will things just work? I.e., when the initrd pivots, will I get a request for the passphrase of the root partition and then it will proceed to boot as normal (and read keys from /etc/cryptab to mount the other partitions)?
If I need to do more, some pointers would be great.
It would be LUKS on top of LVM on top of software RAID.
I believe to convert my to encrypted I'd need to make a new LVM volume, create an encrypted device on top of it, and copy. Is there an easier way?
Thanks.
Ross
I do not know if this is easier, but it has come up recently in discussions over the strength of large volumes using the same key. You might consider making the encrypted device on the partition, and then creating LVM over a set of encrypted devices.
I have a luks encrypted root partition, and for a long time it has worked very well. I enter my password at boot and everything runs very smoothly.
-MJ
Quoted 27 lines · Ross Boylan
Quoted 5 lines · Jonas Meurer
neither crypt keys nor passwords are stored in the initramfs. you don't
even need cryptsetup magic in the initramfs for encrypted non-root partitions. the only partition that needs to be decrypted within the initramfs is the root partition.If I have a LUKS encrypted root partition, will things just work? I.e., when the initrd pivots, will I get a request for the passphrase of the root partition and then it will proceed to boot as normal (and read keys from
/etc/cryptabto mount the other partitions)?If I need to do more, some pointers would be great.
It would be LUKS on top of LVM on top of software RAID.
I believe to convert my to encrypted I'd need to make a new LVM volume, create an encrypted device on top of it, and copy. Is there an easier way?
Thanks.
Ross_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 11 lines · On 16/08/2009 Ross Boylan wrote:
Quoted 5 lines · Jonas Meurer
neither crypt keys nor passwords are stored in the initramfs. you don't
even need cryptsetup magic in the initramfs for encrypted non-root partitions. the only partition that needs to be decrypted within the initramfs is the root partition.If I have a LUKS encrypted root partition, will things just work? I.e., when the initrd pivots, will I get a request for the passphrase of the root partition and then it will proceed to boot as normal (and read keys from
/etc/cryptabto mount the other partitions)?
yes, it should work exactly the way you described it.
Quoted 1 line
It would be LUKS on top of LVM on top of software RAID.
i didn't test such a setup myself yet, but at least luks on top of lvm works without any problems.
Quoted 3 lines
I believe to convert my to encrypted I'd need to make a new LVM volume, create an encrypted device on top of it, and copy. Is there an easier way?
i would not encrypt the partition on-the-fly for security reasons, so yes the best way is to copy data from the unencrypted filesystem into a new, encrypted one.
greetings,
jonas
My apologizes to Christophe for sending this to the bounce address, I have recently changed my email client and I am still getting my settings how I want them.
Ross,
I have a setup like that where my root partition contains a /etc/crypt file where I keep keys.
After my root partition is decrypted I use the keys in my /etc/crypt folder to decrypt my home partition. Although you could have it do as many partitions as you wanted.
I do this in the same part of the init processes that I activate my swap.
I do this mainly because I like having my home directory separate from my root partition and I don't want to have to enter two passwords in at once.
The key I use is 1MB generated from /dev/random, it takes awhile to generate the key but if you want I can send you the really simple script I use to generate them.
As I use luks I have my password on my home directory in the second slot, in case my root partition ever became corrupted and I didn't have access to the key.
Here is the relevant part of my /etc/init.d/localmount, I kept the swap activation part in just for reference of where I placed the code:
ebegin "Activating encrypted swap"
#added to enable encrypted swap
unset open_loop_dev
open_loop_dev="$(/sbin/losetup -f)"/sbin/losetup "${open_loop_dev}" /swap.lpb &> /dev/null /sbin/cryptsetup -c aes-xts-essiv:sha256 -s 512 -h sha512 -d dev/urandom create swap "${open_loop_dev}" &> /dev/null/sbin/mkswap /dev/mapper/swap &> /dev/null/sbin/swapon -a &> /dev/null
unset open_loop_dev
eend $?
#added to enable encrypted home
ebegin "Mounting encrypted home directory"/sbin/cryptsetup luksOpen /dev/sda4 home --key-file /etc/crypt/home.key &> /dev/null/bin/mount /dev/mapper/home /home &> /dev/null
#added to make sure if there is a crash jfs will recover
if [ -z "$(/bin/mount | grep /dev/mapper/home 2> /dev/null )" ]; then /sbin/fsck.jfs /dev/mapper/home/bin/mount /dev/mapper/home /home &> /dev/null
fi
if [ -z "$(/bin/mount | grep /dev/mapper/home 2> /dev/null )" ]; then /sbin/fsck.jfs -afv /dev/mapper/home/bin/mount /dev/mapper/home /home &> /dev/null
fi
eend $?
Quoted 22 lines · Ross Boylan
Quoted 22 lines
Someone referred recently to a scenario in which a human would type in the password for the root partition, and then the passwords for the other partitions would come from a file in /etc.
Could anyone provide some more details about how that would work, and whether it is advisable? Clearly someone with access to the live system could get the passwords for all but root, and someone who, e.g., stole the disk, would only need to crach one password. I think those limits would be acceptable to me; are there others?
It is useful for me to have quite a few partitions (I've just discovered I need more so I can control mount options better), and typing in a whole bunch of passwords on boot is pretty tedious.
Thanks.
Ross Boylan_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 22 lines · Ross Boylan
Someone referred recently to a scenario in which a human would type in the password for the root partition, and then the passwords for the other partitions would come from a file in /etc.
Could anyone provide some more details about how that would work, and whether it is advisable? Clearly someone with access to the live system could get the passwords for all but root, and someone who, e.g., stole the disk, would only need to crach one password. I think those limits would be acceptable to me; are there others?
It is useful for me to have quite a few partitions (I've just discovered I need more so I can control mount options better), and typing in a whole bunch of passwords on boot is pretty tedious.
Thanks.
Ross Boylan_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt