[dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[d.eltzner]

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

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 -
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#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. 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."

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.

Best Wishes, and apologies in advance for the probably somewhat silly
question,
Elso


[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[Arno Wagner]

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

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[d.eltzner]

Thanks a lot for the clarification!

On 20.06.20 08:10, Arno Wagner wrote:
> 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.
You mean because the initrd is somewhat safe from manipulation in this
scenario? Wouldn't you have to do the same for the kernel then?

> But what do you use to unlock it? Something needs to run 
> cryptsetup for that unlocking action.

The Arch way seems to be to do this via the initrd which in a "default"
setup resides on a dedicated /boot. I figure that might be good enough
for me then.

Best Wishes

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[Arno Wagner]

On Sat, Jun 20, 2020 at 11:07:32 CEST, d.eltzner@gmx.de wrote:
> Thanks a lot for the clarification!
> 
> On 20.06.20 08:10, Arno Wagner wrote:
> > 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.
> You mean because the initrd is somewhat safe from manipulation in this
> scenario? Wouldn't you have to do the same for the kernel then?

Yes. The kernel also goes on that stick. Grub does too, if it is
used for booting.
 
> > But what do you use to unlock it? Something needs to run 
> > cryptsetup for that unlocking action.
> 
> The Arch way seems to be to do this via the initrd which in a "default"
> setup resides on a dedicated /boot. I figure that might be good enough
> for me then.

Very likely.

Regards,
Arno

> 
> Best Wishes
> 
> 
> _______________________________________________
> 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

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[JT Morée]

I'm working through a setup right now and documenting at https://sites.google.com/site/jtmoree/knowledge-base/smart-cards-and-linux/kubuntu-20-04

I am using the smartcard to unlock root during the boot process.  this is done by the kernel and initrd using out of the box tools and processes.  

in this setup /boot is in the clear and I have some ideas for signing the kernel+initrd with the smart card, then verifying on boot.  will update the link if I get that working.

JT






On Saturday, June 20, 2020, 2:48:53 AM MST, Arno Wagner <arno@wagner.name> wrote: 





On Sat, Jun 20, 2020 at 11:07:32 CEST, d.eltzner@gmx.de wrote:
> Thanks a lot for the clarification!
> 
> On 20.06.20 08:10, Arno Wagner wrote:
> > 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.
> You mean because the initrd is somewhat safe from manipulation in this
> scenario? Wouldn't you have to do the same for the kernel then?

Yes. The kernel also goes on that stick. Grub does too, if it is
used for booting.

> > But what do you use to unlock it? Something needs to run 
> > cryptsetup for that unlocking action.
> 
> The Arch way seems to be to do this via the initrd which in a "default"
> setup resides on a dedicated /boot. I figure that might be good enough
> for me then.

Very likely.

Regards,
Arno

> 
> Best Wishes
> 
> 
> _______________________________________________
> 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

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

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[Arno Wagner]

This critically depends on the initrd being non-manipulated.
Of course, you cannot use the initrd to verify a signature 
on the initrd securely ...

Regards,
Arno

On Sat, Jun 20, 2020 at 19:26:32 CEST, JT Morée wrote:
> I'm working through a setup right now and documenting at
> https://sites.google.com/site/jtmoree/knowledge-base/smart-cards-and-linux/kubuntu-20-04
> 
> I am using the smartcard to unlock root during the boot process.  this is
> done by the kernel and initrd using out of the box tools and processes. 
> 
> in this setup /boot is in the clear and I have some ideas for signing the
> kernel+initrd with the smart card, then verifying on boot.  will update
> the link if I get that working.
> 

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

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[moreejt]

[-- Attachment #1: Type: text/html, Size: 2066 bytes --]

Re: [dm-crypt] FAQ 2.2 Scenario (1) - clarification concerning "encrypted root"

[Arno Wagner]

On Sun, Jun 21, 2020 at 22:20:21 CEST, moreejt@yahoo.com wrote:
>    I think I can get secure boot working so that the system will not boot
>    unless the kernel and initrd match sign d files
> 

That would be an option, yes. 

Regards,
Arno



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