[dm-crypt] Using dm-crypt: whole disk encryption

[dm-crypt] Using dm-crypt: whole disk encryption

[ken]

A new laptop is on the way and I'm considering using dm-crypt 2 secure the whole SSD. I have some basic questions though.

Is it possible to encrypt the entire Drive, including all the system files?
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Using dm-crypt: whole disk encryption

[Arno Wagner]

To do that you need to boot from an external medium.
FAQ Section 9 has some informatiopn on how to create an 
initrd for an external boot medium.

Regards,
Arno


On Sun, Mar 21, 2021 at 17:13:16 CET, ken wrote:
> A new laptop is on the way and I'm considering using dm-crypt 2 secure the whole SSD. I have some basic questions though.
> 
> Is it possible to encrypt the entire Drive, including all the system files?
> _______________________________________________
> dm-crypt mailing list -- dm-crypt@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de

-- 
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
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Using dm-crypt: whole disk encryption

[Johnny Dahlberg]

[-- Attachment #1.1: Type: text/plain, Size: 4341 bytes --]

On Sun, 21 Mar 2021 at 17:20, ken <gebser@mousecar.com> wrote:

> A new laptop is on the way and I'm considering using dm-crypt 2 secure the
> whole SSD. I have some basic questions though.
>
> Is it possible to encrypt the entire Drive, including all the system files?
> _______________________________________________
> dm-crypt mailing list -- dm-crypt@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de


Yes, you can do this extremely easily in distributions that support it.
What does "it" mean? Well, simply: Placing the kernel and bootloader on an
EFI /boot/efi partition and using that as a bootstrap to decrypt the main
partition. And auto-updating it every time the main system kernel is
updated.
I highly recommend my favorite Linux distro, which handles all of that
automatically and asks if you want Full Disk Encryption during install:
https://pop.system76.com/

However, it only asks you if you want disk encryption if you do a full
"clean install: wipe the disk and auto-partition" setup.

Perhaps that's enough for you? In that case, just go ahead and install it
and you're done! Very quick and easy.

You can also MANUALLY set up smaller/custom partitions though (such as if
you don't want to use an entire disk for this distro). I'll guide you
through all of the steps:

- Be sure that you download Pop!_OS 20.10 ISO v12 or later. The revision is
trailing the filename, such as "pop-os_20.10_amd64_nvidia_12.iso" meaning
the 12th ISO. This is necessary because v12 (or later) enhanced the
installer to support custom encrypted partitions. Furthermore, I recommend
getting the NVIDIA iso if you have (or will ever have) an NVIDIA GPU in
your system, because that ISO makes it seamless to connect NVIDIA GPUs.

- Ensure that your partitioning table is GPT (not MBR). And that your
computer is booting with UEFI. This gives you a modern EFI bootloader.
Otherwise you end up in hellish and brittle legacy grub land where you
definitely don't wanna be.

- Use GParted on the live boot ISO to create 3 partitions: 512 MiB fat32,
4096 MiB fat32, and the remainder as "filesystem: unformatted" (it's a
choice in the GParted dropdown).

- Open a Terminal in the live boot ISO and type all of these commands
(adjust the nvme0n1p3 to whatever your own partition is named):
# Get device name for the "unformatted" partition, in my case
/dev/nvme0n1p3:
fdisk -l

# Ensure that the encrypted payload is aligned to a 1 MiB (2048 * 512 byte
sectors) boundary:
cryptsetup --key-size 256 --type luks2 --sector-size 4096 --align-payload
2048 luksFormat /dev/nvme0n1p3

# Open the LUKS volume and permanently mark it as "allow discards (TRIM) so
that it always opens like that by default, for SSD health purposes:
cryptsetup --allow-discards --persistent open /dev/nvme0n1p3 cryptdata

# Create the LVM volume metadata and enforce "start of payload" alignment
at the nearest 1 MiB boundary after the metadata (by default this means the
payload starts at 1 MiB):
pvcreate -ffy --metadatatype lvm2 --dataalignment 1m --dataalignmentoffset
0 /dev/mapper/cryptdata

# Create the LVM volume group and force it to divide the volume into
aligned 4 MiB chunks (this is the default, but enforcing it just to be
sure):
vgcreate -ffy --physicalextentsize 4m data /dev/mapper/cryptdata

# Create a LVM logical volume using all of the space:
lvcreate -y --name root --extents 100%FREE data

# Format as ext4 with 4096 byte (4 KiB) block size:
mkfs.ext4 -F -b 4096 /dev/mapper/data-root

# Close the devices.
vgchange --activate n data
cryptsetup close cryptdata

- Now close the Terminal and go back to the Pop!_OS installer window, and
proceed until it lets you pick "Custom Install". Pick that option. (Do not
click the "Unlock partition banner at the top of the window.)

- You will be brought to an overview of your partitions. Click the small
512 MiB fat32 and say "Use as: /boot/efi". Click the 4096 MiB fat32 and say
"Use as: Custom. Custom path: /recovery". And lastly, click on the large
partition and it will ask you about your password, so type your password to
unlock it. Then click the large ext4 partition that appears and choose "Use
as: Root (/)".

- Now just proceed with the installation and it will automatically set up
an encrypted full-disk bootloader with your custom partitions.


Take care and have fun!

-- Johny

[-- Attachment #1.2: Type: text/html, Size: 5133 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] What to encrypt and why (was: Using dm-crypt: whole disk encryption

[ken]

On March 22, 2021 3:57:13 AM UTC, Arno Wagner <arno@wagner.name> wrote:
>To do that you need to boot from an external medium.
>FAQ Section 9 has some informatiopn on how to create an 
>initrd for an external boot medium.
>
>Regards,
>Arno
>
>
>On Sun, Mar 21, 2021 at 17:13:16 CET, ken wrote:
>> A new laptop is on the way and I'm considering using dm-crypt 2
>secure the whole SSD. I have some basic questions though.
>> 
>> Is it possible to encrypt the entire Drive, including all the system
>files?
>> _______________________________________________
>> dm-crypt mailing list -- dm-crypt@saout.de
>> To unsubscribe send an email to dm-crypt-leave@saout.de

Thanks for your reply and or the reference to the FAQ. I should have known that the latter probably existed.

While it probably is a very useful kind of configuration for some for a system to have to boot from an external medium, it doesn't sound like something that I want to do. I guess I've been misled by my previous experience with dm-crypt.

It must have been about 20 years ago that I set up and for a couple years used an encrypted system. That system would boot as systems normally do, and I was prompted for a password somewhere along the boot process prior to having to enter my user password. I didn't need an external medium at all. And very recently I very briefly tried out Fedora 33 and clicked a checkbox for disk encryption during the install process, and the boot process was essentially the same, that is, the system would boot, then it would require password for disk decryption before I could log in. Again, no external medium was required. Your answer, though, was the right one, given my imprecise question.

This brings up larger, but pre-technical questions: what is appropriate to encrypt and why? Given your reply, it seems safe to assume that it's possible to encrypt the boot partition of a system. It's quite possible that I'm missing some reason to do this, but I can't see it. However, I'm not at all conversant with the newer UEFI boot processes, so perhaps there's something to learn there.

Reasons for encrypting the OS are more apparent, so I'm fairly certain that would be advisable. I can imagine a sound rationale for encrypting just one part a person's home directory, but for me the entire /home partition is the absolute minimum.

KVM throws another layer of possible confusion into the mix. At the moment I'm considering encrypting the entire (host) OS and /home partition, and with those all the guest systems, because this seems like the simplest way to go. However, I could be convinced against that plan if I find that performance would be too adversely affected, or for some other possible issues I'm not even aware of. Or maybe it wouldn't be simple at all to do what I'm planning. I don't know at this point.

One specific question I have comes out of the FAQ: What is meant by a container? I'm fairly certain that it could be an entire partition. Anything else? Could one container be comprised of two or more partitions? Can two or more virtual machines constitute one container if they are all on the same partition or within the same logical volume?

Sorry for the long post. If you're looking for more fodder for the FAQ, I obviously have plenty of that.  :)






_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: What to encrypt and why (was: Using dm-crypt: whole disk encryption

[Johnny Dahlberg]

[-- Attachment #1.1: Type: text/plain, Size: 5008 bytes --]

On Mon, 22 Mar 2021 at 21:37, ken <gebser@mousecar.com> wrote:

> On March 22, 2021 3:57:13 AM UTC, Arno Wagner <arno@wagner.name> wrote:
> >To do that you need to boot from an external medium.
> >FAQ Section 9 has some informatiopn on how to create an
> >initrd for an external boot medium.
> >
> >Regards,
> >Arno
> >
> >
> >On Sun, Mar 21, 2021 at 17:13:16 CET, ken wrote:
> >> A new laptop is on the way and I'm considering using dm-crypt 2
> >secure the whole SSD. I have some basic questions though.
> >>
> >> Is it possible to encrypt the entire Drive, including all the system
> >files?
> >> _______________________________________________
> >> dm-crypt mailing list -- dm-crypt@saout.de
> >> To unsubscribe send an email to dm-crypt-leave@saout.de
>
> Thanks for your reply and or the reference to the FAQ. I should have known
> that the latter probably existed.
>
> While it probably is a very useful kind of configuration for some for a
> system to have to boot from an external medium, it doesn't sound like
> something that I want to do. I guess I've been misled by my previous
> experience with dm-crypt.
>
> It must have been about 20 years ago that I set up and for a couple years
> used an encrypted system. That system would boot as systems normally do,
> and I was prompted for a password somewhere along the boot process prior to
> having to enter my user password. I didn't need an external medium at all.
> And very recently I very briefly tried out Fedora 33 and clicked a checkbox
> for disk encryption during the install process, and the boot process was
> essentially the same, that is, the system would boot, then it would require
> password for disk decryption before I could log in. Again, no external
> medium was required. Your answer, though, was the right one, given my
> imprecise question.
>
> This brings up larger, but pre-technical questions: what is appropriate to
> encrypt and why? Given your reply, it seems safe to assume that it's
> possible to encrypt the boot partition of a system. It's quite possible
> that I'm missing some reason to do this, but I can't see it. However, I'm
> not at all conversant with the newer UEFI boot processes, so perhaps
> there's something to learn there.
>
> Reasons for encrypting the OS are more apparent, so I'm fairly certain
> that would be advisable. I can imagine a sound rationale for encrypting
> just one part a person's home directory, but for me the entire /home
> partition is the absolute minimum.
>
> KVM throws another layer of possible confusion into the mix. At the moment
> I'm considering encrypting the entire (host) OS and /home partition, and
> with those all the guest systems, because this seems like the simplest way
> to go. However, I could be convinced against that plan if I find that
> performance would be too adversely affected, or for some other possible
> issues I'm not even aware of. Or maybe it wouldn't be simple at all to do
> what I'm planning. I don't know at this point.
>
> One specific question I have comes out of the FAQ: What is meant by a
> container? I'm fairly certain that it could be an entire partition.
> Anything else? Could one container be comprised of two or more partitions?
> Can two or more virtual machines constitute one container if they are all
> on the same partition or within the same logical volume?
>
> Sorry for the long post. If you're looking for more fodder for the FAQ, I
> obviously have plenty of that.  :)
>
>
>
Did you see my detailed reply to your previous post? It explains the exact
boot process you want (being asked for a password at boot).

As for whether to use UEFI boot or not: Yes. Use it. It's way more robust
than MBR boot methods. Don't be afraid to research what systemd-boot is, if
you want to know. Or just enable UEFI in your BIOS (it's most likely on by
default on your new laptop) and just install the OS and it'll automatically
use UEFI.

As for what to encrypt:

/boot/efi = No. It must be unencrypted to be able to boot. But it only
contains your bootloader, kernel and initramfs which is what sets up the
decryption environment.

/ (root) = Yes. All of it will be encrypted with your passphrase.

As for having a separate /home partition: Don't bother. It makes no sense
at all and just creates hassle when you inevitably run out of space in
either / or /home. There are no benefits to a separate home directory.
None. People think it makes OS reinstalls or distro hopping easier. Nope it
doesn't. If you have a unified partition, you simply have to boot any
random liveCD and delete everything except the /home folder, and then
install your OS on the same partition without formatting it, and voila
you've kept /home without tediously separating it.

If you wanna check out the distro I recommended in the longer answer about
full disk encryption, you even have a "Refresh Install" feature in the
installer, which deletes everything except /home and reinstalls the OS.
That's another fantastically easy option. :-)


-- Johnny

[-- Attachment #1.2: Type: text/html, Size: 5787 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Using dm-crypt: whole disk encryption

[Maksim Fomin]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 21, 2021 4:13 PM, ken <gebser@mousecar.com> wrote:

> A new laptop is on the way and I'm considering using dm-crypt 2 secure the whole SSD. I have some basic questions though.
>
> Is it possible to encrypt the entire Drive, including all the system files?
>
> dm-crypt mailing list -- dm-crypt@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de

This is a complex topic because there are several ways to encrypt entire drive (which is called FDE - full disk ecnryption) and because it depends on several tools (dmcrypt, cryptsetup, initrd, bootloader, file system, possibly lvm) working together. This topic is further complicated because initrd, filesystem, bootloader may vary (which means this question is beyond of scope of dmcrypt).

First of all, encrypting 'entire drive' can mean two things: literally encrypting entire drive (#1) or leaving bootloader (residing on such drive) unencrypted (#2). Since neither BIOS nor EFI support decrypting bootloaders, some part of bootloader must be left unencrypted anyway. This means if you encrypt entire drive (#1), you must also have the second drive during boot because no BIOS/EFI firmware can decrypt partitions/drives. But if you do not need the second drive in boot process per se, you can move bootloader to unencrypted partition and have a single drive (scenario #2). So basically scenario #2 results in having encrypted as much as possible (including all system files, which you mentioned in the question), taking into account technical limitations of BIOS/EFI firmware.

Assuming scenario #2 and EFI machine there are several 'schemes' to do FDE.

1. Leaving unencrypted only portion of bootloader on EFI partition. AFAIK, only grub supports that. It can embed some minimal crypto modules in its core image in efi file which resides in EFI partition. During boot the core image ('efi file') asks password, decrypts the partition where the rest of grub bootloader code resides and loads its. Probably systemd bootloader also supports this scheme, but I am not sure (I use grub). In this scenario initrd or LUKS keyfiles can reside inside encrypted partitions with no security concers during boot process (except that these keyfiles can be compromised when system is booted - if an attacker gains root access it can read any file, including keyfiles).

Example of such setup: grub resides in EFI partition and on root partition. Root partition resides on LVM volume on top of LUKS/plain dm-crypt real GPT (sda/sdb/sdx) partition. During boot grub asks password for decrypting LUKS partition. In this case initrd image either asks password during boot (for the second time) or keyfile is embeded into initrd image (this depends on which initrd is used). In the latter case when system is booted an attacker which gained root access can read initrd image and get the keyfile.

2. Leaving bootloader fully unencrypted. Theoreticaly anyone which has psysical access to your drive can compromise the bootloader, but this is extremely theoretical scenario. In this case during boot you must provide passphase to decrypt root partition (possibly LVM partition which contains root/home/other partitions). In general, this case is similar to 1.

3. Leaving bootloader and initrd/linux image unencrypted. This means during boot initrd will ask the password (or keyfile on special drive) to decrypt root partition - in this case only once (if all partitions reside on LVM which resides on top of LUKS/plain dm-crypt partition). In this scenario not only bootloader, but also initrd and linux image can be theoretically compromised.

Actually, there are more configurations which were mentioned. Technically kernel image can be located in encrypted location while initrd left on unencrypted partition (and vice versa) - although such configuration has little sense. Swap partition can be located on LVM volume or on separate partition. Bootloader can be located on EFI partition or partially on some secondary partition. Initrd and kernel image can be located on encrypted root partition or on a separate partition. Initrd can be configured via crypttab to decrypt root partition with password prompt or via keyfile. Well, keyfiles can be located on separate drive which must be plugged in order to boot machine. Or they can be placed in root partition and marked as read-root-only (hoping attacker will not have root access). Or keyfiles can be located on some separate encryption partition which protects them after boot.


More information can be found in archlinux wiki (https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system) which contains quite decent manual for entire drive encryption. Gentoo also has some information (https://wiki.gentoo.org/wiki/Full_Disk_Encryption_From_Scratch_Simplified) but it is more limited. It should be noted that both wiki contain distro-specific information which is likely is not applicable to your distribution.


* Regarding compromising bootloader or initrd/linux image. These are theoretical threats - I have not heard any public case when some entity (for example, government) hacked someone through bootloader/initrd/linux image. This means some tools allow to protect them, but this is probably overkill.

** Regarding choice between LVM and several GPT partitions. If you have several GPT partitions, you must provide passwords for all of them and keep entries in /etc/cryptab for each partition. So, if you have root and home partitions (not counting boot partition), you have to type (at least) two passwords during boot (possibly two times for root partition - to unlock initrd/linux image if it is located in encrypted root). If you have encrypted root, home and swap partition - you have to type three passwords for each partition. LVM can simplify things here - you can have LVM volumes on top of single real (GPT) partition which is encrypted (LUKS or dm-crypt). In this case you type password only once - for the single LUKS/plain dm-crypt partition. Once it is decrypted, initrd can activate LVM partitions and mount them according to /etc/fstab entries without asking password (keyfiles) for each lvm volume (which acts as virtual volume).

*** Encrypted drive/partition can contain several partitions/LVM volumes which can complicate boot process, but some technical considerations should be taken into account: 1) EFI firmware can load bootloader only from unencrypted real (GPT) partition, 2) bootloader must support encryption and file system where initrd/linux image is located, 3) initrd image must be configured to unlock root partition - either by asking password or by reading keyfile from some place which is accessible to initrd during boot process.

Best regards,
Maxim Fomin
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: What to encrypt and why (was: Using dm-crypt: whole disk encryption

[Maksim Fomin]

[-- Attachment #1.1: Type: text/plain, Size: 2869 bytes --]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 22, 2021 8:50 PM, Johnny Dahlberg <svartchimpans@gmail.com> wrote:

> As for whether to use UEFI boot or not: Yes. Use it. It's way more robust than MBR boot methods. Don't be afraid to research what systemd-boot is, if you want to know. Or just enable UEFI in your BIOS (it's most likely on by default on your new laptop) and just install the OS and it'll automatically use UEFI.
>
> As for what to encrypt:
>
> /boot/efi = No. It must be unencrypted to be able to boot. But it only contains your bootloader, kernel and initramfs which is what sets up the decryption environment.
>
> / (root) = Yes. All of it will be encrypted with your passphrase.
>
> As for having a separate /home partition: Don't bother. It makes no sense at all and just creates hassle when you inevitably run out of space in either / or /home. There are no benefits to a separate home directory. None. People think it makes OS reinstalls or distro hopping easier. Nope it doesn't. If you have a unified partition, you simply have to boot any random liveCD and delete everything except the /home folder, and then install your OS on the same partition without formatting it, and voila you've kept /home without tediously separating it.
>
> If you wanna check out the distro I recommended in the longer answer about full disk encryption, you even have a "Refresh Install" feature in the installer, which deletes everything except /home and reinstalls the OS. That's another fantastically easy option. :-)
>
> -- Johnny

1. Kernel and initramfs can be located in encrypted partition if bootloader can decrypt them.
2. Having separate /home partition has several benefits: if root fs is damaged, the home partition is left intact. Also, depending on fs type, its configuration and partition size io operations can be faster on smaller partitons than on a big one.
3. There are such tools like lvm or fs subvolumes which make the choice between single or separate partition redudant. For example, lvm alows to share single partition space for several virtual partitions (they are fs independent - if one fs is damaged, other are still ok). Some fs allow to have subvolumes which also share space (but they are fs dependent, so if fs is damaged all its subvolumes are also damaged).

Regarding initial question: operating system partition, swap partition, home partition and all other 'user data' partitions 'are appropriate' to encrypt. Boot partition (to be more precise bootloader) can also be encrypt, but the benefits are extremely theoretical. Initrd and kernel images 'are appropriate' to encrypt if they are part of encryption process (in this case they must encrypt, because, for example embeding keyfile in initrd image located at unencrypted partition is like leaving key at the door).

Best regards,
Maxim Fomin

[-- Attachment #1.2: Type: text/html, Size: 3360 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: What to encrypt and why (was: Using dm-crypt: whole disk encryption

[Johnny Dahlberg]

[-- Attachment #1.1: Type: text/plain, Size: 4459 bytes --]

On Mon, 22 Mar 2021 at 22:27, Maksim Fomin <maxim@fomin.one> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, March 22, 2021 8:50 PM, Johnny Dahlberg <
> svartchimpans@gmail.com> wrote:
>
> As for whether to use UEFI boot or not: Yes. Use it. It's way more robust
> than MBR boot methods. Don't be afraid to research what systemd-boot is, if
> you want to know. Or just enable UEFI in your BIOS (it's most likely on by
> default on your new laptop) and just install the OS and it'll automatically
> use UEFI.
>
> As for what to encrypt:
>
> /boot/efi = No. It must be unencrypted to be able to boot. But it only
> contains your bootloader, kernel and initramfs which is what sets up the
> decryption environment.
>
> / (root) = Yes. All of it will be encrypted with your passphrase.
>
> As for having a separate /home partition: Don't bother. It makes no sense
> at all and just creates hassle when you inevitably run out of space in
> either / or /home. There are no benefits to a separate home directory.
> None. People think it makes OS reinstalls or distro hopping easier. Nope it
> doesn't. If you have a unified partition, you simply have to boot any
> random liveCD and delete everything except the /home folder, and then
> install your OS on the same partition without formatting it, and voila
> you've kept /home without tediously separating it.
>
> If you wanna check out the distro I recommended in the longer answer about
> full disk encryption, you even have a "Refresh Install" feature in the
> installer, which deletes everything except /home and reinstalls the OS.
> That's another fantastically easy option. :-)
>
>
> -- Johnny
>
>
> 2. Having separate /home partition has several benefits: if root fs is
> damaged, the home partition is left intact. Also, depending on fs type, its
> configuration and partition size io operations can be faster on smaller
> partitons than on a big one.
> 3. There are such tools like lvm or fs subvolumes which make the choice
> between single or separate partition redudant. For example, lvm alows to
> share single partition space for several virtual partitions (they are fs
> independent - if one fs is damaged, other are still ok). Some fs allow to
> have subvolumes which also share space (but they are fs dependent, so if fs
> is damaged all its subvolumes are also damaged).
>
>
 Hi Maksim! :-)

"if root fs is damaged, the home partition is left intact."

I disagree. If we're talking general filesystem corruption, that's equally
likely to happen to the home partition. And in both cases it's just minor
stuff like corruption from a loss of power during write. All of which is
fixable with a simple filesystem check/repair command.

The other kind of corruption, which is physical corruption of the storage
medium, is also equally likely to happen to *any* partition.

The final kind, which is software induced data loss such as "rm -rf /",
will likewise destroy the home partition too.

So corruption isn't a reason to separate partitions.

"depending on fs type, its configuration and partition size io operations
can be faster on smaller partitons than on a big one."

What are you referring to here? The speed of formatting a brand new
filesystem? That's a do-it-once-and-keep-it-for-years operation and I would
think it's silly to worry about that inital formatting. Which usually takes
mere seconds in quick format mode. It's not a reason to separate partitions.

"There are such tools like lvm or fs subvolumes which make the choice
between single or separate partition redudant."

That is a really good point. LVM thin provisioning lets several volumes
have a shared pool of storage, which would make it possible to separate
home and root without defining fixed sizes for each. Although I still don't
see the point compared to the process I described. Since you can always
rely on a filesystem check keeping the health of your filesystem, it
doesn't matter if your /home filesystem is separate or shared with the rest
of /. It's not more safe.

But LVM thin provisioning is definitely the route I would choose if I had
to separate them. Performance is probably pretty good, since LVM allocates
chunks of 4 MiB by default, so there shouldn't be any massive fragmentation
by doing that.

Anyway, good luck with your new system, Ken!


Best Regards,

-- Johnny

[-- Attachment #1.2: Type: text/html, Size: 5372 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Using dm-crypt: whole disk encryption

[Didier Spaier]

Le 22/03/2021 à 17:43, Johnny Dahlberg a écrit :
> On Sun, 21 Mar 2021 at 17:20, ken <gebser@mousecar.com 
> <mailto:gebser@mousecar.com>> wrote:
> 
>     A new laptop is on the way and I'm considering using dm-crypt 2
>     secure the whole SSD. I have some basic questions though.
> 
>     Is it possible to encrypt the entire Drive, including all the system
>     files?

> Yes, you can do this extremely easily in distributions that support it.
> What does "it" mean? Well, simply: Placing the kernel and bootloader on 
> an EFI /boot/efi partition and using that as a bootstrap to decrypt the 
> main partition. And auto-updating it every time the main system kernel 
> is updated.
> I highly recommend my favorite Linux distro, which handles all of that 
> automatically and asks if you want Full Disk Encryption during install: 
> https://pop.system76.com/

Well Slint can do that as well in 'Auto' mode, with a simpler layout:
1. A BiosBoot partition # For GRUB to boot in Legacy mode
2. An ESP # Contains only the EFI OS loader
3. A partition for /, encrypted
4. Optionally an additional partition, encrypted

No LVM, the LUKS passphrase is asked by GRUB before displaying its menu,
then loads the kernel and the initrd, which includes a LUKS key used to
unlock /, also stored in /etc/keys
Another LUKS key stored in /etc/keys allows then to unlock /data.

when the kernel is updated, the key used to unlock / is copied in the
new initrd.

As an aside, instead of a swap partition a small swap file is set up,
as well as a swap space in zram with a higher priority.

Out of curiosity I installed pop-os in a Qemu VM. I think it would be
fair to mention on the website that it's based on Ubuntu. I don't
like GNOME, but that's just a personal taste ;)

Slint's website: https://slint.fr
Main server: http://slackware.uk/slint/x86_64/slint-14.2.1/

Best regards,
Didier
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: What to encrypt and why (was: Using dm-crypt: whole disk encryption

[Maksim Fomin]

[-- Attachment #1.1: Type: text/plain, Size: 4304 bytes --]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, March 22, 2021 9:58 PM, Johnny Dahlberg <svartchimpans@gmail.com> wrote:

> On Mon, 22 Mar 2021 at 22:27, Maksim Fomin <maxim@fomin.one> wrote:
>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Monday, March 22, 2021 8:50 PM, Johnny Dahlberg <svartchimpans@gmail.com> wrote:
>>
>>> As for whether to use UEFI boot or not: Yes. Use it. It's way more robust than MBR boot methods. Don't be afraid to research what systemd-boot is, if you want to know. Or just enable UEFI in your BIOS (it's most likely on by default on your new laptop) and just install the OS and it'll automatically use UEFI.
>>>
>>> As for what to encrypt:
>>>
>>> /boot/efi = No. It must be unencrypted to be able to boot. But it only contains your bootloader, kernel and initramfs which is what sets up the decryption environment.
>>>
>>> / (root) = Yes. All of it will be encrypted with your passphrase.
>>>
>>> As for having a separate /home partition: Don't bother. It makes no sense at all and just creates hassle when you inevitably run out of space in either / or /home. There are no benefits to a separate home directory. None. People think it makes OS reinstalls or distro hopping easier. Nope it doesn't. If you have a unified partition, you simply have to boot any random liveCD and delete everything except the /home folder, and then install your OS on the same partition without formatting it, and voila you've kept /home without tediously separating it.
>>>
>>> If you wanna check out the distro I recommended in the longer answer about full disk encryption, you even have a "Refresh Install" feature in the installer, which deletes everything except /home and reinstalls the OS. That's another fantastically easy option. :-)
>>>
>>> -- Johnny
>>
>> 2. Having separate /home partition has several benefits: if root fs is damaged, the home partition is left intact. Also, depending on fs type, its configuration and partition size io operations can be faster on smaller partitons than on a big one.
>> 3. There are such tools like lvm or fs subvolumes which make the choice between single or separate partition redudant. For example, lvm alows to share single partition space for several virtual partitions (they are fs independent - if one fs is damaged, other are still ok). Some fs allow to have subvolumes which also share space (but they are fs dependent, so if fs is damaged all its subvolumes are also damaged).
>
> Hi Maksim! :-)
>
> "if root fs is damaged, the home partition is left intact."
>
> I disagree. If we're talking general filesystem corruption, that's equally likely to happen to the home partition. And in both cases it's just minor stuff like corruption from a loss of power during write. All of which is fixable with a simple filesystem check/repair command.
>
> The other kind of corruption, which is physical corruption of the storage medium, is also equally likely to happen to *any* partition.
>
> The final kind, which is software induced data loss such as "rm -rf /", will likewise destroy the home partition too.
>
> So corruption isn't a reason to separate partitions.
>
> "depending on fs type, its configuration and partition size io operations can be faster on smaller partitons than on a big one."
>
> What are you referring to here? The speed of formatting a brand new filesystem? That's a do-it-once-and-keep-it-for-years operation and I would think it's silly to worry about that inital formatting. Which usually takes mere seconds in quick format mode. It's not a reason to separate partitions.
>
> Best Regards,
>
> -- Johnny

Nevertheless, when corruption happens (for example, power failure, RAM bit flip), there are higher chances to have only one out of two fs damaged. Regarding faster io operation - I didn't mean formatting, but a general case. In my experience 2 TB partition works in both ext4/btrfs visibly slower than 40 GB root partitions, expecially on mounting, because when partition is 5TB, fs checks more data structures during mount. Anyway, claims like 'There are no benefits to a separate home directory' should be provided with care because the choice depends on many circumstances. In addition, such discussion is not related to dm-crypt.

Best regards,
Maxim Fomin

[-- Attachment #1.2: Type: text/html, Size: 5428 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Using dm-crypt: whole disk encryption

[Johnny Dahlberg]

[-- Attachment #1.1: Type: text/plain, Size: 3920 bytes --]

On Tue, 23 Mar 2021 at 00:59, Didier Spaier <didier@slint.fr> wrote:

> Le 22/03/2021 à 17:43, Johnny Dahlberg a écrit :
> > On Sun, 21 Mar 2021 at 17:20, ken <gebser@mousecar.com
> > <mailto:gebser@mousecar.com>> wrote:
> >
> >     A new laptop is on the way and I'm considering using dm-crypt 2
> >     secure the whole SSD. I have some basic questions though.
> >
> >     Is it possible to encrypt the entire Drive, including all the system
> >     files?
>
> > Yes, you can do this extremely easily in distributions that support it.
> > What does "it" mean? Well, simply: Placing the kernel and bootloader on
> > an EFI /boot/efi partition and using that as a bootstrap to decrypt the
> > main partition. And auto-updating it every time the main system kernel
> > is updated.
> > I highly recommend my favorite Linux distro, which handles all of that
> > automatically and asks if you want Full Disk Encryption during install:
> > https://pop.system76.com/
>
> Well Slint can do that as well in 'Auto' mode, with a simpler layout:
>

Ah. The layout you describe is basically the same thing as Pop!_OS full
disk encryption. But Pop requires LVM on top of LUKS. I wish it didn't
require LVM. But at least it's nice since LVM lets you "repartition" inside
the encrypted disk easily by just adding more LVM volumes.

I think all distros that support FDE do basically the layout you described.
Because EFI/BIOS don't support encrypted bootloaders. So the boot partition
must always be unencrypted. And then the bootloader needs something to
decrypt the disk, and the easiest way to do that is initrd/initramfs with a
whole kernel on the unencrypted boot partition. Which decrypts the disk and
passes control over to the main system kernel (via chroot and stuff like
that). This process is universal.

You mention using grub and BIOS boot though. I've heard that it's painfully
slow to boot LUKS systems via grub? I haven't tried grub in years, but I
use UEFI systemd-boot and it's instant (the decryption unlock screen shows
up in ~3 seconds, and the desktop is booted in another ~5 seconds). It's
really fast.


>
> As an aside, instead of a swap partition a small swap file is set up,
> as well as a swap space in zram with a higher priority.
>
>
That's nice. I don't use swap at all (I have 64GB RAM) but I've been
reading about zram which does in-ram compression, that's a nice thing.
Thank you for reminding me to do that.


> Out of curiosity I installed pop-os in a Qemu VM. I think it would be
> fair to mention on the website that it's based on Ubuntu. I don't
> like GNOME, but that's just a personal taste ;)
>
>
True. They have a few small mentions about Ubuntu on the website though,
but they definitely don't brag about it. It's a good thing though since it
means the users can search the vast amounts of Ubuntu information online to
find answers.

As for GNOME, you can replace the desktop environment with one command. You
just run the command for the environment you want, and it will appear on
your login screen with a little down-arrow to log in using that particular
environment, and you can have multiple at the same time. Here's a list of
environments and how to install each:

https://support.system76.com/articles/desktop-environment/

That Slint distro is news to me. It gives the impression that it's very
niche (it has existed for over a decade but was added to Distrowatch last
year :O). Can be nice to find cozy, unique distros like that, but it's hard
to find documentation for problems or proper maintenance by the developers
on such small distros.

My choices for systems that "just work" would be Manjaro (Arch) and Pop
(Ubuntu/Debian). Both are really, really polished.


> Slint's website: https://slint.fr
> Main server: http://slackware.uk/slint/x86_64/slint-14.2.1/
>
>
Best Regards,

Johnny

[-- Attachment #1.2: Type: text/html, Size: 5423 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: Using dm-crypt: whole disk encryption

[ken]

[-- Attachment #1.1: Type: text/plain, Size: 5305 bytes --]

On March 22, 2021 4:43:59 PM UTC, Johnny Dahlberg <svartchimpans@gmail.com> wrote:
>On Sun, 21 Mar 2021 at 17:20, ken <gebser@mousecar.com> wrote:
>
>> A new laptop is on the way and I'm considering using dm-crypt 2
>secure the
>> whole SSD. I have some basic questions though.
>>
>> Is it possible to encrypt the entire Drive, including all the system
>files?
>> _______________________________________________
>> dm-crypt mailing list -- dm-crypt@saout.de
>> To unsubscribe send an email to dm-crypt-leave@saout.de
>
>
>Yes, you can do this extremely easily in distributions that support it.
>What does "it" mean? Well, simply: Placing the kernel and bootloader on
>an
>EFI /boot/efi partition and using that as a bootstrap to decrypt the
>main
>partition. And auto-updating it every time the main system kernel is
>updated.
>I highly recommend my favorite Linux distro, which handles all of that
>automatically and asks if you want Full Disk Encryption during install:
>https://pop.system76.com/
>
>However, it only asks you if you want disk encryption if you do a full
>"clean install: wipe the disk and auto-partition" setup.
>
>Perhaps that's enough for you? In that case, just go ahead and install
>it
>and you're done! Very quick and easy.
>
>You can also MANUALLY set up smaller/custom partitions though (such as
>if
>you don't want to use an entire disk for this distro). I'll guide you
>through all of the steps:
>
>- Be sure that you download Pop!_OS 20.10 ISO v12 or later. The
>revision is
>trailing the filename, such as "pop-os_20.10_amd64_nvidia_12.iso"
>meaning
>the 12th ISO. This is necessary because v12 (or later) enhanced the
>installer to support custom encrypted partitions. Furthermore, I
>recommend
>getting the NVIDIA iso if you have (or will ever have) an NVIDIA GPU in
>your system, because that ISO makes it seamless to connect NVIDIA GPUs.
>
>- Ensure that your partitioning table is GPT (not MBR). And that your
>computer is booting with UEFI. This gives you a modern EFI bootloader.
>Otherwise you end up in hellish and brittle legacy grub land where you
>definitely don't wanna be.
>
>- Use GParted on the live boot ISO to create 3 partitions: 512 MiB
>fat32,
>4096 MiB fat32, and the remainder as "filesystem: unformatted" (it's a
>choice in the GParted dropdown).
>
>- Open a Terminal in the live boot ISO and type all of these commands
>(adjust the nvme0n1p3 to whatever your own partition is named):
># Get device name for the "unformatted" partition, in my case
>/dev/nvme0n1p3:
>fdisk -l
>
># Ensure that the encrypted payload is aligned to a 1 MiB (2048 * 512
>byte
>sectors) boundary:
>cryptsetup --key-size 256 --type luks2 --sector-size 4096
>--align-payload
>2048 luksFormat /dev/nvme0n1p3
>
># Open the LUKS volume and permanently mark it as "allow discards
>(TRIM) so
>that it always opens like that by default, for SSD health purposes:
>cryptsetup --allow-discards --persistent open /dev/nvme0n1p3 cryptdata
>
># Create the LVM volume metadata and enforce "start of payload"
>alignment
>at the nearest 1 MiB boundary after the metadata (by default this means
>the
>payload starts at 1 MiB):
>pvcreate -ffy --metadatatype lvm2 --dataalignment 1m
>--dataalignmentoffset
>0 /dev/mapper/cryptdata
>
># Create the LVM volume group and force it to divide the volume into
>aligned 4 MiB chunks (this is the default, but enforcing it just to be
>sure):
>vgcreate -ffy --physicalextentsize 4m data /dev/mapper/cryptdata
>
># Create a LVM logical volume using all of the space:
>lvcreate -y --name root --extents 100%FREE data
>
># Format as ext4 with 4096 byte (4 KiB) block size:
>mkfs.ext4 -F -b 4096 /dev/mapper/data-root
>
># Close the devices.
>vgchange --activate n data
>cryptsetup close cryptdata
>
>- Now close the Terminal and go back to the Pop!_OS installer window,
>and
>proceed until it lets you pick "Custom Install". Pick that option. (Do
>not
>click the "Unlock partition banner at the top of the window.)
>
>- You will be brought to an overview of your partitions. Click the
>small
>512 MiB fat32 and say "Use as: /boot/efi". Click the 4096 MiB fat32 and
>say
>"Use as: Custom. Custom path: /recovery". And lastly, click on the
>large
>partition and it will ask you about your password, so type your
>password to
>unlock it. Then click the large ext4 partition that appears and choose
>"Use
>as: Root (/)".
>
>- Now just proceed with the installation and it will automatically set
>up
>an encrypted full-disk bootloader with your custom partitions.
>
>
>Take care and have fun!
>
>-- Johny

Much thanks to everyone who replied. Your answers were much better than my question. From those answers it's abundantly apparent that I need to study a bit more on a few issues, like the boot processes and other things before I'll be able to make intelligent decisions. I used to understand the boot process fairly well, but that was before quite a bit was changed.

Also, I can't reply to e-mails the way I'm accustomed to and the way I'd like to because I don't have an actual Linux system for that, rather I'm forced to make do with a phone for the time being. Not optimal at all.

Thanks again for all the great replies.

[-- Attachment #1.2: Type: text/html, Size: 5961 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de