[dm-crypt] type one password, get many

[dm-crypt] type one password, get many

[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

Re: [dm-crypt] type one password, get many

[Ross Boylan]

On Fri, 2009-08-14 at 10:19 -0700, Ross Boylan wrote:
> 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
> 
> 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
> 

Re: [dm-crypt] type one password, get many

[Ross Boylan]

On Fri, 2009-08-14 at 12:09 -0700, Ross Boylan wrote:
> 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
> 
> 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).

Re: [dm-crypt] type one password, get many

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

hello,

On 14/08/2009 Ross Boylan wrote:
> On Fri, 2009-08-14 at 10:19 -0700, Ross Boylan wrote:
> > 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).

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [dm-crypt] type one password, get many

[Ross Boylan]

On Sun, 2009-08-16 at 21:44 +0200, Jonas Meurer wrote:
> 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

Re: [dm-crypt] type one password, get many

[Moji]

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

Ross Boylan wrote:
> On Sun, 2009-08-16 at 21:44 +0200, Jonas Meurer wrote:
>> 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
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] type one password, get many

[Jonas Meurer]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On 16/08/2009 Ross Boylan wrote:
> On Sun, 2009-08-16 at 21:44 +0200, Jonas Meurer wrote:
> > 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)?

yes, it should work exactly the way you described it.

> 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.

> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [dm-crypt] type one password, get many

[Moji]

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 $?

Ross Boylan wrote:
> > 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
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >



Ross Boylan wrote:
> 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
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>