Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo User (http://www.linux-archive.org/gentoo-user/)
-   -   dm-crypt + ext4 = where will the journal go? (http://www.linux-archive.org/gentoo-user/700257-dm-crypt-ext4-where-will-journal-go.html)

Florian Philipp 09-03-2012 08:40 PM

dm-crypt + ext4 = where will the journal go?
 
Am 03.09.2012 22:20, schrieb "Roland Häder":
> Hi all,
>
> I'm currently testing dm-crypt to encrypt my whole hard drive. So far
> I followed this [1] guide and have to wait for the randomization part
> of the hard drive.
>

You forgot the link to [1].

> In the wiki, ext4 is being used. Since ext3 a journal has been added.
> From my times with loop-aes I know that I have to store the journal
> through an encrypted loop device else it might be written on the hard
> drive.
>

Never used loop-aes myself. Sorry if I miss the reason for your
confusion because of it.

> As of I'm new to dm-crypt and Gentoo, where will that journal now
> go?
>

Opening a dmcrypt volume creates a mapped block device in /dev/mapper.
You treat it like a partition and format it with ext4. Unless you use
some exotic flags for mke2fs, the journal will be put on the same block
device and is encrypted along with the rest of it.

So: No need to worry about it.

Hope this helps,
Florian Philipp

Steve Buzonas 09-03-2012 08:51 PM

dm-crypt + ext4 = where will the journal go?
 
The journal is generally located on the partition in question. *If the partition is encrypted the journal should also be encrypted. *You can use `tune2fs -l` to list the contents of the partition's superblock which will have details on the partition such as journal location, etc...


On Mon, Sep 3, 2012 at 4:20 PM, "Roland Häder" <r.haeder@web.de> wrote:

Hi all,



I'm currently testing dm-crypt to encrypt my whole hard drive. So far I followed this [1] guide and have to wait for the randomization part of the hard drive.



In the wiki, ext4 is being used. Since ext3 a journal has been added. From my times with loop-aes I know that I have to store the journal through an encrypted loop device else it might be written on the hard drive.



As of I'm new to dm-crypt and Gentoo, where will that journal now go?



Any help is welcomed. :)



Regards,

* Roland





--
Sincerely,

Steve Buzonas Jr.

Florian Philipp 09-03-2012 08:52 PM

dm-crypt + ext4 = where will the journal go?
 
Am 03.09.2012 22:36, schrieb "Roland Häder":
> Opps, here is the missing link: http://wiki.gentoo.org/wiki/DM-Crypt
>
> (I don't think it is a good idea to store the keyFile somewhere
> plain, [2] tells that there is support for crypt-gnupg, but it
> doesn't show any help how to setup it.
>
> [2]: http://wiki.gentoo.org/wiki/Dracut
>

No comment on dracut as I have no experience with it.

However, as I see it, you need no key file if you just use a pass
phrase. In my opinion, a key file is only necessary for two improvements:

1. Two-factor authentication (read: encrypted key file)

2. Avoiding re-typing the pass phrase for multiple dmcrypt partitions

You can easily achieve the second point by putting an unencrypted key
file on the first partition which you encrypt with a pass phrase. You
don't even need dracut for this, /etc/conf.d/dmcrypt lets you configure
it easily (as long as it doesn't affect /usr).

However, I personally find it easier to put LVM on a single dmcrypt
volume and be done this. All you need for this to work are two lines in
/etc/rc.conf:
rc_dmcrypt_before="lvm"
rc_dmcrypt_after="udev"

Regards,
Florian Philipp

Alan McKinnon 09-04-2012 03:14 PM

dm-crypt + ext4 = where will the journal go?
 
On Tue, 04 Sep 2012 09:15:31 -0500
Dale <rdalek1967@gmail.com> wrote:

> I think the new method for determining swap is to use what makes sense
> and not the old rule of 'twice the ram'.

Alan's new rule of swap is:

If you ever use swap as swap at all, find out how your machine is
misconfigured. When my 16G is "not enough" anymore, something is badly
wrong and it isn't not enough RAM and I need swap to wiggle around
in :-)

I think the 2 x RAM rule stopped being applicable when the average
machine got to more than 16M. Some old memes are like zombies - very
hard to kill.

This laptop has a "swap" partition, but it's not for swap, it's for
hibernate. And I never use it, it takes longer to come out of hibernate
than to just boot up from cold! These days I just suspend.

None of this changes the fact that the kernel still does get upset when
it has no swap at all (even just a little bit). But that doesn't mean
we should still be using it as full-blown swap.



--
Alan McKinnon
alan.mckinnon@gmail.com

Dale 09-04-2012 03:53 PM

dm-crypt + ext4 = where will the journal go?
 
Alan McKinnon wrote:
> On Tue, 04 Sep 2012 09:15:31 -0500
> Dale <rdalek1967@gmail.com> wrote:
>
>> I think the new method for determining swap is to use what makes sense
>> and not the old rule of 'twice the ram'.
> Alan's new rule of swap is:
>
> If you ever use swap as swap at all, find out how your machine is
> misconfigured. When my 16G is "not enough" anymore, something is badly
> wrong and it isn't not enough RAM and I need swap to wiggle around
> in :-)
>
> I think the 2 x RAM rule stopped being applicable when the average
> machine got to more than 16M. Some old memes are like zombies - very
> hard to kill.
>
> This laptop has a "swap" partition, but it's not for swap, it's for
> hibernate. And I never use it, it takes longer to come out of hibernate
> than to just boot up from cold! These days I just suspend.
>
> None of this changes the fact that the kernel still does get upset when
> it has no swap at all (even just a little bit). But that doesn't mean
> we should still be using it as full-blown swap.
>
>
>


Yup. I have swap but I have it set to where it won't use it unless it
is REALLY bad. I have swappiness set to like 20 or something. It will
fill up my ram with cache and such but it rarely uses more than a few
hundred kilobytes of swap. When I see it using that, I usually kill
swap and add it back. I just don't like a machine with 16Gbs of ram
using swap at all. I have thought about setting it to 10. Maybe then
it will leave it alone until it really hits the fan. ;-)

