public inbox for dm-crypt@saout.de
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Cc: arno@wagner.name
Subject: Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"
Date: Sat, 20 Jun 2020 08:10:31 +0200	[thread overview]
Message-ID: <20200620061031.GA13611@tansi.org> (raw)
In-Reply-To: <455a1ea8-550c-9259-3a6c-7a945b3b005e@gmx.de>

On Fri, Jun 19, 2020 at 22:45:51 CEST, d.eltzner@gmx.de wrote:
>    Hello there,
> 
>    first, thanks a lot for the exemplary FAQ and, I guess, for the great
>    software, although I must admit I have yet to actually use it.
> 
>    My entry point for learning about dm-crypt was the Arch Wiki and
>    sections like the one here -
>    [1]https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_s
>    ystem#LVM_on_LUKS
>    - seemed (to me) to suggest that having the (logical) root partition in
>    a LUKS container is at least no security risk in itself.
>    I actually also cannot think of a reason why it should be, but then
>    again my knowledge of all things crypto is negligible.
> 
>    So I was wondering about the following section *2.2 LUKS on partitions
>    or raw disks* of the FAQ:
> 
>    "(1) Encrypted partition: Just make a partition to your liking, and put
>    LUKS on top of it and a filesystem into the LUKS container. [...]
> 
>    Note that you cannot do this for encrypted root, that requires an
>    initrd. 

You can. You need to use the traditional set-up where the initrd
resides on a separate partition mounted under /boot.
Or put the initrd on an USB stick. Or some other place.

But I will add a comment to that effect, as it seems more
and more distros just place the initrd on the root partition.

>    On the other hand, an initrd is about as vulnerable to a
>    competent attacker as a non-encrypted root, so there really is no
>    security advantage to doing it that way. An attacker that wants to
>    compromise your system will just compromise the initrd or the kernel
>    itself."

I have a scenario: Put the initrd on USB-stick, remove it after
boot and secure the USB-stick physically (safe) when not in use.
I actually did that set-up for somebody. This is not perfect either, 
but makes attacks that rely on manipulating the disk directly a lot 
harder.

>    Obviously, it only states there is no advantage to it, but it made me
>    doubtful whether there was an actual disadvantage.
>    To me that's relevant since, as of now, encrypting my entire disk and
>    unlocking it at boot seemed to be the easiest setup.

But what do you use to unlock it? Something needs to run 
cryptsetup for that unlocking action.
 
>    Best Wishes, and apologies in advance for the probably somewhat silly
>    question,

Actually, thanks for the comment. Allows me to make the FAQ a bit 
clearer.

Regards,
Arno

>    Elso
> 
> References
> 
>    1. https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

  reply	other threads:[~2020-06-20  6:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 20:45 [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root" d.eltzner
2020-06-20  6:10 ` Arno Wagner [this message]
2020-06-20  9:07   ` d.eltzner
2020-06-20  9:46     ` Arno Wagner
2020-06-20 17:26       ` JT Morée
2020-06-20 23:53         ` Arno Wagner
2020-06-21 20:20           ` moreejt
2020-06-22  7:33             ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200620061031.GA13611@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox