All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.