That said, I did roll over one night and notice that the CPU was going
ape. I got up and into my chair to notice it was using almost all the
ram and was starting to use a bit of swap. I switched to a console, ran
htop and noticed that some KDE process was using about ~15.5Gbs of ram.
It was crazy to see. I couldn't get it to die with kill -15 so I did a
kill -9. I guess it had to know I really wanted it dead. It has not
happened since so no clue on why it did that. Heck, it ran the same
version of KDE for a good while and still didn't do it. Cosmic rays
from Mars I guess.

I would recommend at least 500Mbs or so of swap regardless of ram tho.
Some swap is a good idea. Just try not to use it since it is dog slow.
If you are using hibernate/suspend thingys then that is different.
Isn't that when it has to be at least as much swap as you have ram?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Michael Mol 09-04-2012 04:10 PM

dm-crypt + ext4 = where will the journal go?
 
On Tue, Sep 4, 2012 at 11:53 AM, Dale <rdalek1967@gmail.com> wrote:
> Alan McKinnon wrote:
>> On Tue, 04 Sep 2012 09:15:31 -0500
>> Dale <rdalek1967@gmail.com> wrote:
>>
>>> I think the new method for determining swap is to use what makes sense
>>> and not the old rule of 'twice the ram'.
>> Alan's new rule of swap is:
>>
>> If you ever use swap as swap at all, find out how your machine is
>> misconfigured. When my 16G is "not enough" anymore, something is badly
>> wrong and it isn't not enough RAM and I need swap to wiggle around
>> in :-)
>>
>> I think the 2 x RAM rule stopped being applicable when the average
>> machine got to more than 16M. Some old memes are like zombies - very
>> hard to kill.
>>
>> This laptop has a "swap" partition, but it's not for swap, it's for
>> hibernate. And I never use it, it takes longer to come out of hibernate
>> than to just boot up from cold! These days I just suspend.
>>
>> None of this changes the fact that the kernel still does get upset when
>> it has no swap at all (even just a little bit). But that doesn't mean
>> we should still be using it as full-blown swap.
>>
>>
>>
>
>
> Yup. I have swap but I have it set to where it won't use it unless it
> is REALLY bad. I have swappiness set to like 20 or something. It will
> fill up my ram with cache and such but it rarely uses more than a few
> hundred kilobytes of swap. When I see it using that, I usually kill
> swap and add it back. I just don't like a machine with 16Gbs of ram
> using swap at all. I have thought about setting it to 10. Maybe then
> it will leave it alone until it really hits the fan. ;-)

