I've read the warning in /etc/conf.d/cryptfs about /usr on a separate
partition and followed their advice.
However, the setup doesn't work. I'm not asked for the passphrase, the
mappings are not created. What did I forget?
Thanks in advance!
Florian Philipp
03-30-2008, 07:50 AM
"Dirk Heinrichs"
Cryptfs
Am Samstag, 29. März 2008 schrieb Florian Philipp:
> My goal is to open a Luks-mapping for /var with a gpg-encrypted file
> on /boot and then open a mapping for /var/tmp with a plaintext file
> on /var.
See below. But while we're at it, can anybody tell me what's the advantage of
a gpg-encrypted keyfile over a keyfile generated from /dev/urandom?
> I thought it would work with the following settings:
>
> /etc/conf.d/cryptfs
It's /etc/conf.d/dmcrypt nowadays.
> target=var
> source='/dev/mapper/vg-crypt_var'
> key='/boot/key.gpg:gpg'
>
> target=var_tmp
> source='/dev/mapper/vg-crypt_var_tmp'
> key='/var/lib/tmp_key'
>
>
> I've read the warning in /etc/conf.d/cryptfs about /usr on a separate
> partition and followed their advice.
Which warning, btw.? Works just fine here.
> However, the setup doesn't work. I'm not asked for the passphrase, the
> mappings are not created. What did I forget?
That the mappings are created all in one go before anything is mounted, so you
can't put the keyfile for /var into /boot. The only thing that would work is
to put the keyfile on the root fs, because that's the only one that is
mounted when the mappings are created, like:
On Sun, 2008-03-30 at 09:50 +0200, Dirk Heinrichs wrote:
> Am Samstag, 29. März 2008 schrieb Florian Philipp:
>
> > My goal is to open a Luks-mapping for /var with a gpg-encrypted file
> > on /boot and then open a mapping for /var/tmp with a plaintext file
> > on /var.
>
> See below. But while we're at it, can anybody tell me what's the advantage of
> a gpg-encrypted keyfile over a keyfile generated from /dev/urandom?
Keys for urandom work great for /tmp and swap but how should I use this
for a partition which is supposed to keep its content between reboots?
>
> > I thought it would work with the following settings:
> >
> > /etc/conf.d/cryptfs
>
> It's /etc/conf.d/dmcrypt nowadays.
Interesting, why is there no hint that cryptfs is deprecated/obsolete?
>
> > target=var
> > source='/dev/mapper/vg-crypt_var'
> > key='/boot/key.gpg:gpg'
> >
> > target=var_tmp
> > source='/dev/mapper/vg-crypt_var_tmp'
> > key='/var/lib/tmp_key'
> >
> >
> > I've read the warning in /etc/conf.d/cryptfs about /usr on a separate
> > partition and followed their advice.
>
> Which warning, btw.? Works just fine here.
>
"# Note when using gpg keys and /usr on a separate partition, you will
# have to copy /usr/bin/gpg to /bin/gpg so that it will work properly
# and ensure that gpg has been compiled statically.
# See http://bugs.gentoo.org/90482 for more information."
> > However, the setup doesn't work. I'm not asked for the passphrase, the
> > mappings are not created. What did I forget?
>
> That the mappings are created all in one go before anything is mounted, so you
> can't put the keyfile for /var into /boot. The only thing that would work is
> to put the keyfile on the root fs, because that's the only one that is
> mounted when the mappings are created, like:
>
> target='c-usr'
> source='/dev/evms/usr'
> key='/etc/crypt/keyfile'
>
> Bye...
>
> Dirk
Thanks, I'll try it.
03-30-2008, 11:24 AM
"Dirk Heinrichs"
Cryptfs
Am Sonntag, 30. März 2008 schrieb Florian Philipp:
> On Sun, 2008-03-30 at 09:50 +0200, Dirk Heinrichs wrote:
> > Am Samstag, 29. März 2008 schrieb Florian Philipp:
> > > My goal is to open a Luks-mapping for /var with a gpg-encrypted file
> > > on /boot and then open a mapping for /var/tmp with a plaintext file
> > > on /var.
> >
> > See below. But while we're at it, can anybody tell me what's the
> > advantage of a gpg-encrypted keyfile over a keyfile generated from
> > /dev/urandom?
>
> Keys for urandom work great for /tmp and swap but how should I use this
> for a partition which is supposed to keep its content between reboots?
See my example below.
> > Which warning, btw.? Works just fine here.
>
> "# Note when using gpg keys and /usr on a separate partition, you will
> # have to copy /usr/bin/gpg to /bin/gpg so that it will work properly
> # and ensure that gpg has been compiled statically.
> # See http://bugs.gentoo.org/90482 for more information."
Ah, I see. Since I don't use gpg it doesn't matter to me.
On Sun, 30 Mar 2008 09:50:47 +0200, Dirk Heinrichs wrote:
> > However, the setup doesn't work. I'm not asked for the passphrase, the
> > mappings are not created. What did I forget?
>
> That the mappings are created all in one go before anything is mounted,
> so you can't put the keyfile for /var into /boot. The only thing that
> would work is to put the keyfile on the root fs, because that's the
> only one that is mounted when the mappings are created, like:
You can if you add
pre_mount="mount /dev/mapper/boot /boot"
to the boot stanza of dmcrypt, it forces the filesystem to be mounted
immediately.
I ue a variant of this, where keys are stored on a dedicated partition.
The pre_mount and post_mount (which unmounts the filesystem) ensure that
the keys are only visible for as long as it takes to mount the other
filesystems.
--
Neil Bothwick
Thesaurus: ancient reptile with an excellent vocabulary
03-30-2008, 04:50 PM
"Dirk Heinrichs"
Cryptfs
Am Sonntag, 30. März 2008 schrieb Neil Bothwick:
> On Sun, 30 Mar 2008 09:50:47 +0200, Dirk Heinrichs wrote:
> > > However, the setup doesn't work. I'm not asked for the passphrase, the
> > > mappings are not created. What did I forget?
> >
> > That the mappings are created all in one go before anything is mounted,
> > so you can't put the keyfile for /var into /boot. The only thing that
> > would work is to put the keyfile on the root fs, because that's the
> > only one that is mounted when the mappings are created, like:
>
> You can if you add
>
> pre_mount="mount /dev/mapper/boot /boot"
>
> to the boot stanza of dmcrypt, it forces the filesystem to be mounted
> immediately.
>
> I ue a variant of this, where keys are stored on a dedicated partition.
> The pre_mount and post_mount (which unmounts the filesystem) ensure that
> the keys are only visible for as long as it takes to mount the other
> filesystems.
I protect the root fs with a passphrase and all other volumes with a keyfile
stored in this fs. No need to mount anything (however, I _do_ need an
initramfs because of this).
Bye...
Dirk
03-30-2008, 08:13 PM
Neil Bothwick
Cryptfs
On Sun, 30 Mar 2008 18:50:59 +0200, Dirk Heinrichs wrote:
> > I use a variant of this, where keys are stored on a dedicated
> > partition. The pre_mount and post_mount (which unmounts the
> > filesystem) ensure that the keys are only visible for as long as it
> > takes to mount the other filesystems.
>
> I protect the root fs with a passphrase and all other volumes with a
> keyfile stored in this fs. No need to mount anything (however, I _do_
> need an initramfs because of this).
That still means your keys are readable all the time, whereas mine
disappear long before the network comes up.
--
Neil Bothwick
Remember, it takes 47 muscles to frown
And only 4 to pull the trigger of a sniper rifle....
03-31-2008, 06:36 AM
Dirk Heinrichs
Cryptfs
Am Sonntag, 30. März 2008 schrieb ext Neil Bothwick:
> On Sun, 30 Mar 2008 18:50:59 +0200, Dirk Heinrichs wrote:
> > I protect the root fs with a passphrase and all other volumes with a
> > keyfile stored in this fs. No need to mount anything (however, I _do_
> > need an initramfs because of this).
>
> That still means your keys are readable all the time,
By root only, chmod 400 is your friend.
> whereas mine
> disappear long before the network comes up.
So what? If somebody cracks into your box and gains root access, he can't
mount /boot and take the keys? You'll need SELinux to prevent this.
On Mon, 31 Mar 2008 07:36:52 +0100, Dirk Heinrichs wrote:
> > That still means your keys are readable all the time,
>
> By root only, chmod 400 is your friend.
But still readable.
>
> > whereas mine
> > disappear long before the network comes up.
>
> So what? If somebody cracks into your box and gains root access, he
> can't mount /boot and take the keys?
That's right, because the keys aren't in /boot ;-)
--
Neil Bothwick
WITLAG: The delay between delivery and comprehension of a joke.
03-31-2008, 04:15 PM
"Dirk Heinrichs"
Cryptfs
Neil Bothwick schrieb:
> On Mon, 31 Mar 2008 07:36:52 +0100, Dirk Heinrichs wrote:
>
>>> That still means your keys are readable all the time,
>> By root only, chmod 400 is your friend.
>
> But still readable.
>>> whereas mine
>>> disappear long before the network comes up.
>> So what? If somebody cracks into your box and gains root access, he
>> can't mount /boot and take the keys?
>
> That's right, because the keys aren't in /boot ;-)
But they are somewhere. He who has cracked your box can simply look into
/etc/conf.d/dmcrypt to find out where your keyfile is stored and mount
that fs if needed. There's no difference in storing them on the root fs
directly, it will take the cracker just a few seconds longer to get it.
But hey, this answers my question about the sense of using gpg encrypted
keyfiles. :-)
Other possible solution is to put the keyfile(s) on an USB stick and
unplug this right after booting. I doubt I would always remember to do
so :-)
Cryptfs