Set swappiness to 0. Swap will be used if and only if absolutely necessary.

Also, you're unlikely to notice a performance hit if the amount of
data in swap is only a few tens of megabytes; the seek-and-read rate
of even spinning platter disks should tend to cause that bit of
latency to get lost in the normal noise of library linkage, data file
loading, etc. (heck, it might even still be in the drive cache) The
performance hit is there, but probably not subjectively noticeable.

>
> That said, I did roll over one night and notice that the CPU was going
> ape. I got up and into my chair to notice it was using almost all the
> ram and was starting to use a bit of swap. I switched to a console, ran
> htop and noticed that some KDE process was using about ~15.5Gbs of ram.
> It was crazy to see. I couldn't get it to die with kill -15 so I did a
> kill -9. I guess it had to know I really wanted it dead. It has not
> happened since so no clue on why it did that. Heck, it ran the same
> version of KDE for a good while and still didn't do it. Cosmic rays
> from Mars I guess.
>
> I would recommend at least 500Mbs or so of swap regardless of ram tho.
> Some swap is a good idea. Just try not to use it since it is dog slow.

Indeed.

> If you are using hibernate/suspend thingys then that is different.
> Isn't that when it has to be at least as much swap as you have ram?

Yes.

--
:wq

Florian Philipp 09-04-2012 06:18 PM

dm-crypt + ext4 = where will the journal go?
 
Am 04.09.2012 19:37, schrieb Hinnerk van Bruinehsen:
> On 04.09.2012 15:48, "Roland Häder" wrote:
>> I think I made a (tollerateable) mistake:
>
>> My hard drive has two partitions: - sda1 - encrypted swap - sda2 -
>> encrypted root
>
>> How should it boot? One way could be by external media (e.g.
>> stick), other is from hard drive. But that is encrypted. So I must
>> leave a small area left for kernel, initrd, System.map and maybe
>> config.
>
>> So the page at [1] is a little wrong because it misses the boot
>> partition, so the new layout should be: - sda1 - unencrypted boot
>> (/boot) partition - sda2 - encrypted swap (at least as double as
>> your RAM) (crypt-swap) - sda3 - encrypted root (crypt-root)
>
>> Can someone update this?
>
>> Regards, Roland
>
>> [1]: http://wiki.gentoo.org/wiki/DM-Crypt
>
>
> In theory grub2 is able to open a luks-encrypted volume though it
> seems to have some disadvantages: you'll need to enter the passphrase
> (or pass the keyfile) two times, because grub itself needs to decrypt
> the volume to get the later stages from the encrypted volume and
> afterwards the decryption in the bootprocess itself takes place.
>
> I can't give any real advice about it though, because I use an
> unencrypted boot partition. Depending on your needs it could be an
> increase of security, because you can stop an attacker from injecting
> malicious code into your kernel (or replace it completely).
>
> WKR
> Hinnerk


For personal use, I see no point in using an encrypted boot partition.
An attacker needs physical or root access to change the kernel or initrd
in order to get to your encrypted data. In both cases, you are hosed
anyway (keyloggers, etc.).

Encrypting everything except the boot partition still protects you
against theft, seizure and so on (as long as you sanitize the device
when you get it back). Secure Boot would help further but let's not
re-iterate that particular flame/FUD war.

Regards,
Florian Philipp

Michael Mol 09-04-2012 06:27 PM

dm-crypt + ext4 = where will the journal go?
 
On Tue, Sep 4, 2012 at 2:18 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 04.09.2012 19:37, schrieb Hinnerk van Bruinehsen:
>> On 04.09.2012 15:48, "Roland Häder" wrote:
>>> I think I made a (tollerateable) mistake:
>>
>>> My hard drive has two partitions: - sda1 - encrypted swap - sda2 -
>>> encrypted root
>>
>>> How should it boot? One way could be by external media (e.g.
>>> stick), other is from hard drive. But that is encrypted. So I must
>>> leave a small area left for kernel, initrd, System.map and maybe
>>> config.
>>
>>> So the page at [1] is a little wrong because it misses the boot
>>> partition, so the new layout should be: - sda1 - unencrypted boot
>>> (/boot) partition - sda2 - encrypted swap (at least as double as
>>> your RAM) (crypt-swap) - sda3 - encrypted root (crypt-root)
>>
>>> Can someone update this?
>>
>>> Regards, Roland
>>
>>> [1]: http://wiki.gentoo.org/wiki/DM-Crypt
>>
>>
>> In theory grub2 is able to open a luks-encrypted volume though it
>> seems to have some disadvantages: you'll need to enter the passphrase
>> (or pass the keyfile) two times, because grub itself needs to decrypt
>> the volume to get the later stages from the encrypted volume and
>> afterwards the decryption in the bootprocess itself takes place.
>>
>> I can't give any real advice about it though, because I use an
>> unencrypted boot partition. Depending on your needs it could be an
>> increase of security, because you can stop an attacker from injecting
>> malicious code into your kernel (or replace it completely).
>>
>> WKR
>> Hinnerk
>
>
> For personal use, I see no point in using an encrypted boot partition.
> An attacker needs physical or root access to change the kernel or initrd
> in order to get to your encrypted data. In both cases, you are hosed
> anyway (keyloggers, etc.).

Now you've got me pondering cryptographically-verified input devices.
But perhaps a paired USB key fob with a challenge/response setup would
be reasonable.


--
:wq

Florian Philipp 09-04-2012 06:33 PM

dm-crypt + ext4 = where will the journal go?
 
Am 04.09.2012 00:12, schrieb "Roland Häder":
> Okay, I have made a little progress. I have generated my private key
> using some random data + gpg:
>
> # head -c 3705 /dev/urandom | head -n 66 | tail -n 65 > key.out # gpg
> --symmetric -a --s2k-count 8388608 key.out <Enter your password
> twice> # mv key.out.asc key.gpg # rm -f key.out
>

Two minor suggestions:

1. Maybe it would be a good idea to use an ASCII-only random string, for
example by piping it through `base64 -w 0`. That way you don't loose any
entropy (the key just gets longer) but it is easier to type the keyfile
manually, in case you ever need to. You also don't have to worry about
odd behavior of password prompts anymore.

2. You should `shred` key.out instead of `rm`.

> Now I have to copy that file on my stick and setup
> /etc/conf.d/dmcrypt:
>
> # whole root system encrypted with gpg key from removeable media
> target=crypt-root source='/dev/hdaX' key='/key:gpg' # This is your
> stick remdev='/dev/sda1'
>
> But what next? The example at [1] is based on key-only file (no
> passphrase). I know, later on /etc/conf.d/dmcrypt must be placed on
> the new root-fs but what now? I still have to setup it. cryptsetup
> doesn't do anything with gpg. So I have setup a pipeline?
>

I'm not entirely sure I understand what you mean, therefore I just start
babbling. ;-)

The dmcrypt init script cannot be used for encrypting the root fs, a
separate /usr or /etc. At least, I don't see a way to do it and I don't
see it in the examples in my /etc/conf.d/dmcrypt.

However, you can use it for all other directories containing sensitive
data (/home, /srv, /var, /tmp). You might still need a skeleton
directory structure of /var for the early boot stages but that's about it.

Getting root encrypted is the sole responsibility of your initrd.

Regards,
Florian Philipp

Florian Philipp 09-04-2012 06:59 PM

dm-crypt + ext4 = where will the journal go?
 
Am 03.09.2012 23:23, schrieb "Roland Häder":
>
>> No comment on dracut as I have no experience with it.
> Okay, so I have to try it out myself. When I found something out, I
> expand the wiki with it.
>
>>
>> However, as I see it, you need no key file if you just use a pass
>> phrase. In my opinion, a key file is only necessary for two
>> improvements:
> Entering just a pass phrase means that this pass phrase will be used
> to decrypt the device, if you decrypt a key before and then with that
> key decrypt all your volumes you have a much better security because
> that key will then be used as 'pass phrase' which is *way* much
> stronger (4096+ chars + ~10-20 chars you can remember).
>

That's not exactly how it works.

1. An attacker could still simply break the pass phrase used to encrypt
the key file.

2. You don't actually weaken the encryption of your disk if you use a
small key (besides the obviously easier guessing of the key). The actual
encryption key is generated from the pass phrase (or key file) by a hash
function (default: SHA-1). This always expands or compresses your key to
the key size defined when issuing `cryptsetup luksFormat`.

>>
>> 1. Two-factor authentication (read: encrypted key file)
>>

This is what makes a key file better and more secure. The attacker not
only needs a pass phrase /or/ a memory stick; he needs both.

>> 2. Avoiding re-typing the pass phrase for multiple dmcrypt
>> partitions
> See above. :)
>
>> You can easily achieve the second point by putting an unencrypted
>> key file on the first partition which you encrypt with a pass
>> phrase. You don't even need dracut for this, /etc/conf.d/dmcrypt
>> lets you configure it easily (as long as it doesn't affect /usr).
> Okay, I look into this.
>
>>
>> However, I personally find it easier to put LVM on a single
>> dmcrypt volume and be done this. All you need for this to work are
>> two lines in /etc/rc.conf: rc_dmcrypt_before="lvm"
>> rc_dmcrypt_after="udev"
> I'm new to LVM, does it setup key-based encryption (best is to put
> that key on an USB stick, so the attacker needs my stick).
>
> Regards, Roland
>


I guess I didn't make myself clear. Mostly because I didn't want to
write a whole article on it before someone actually showed interest in
this. Anyway:

LVM has nothing to do with the encryption. It is just a way to partition
a single dmcrypt partition into more devices. Maybe it gets clearer if I
show my partitioning scheme (shortened a bit and with some artistic
liberties):

/dev/sda1 # /boot
/dev/sda2 # root + /usr + /etc
/dev/sda3 -> /dev/mapper/crypt # dmcrypt partition
/dev/mapper/crypt -> vg_notebook # LVM volume group on dmcrypt
vg_noteboot -> /dev/mapper/vg_notebook-var # /var
vg_noteboot -> /dev/mapper/vg_notebook-home # /home
vg_noteboot -> /dev/mapper/vg_notebook-swap # swap
vg_noteboot -> /dev/mapper/vg_notebook-opt # /opt
vg_noteboot -> /dev/mapper/vg_notebook-usr-local # /usr/local


You see, it is just an alternative to different approaches on getting
several parts of your file system encrypted without having to enter pass
phrases for several dmcrypt partitions. Alternatives are

1. Put an unencrypted key file on the first encrypted partition.
2. Use a single file system on a single dmcrypt partition and then
`mount --bind` or `ln -s` parts of it in different places.

For me personally, it is a nice compromise as it allows me to work
without an initrd while still keeping most of my file systems encrypted.
I just have to make sure to leave nothing private on root, /usr or /etc.

Regards,
Florian Philipp


All times are GMT. The time now is 07:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.