MX Linux Forum

Support for MX and antiX Linux distros
http://www.forum.mxlinux.org/

Full disk encryption

http://www.forum.mxlinux.org/viewtopic.php?t=45146

Page 1 of 1

Full disk encryption

Posted: Fri May 11, 2018 5:24 pm
by anticapitalista
We want to add full disk encryption within the antiX/MX installer, and we need some feedback from users who already use a Linux OS with full disk encryption (fde).

How many times do you have to input the encryption passphrase?
When?
Does the system use LUKS over LVM? Should it?

I ask since I tried 2 different Linux distros that offer fde, and they did it differently.
One prompted for the passphrase before grub menu and also afterwards when 'opening' the root filesystem.
The other only prompted once, IIRC after the grub menu.

Thanks

Re: Full disk encryption

Posted: Sat May 12, 2018 10:22 pm
by Mauser
This would be great.

Re: Full disk encryption

Posted: Sat May 12, 2018 11:22 pm
by Adrian
How many people around have experience with LVM?

Re: Full disk encryption

Posted: Sun May 13, 2018 4:30 pm
by fbc
How many times do you have to input the encryption passphrase?
Assuming you involve the cryptsetup executable, you have the option --verify-passphrase.
It's arguable how much sense that makes from a frontend, which can verify the input itself, but it's also
arguable whether the frontend should know about the meaning of the corresponding input field. The
repetition could just be made optional, with an additional option to visually reveal the passphrase (like
in the user creation dialog; I think most people wouldn't consider this critical, because the encryption is
only setup once.
Does the system use LUKS over LVM? Should it?
If "the system" refers to MX Linux, honestly, I don't know... both LUKS and LVM, however, are addressed
via the device mapper infrastructure, which generally means, that you can as well have LUKS on LVM as LVM on LUKS.

Omitting (SW/HW) RAID from this thread, most users would create one partition per disk and make
that physical volume (PV), logically dividing that into extents, which can be concluded to logical volumes (LV).

From my POV it's logical to encrypt the partition and create the PV in the encrypted volume, so I have to provide a passphrase only once.

Another approach would be to set up the LVs to be encrypted individually. Apart from the fact, that the
user has to memorize possibly distinct passphrases per LV, this method could leak information about the
distribution of LVs in the PV (how critical that is, remains at the discretion of each user; i. e. I wouldn't
care, but others do).

Encrypting individual LVs has an advantage: assume your girlfriend/brother/daughter/father needs their
data for a presentation tomorrow, but their notebook died yesterday... They have the data on backup
and ask if they can borrow your laptop, and there's no reason against it. Just install their Widows and
Orphace into an LV, which can be passed via Xen to any DomU so that it appears as a physical block
device. And even if that respective person works for Bank A, while you work for Bank B, there's little
chance that they could access the other, individually encrypted LVs on the system, which could hold
delicate data of Bank B.

Since LVM on LUKS is as possible as LUKS on LVM, and both are mediated via the device manager, both
approaches can even be combined.

To abstract the term "logical volume": even encrypting a partition makes a logical volume (in a broader
sense), which can be used as a physical volume in terms of LVM. That PV can be partitioned into so
called extents, which can be concluded into LVM LVs... each of those LVs can in turn be encrypted or
even made further physical volumes for a distinct LVM volume group. Etc. etc...

How much of this setup could/should/would be implemented in an installer, is also debatable to the
max. If it was my task, I'd just say, support LVM so far that LVs are recognized (using lvscan),
but leave the creation of such arbitrarily nested LUKS/LVM setups out of the installation focus.

An option could be to add an alternative choice to gparted, which runs a shell, in which a user can do
this setup if they feel like it, and afterwards, no matter whether they choose gparted or a manual setup
(or maybe the disk to be used has been partitioned/LVMed as desired in the first place), just read in all
possible volumes (even with recursion it's pretty easy), using lvscan and cryptsetup isLuks <device-node>, give the user the chance to unlock volumes, then check again. Finally, when the volumes,
that the user deems important, are visible in the system, let the user choose:

- never touch this (probably for most of already existing file systems, or at least for LVM physical
volumes not scanned for their contents)
- don't mount
- mount as <mountpoint>
- format as <filesystem choice> and mount as <mountpoint>

While the first two options are technically equivalent, they may raise awareness when facing a user who
is not (yet) well experienced...

Anyway, just a set of suggestions...

Have a good time... til then...

Re: Full disk encryption

Posted: Mon Jun 11, 2018 4:24 am
by JCH760310
FDE would be great addition to already great distro .....

I still have Ubuntu MATE on my laptop because it has FDE (providing passphrase just once), but the desktop was already migrated from W10 to MX, but I'd like to have FDE as an extra security layer on desktop as well.

Re: Full disk encryption

Posted: Mon Jun 11, 2018 4:07 pm
by KBD
FDE is a good idea. I used it in the past with Debian. I only remember being asked for my password once at bootup. I use just a single partition with everything on it and never had any problems with FDE. I have seen on one of the forums recently, perhaps Mint?, that those using a separate home partition had issues with FDE so might want to test for that.

Re: Full disk encryption

Posted: Tue Jun 19, 2018 11:16 am
by johnf76
Hi!

I use Linux Mint XFCE (18.3) with FDE (LUKS). I actually like having to enter in a password twice...in my case, I can use two different passwords, which I think gives a bit more security as well. I am intrigued with MX, though for work purposes I would need FDE if I'm to use it on my laptop. Great Distro, by the way!

Re: Full disk encryption

Posted: Wed Jun 20, 2018 4:21 am
by c4os
Hello MX friends,

I'm new at the forum, especially registered for this thread.

I also missed the full disk encryption, because wifi passwords and /tmp is not secure with home encryption.
With some tests yesterday, I made an manual for full disk encryption.

But first the answer to the questions at the beginning:
How many times do you have to input the encryption passphrase? One time
When? When the system boots
Does the system use LUKS over LVM? Should it? Yes, it's LUKS over LVM

This manual is for an empty disk, but it also works behind a Windows installation, if Windows has only 3 partitions created.
Normally Windows use a boot, a system and a recovery disk, which are primary disks. In this case the fourth should be an extended partition, which include boot and the rest of LVM partitions.
But we speak about an empty disk and this is only for information.
Also the numbers of partitions into the LVM are not limited. You can create as much as you want. In my manual I created only root, home and swap.

Unfortunately you have to type two passwords. One for encryption and one for login.

Should I add it as attachment or as code block? Because it's a little bit longer! ;)

Re: Full disk encryption

Posted: Wed Jun 20, 2018 4:26 am
by c4os
Need to correct that:
Does the system use LUKS over LVM? Should it? No, it's LVM over LUKS!

Re: Full disk encryption

Posted: Wed Jun 20, 2018 8:19 am
by Adrian
Thanks, add a code block, not sure you can add an attachment as a new user of the forum.

Re: Full disk encryption

Posted: Wed Jun 20, 2018 11:32 am
by bigbenaugust
Debian asks once, after GRUB.
and yes, it is the LVM/LUKS combo, I cannot remember the order.

Re: Full disk encryption

Posted: Fri Jun 22, 2018 3:55 am
by c4os
Ok, lets go!

Boot from live medium and gain root at the terminal.

You need to create 2 partitions. First partition for boot with approximately 512MB and a second with the rest of the disk.
Format the boot partition with ext2 and the second partition unformatted.

Looks like this:

Code: Select all

root@mx1:/home/demo# fdisk -l
Disk /dev/sda: 119.2 GiB, 128035675648 bytes, 250069679 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x7b703775

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1          2048   1050623   1048576   512M 83 Linux
/dev/sda2       1050624 250068991 249018368 118.8G 83 Linux
If you want to clean all data, do:

Code: Select all

root@mx1:/home/demo# dd if=/dev/urandom of=/dev/sda2 bs=4k status=progress
But it takes a while!

You need to install lvm2:

Code: Select all

root@mx1:/home/demo# apt-get install lvm2
Next step is to create LUKS disk:

Code: Select all

root@mx1:/home/demo# cryptsetup luksFormat /dev/sda2

WARNING!
========
This will overwrite data on /dev/sda2 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: 
Verify passphrase:
It goes without saying to use a looooong passphrase! May you have heard about hashcat?

Mount crypt disk:

Code: Select all

root@mx1:/home/demo# cryptsetup luksOpen /dev/sda2 sda2_crypt
Enter passphrase for /dev/sda2:
Check lvms:

Code: Select all

root@mx1:/home/demo# ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Jun 19 05:43 control
lrwxrwxrwx 1 root root       7 Jun 19 06:13 sda2_crypt -> ../dm-0
Create a phyisical volume:

Code: Select all

root@mx1:/home/demo# pvcreate /dev/mapper/sda2_crypt
  Physical volume "/dev/mapper/sda2_crypt" successfully created.
Create a volume group:

Code: Select all

root@mx1:/home/demo# vgcreate diskLVM /dev/mapper/sda2_crypt
  Volume group "diskLVM" successfully created
Create the logical volumes. I used 15GB for root, 5GB for swap (should be a little bit bigger as your RAM) and the rest for home:

Code: Select all

root@mx1:/home/demo# lvcreate -n root -L 15G diskLVM -Z n
  WARNING: Logical volume diskLVM/root not zeroed.
  Logical volume "root" created.

root@mx1:/home/demo# lvcreate -n swap -L 5g diskLVM -Z n
  WARNING: Logical volume diskLVM/swap not zeroed.
  Logical volume "swap" created.

root@mx1:/home/demo# lvcreate -n home -l 100%FREE diskLVM -Z n
  WARNING: Logical volume diskLVM/home not zeroed.
  Logical volume "home" created.
Check your logical volumes:

Code: Select all

root@mx1:/home/demo# lvdisplay 
  --- Logical volume ---
  LV Path                /dev/diskLVM/root
  LV Name                root
  VG Name                diskLVM
  LV UUID                30kSyu-0yN2-thzx-URY3-GyAf-x7Eg-7LgICf
  LV Write Access        read/write
  LV Creation host, time mx1, 2018-06-19 06:37:54 -0400
  LV Status              available
  # open                 0
  LV Size                15.00 GiB
  Current LE             3840
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:1
   
  --- Logical volume ---
  LV Path                /dev/diskLVM/swap
  LV Name                swap
  VG Name                diskLVM
  LV UUID                QXCWmj-xYQ6-M0eE-Pt89-ujMg-mI4k-s5wHjU
  LV Write Access        read/write
  LV Creation host, time mx1, 2018-06-19 06:39:17 -0400
  LV Status              available
  # open                 0
  LV Size                5.00 GiB
  Current LE             1280
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:2
   
  --- Logical volume ---
  LV Path                /dev/diskLVM/home
  LV Name                home
  VG Name                diskLVM
  LV UUID                OvMVTo-EkIg-FNmb-H81Z-q1mD-qp6g-Sctie7
  LV Write Access        read/write
  LV Creation host, time mx1, 2018-06-19 06:40:51 -0400
  LV Status              available
  # open                 0
  LV Size                98.74 GiB
  Current LE             25277
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           254:3
And your mapper devices:

Code: Select all

root@mx1:/home/demo# ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Jun 19 05:43 control
lrwxrwxrwx 1 root root       7 Jun 19 06:40 diskLVM-home -> ../dm-3
lrwxrwxrwx 1 root root       7 Jun 19 06:37 diskLVM-root -> ../dm-1
lrwxrwxrwx 1 root root       7 Jun 19 06:44 diskLVM-swap -> ../dm-2
lrwxrwxrwx 1 root root       7 Jun 19 06:40 sda2_crypt -> ../dm-0
About the message the device is "not zeroed", you can wipe it's with:
dd if=/dev/urandom of=/dev/mapper/diskLVM-... bs=4k
If it was a new disk don't waste your time.

Format and activate your swap volume:

Code: Select all

root@mx1:/home/demo# mkswap /dev/mapper/diskLVM-swap
Setting up swapspace version 1, size = 5 GiB (5368705024 bytes)
no label, UUID=fe655c35-f51b-434e-b793-3ac00475f2ec

root@mx1:/home/demo# swapon /dev/mapper/diskLVM-swap
Format the root and the home volume:

Code: Select all

root@mx1:/home/demo# mkfs -t ext4 /dev/mapper/diskLVM-root
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 3932160 4k blocks and 983040 inodes
Filesystem UUID: eff44206-ffab-4cca-b78a-b8c1954307dc
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done


root@mx1:/home/demo# mkfs -t ext4 /dev/mapper/diskLVM-home
mke2fs 1.43.4 (31-Jan-2017)
Creating filesystem with 25883648 4k blocks and 6471680 inodes
Filesystem UUID: 443a74f0-8b04-437d-a7b5-1d27a55ac46b
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (131072 blocks): done
Writing superblocks and filesystem accounting information: done
Mount the root volume to /mnt:

Code: Select all

root@mx1:/home/demo# mount /dev/mapper/diskLVM-root /mnt
Create directories for boot and home:

Code: Select all

root@mx1:/home/demo# mkdir /mnt/boot /mnt/home
Mount boot partition and home volume:

Code: Select all

root@mx1:/home/demo# mount /dev/sda1 /mnt/boot/

root@mx1:/home/demo# mount /dev/mapper/diskLVM-home /mnt/home/
Copy the MX file system (it can take a while):

Code: Select all

root@mx1:/home/demo# cp -a /live/aufs/* /mnt/
Check your disk UUID's:

Code: Select all

root@mx1:/home/demo# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root  9 Jun 19 06:06 2017-05-05-08-16-50-00 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jun 19 06:06 23cd3220-553c-49af-ac5a-91e88ec8abed -> ../../sda1
lrwxrwxrwx 1 root root 10 Jun 19 06:47 443a74f0-8b04-437d-a7b5-1d27a55ac46b -> ../../dm-3
lrwxrwxrwx 1 root root 10 Jun 19 06:06 8D6C-E184 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jun 19 06:13 bd662f4e-01d4-4ac4-82fb-b68c1e5a20f7 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jun 19 06:47 eff44206-ffab-4cca-b78a-b8c1954307dc -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jun 19 06:44 fe655c35-f51b-434e-b793-3ac00475f2ec -> ../../dm-2
Now you have to edit your /mnt/etc/fstab to something like this, but with YOUR sda1 UUID:

Code: Select all

# /etc/fstab: static file system information
#
# Created by make-fstab on Tue Jun 19 05:43:39 EDT 2018

# <file system>                            <mount point>                               <type>     <options>                       <dump/$
# My root LVM
/dev/mapper/diskLVM-root        /       ext4    errors=remount-ro       0       1
# My UUID /boot device with should be pointed to /dev/sda1
UUID=23cd3220-553c-49af-ac5a-91e88ec8abed       /boot   ext2    defaults        0       2
# My swap volume
/dev/mapper/diskLVM-swap        none    swap    sw      0       0
# My home volume
/dev/mapper/diskLVM-home        /home   ext4    defaults        0       2
Edit your /mnt/etc/crypttab to something like this, but with YOUR sda2 UUID:

Code: Select all

# <target name> <source device>         <key file>      <options>
sda2_crypt      UUID=bd662f4e-01d4-4ac4-82fb-b68c1e5a20f7       none    luks,discard
Edit your /mnt/etc/lvm/lvm.conf parameter issue_discards = 0 to issue_discards = 1 if you have an SDD disk!

Copy your current resolv.conf if different (not in my case):

Code: Select all

root@mx1:/home/demo# cp /etc/resolv.conf /mnt/etc
cp: '/etc/resolv.conf' and '/mnt/etc/resolv.conf' are the same file
Mount your local services to /mnt:

Code: Select all

root@mx1:/home/demo# mount -o bind /run /mnt/run/
root@mx1:/home/demo# mount -o bind /dev /mnt/dev
root@mx1:/home/demo# mount -o bind /sys /mnt/sys
root@mx1:/home/demo# mount -t proc /proc /mnt/proc
Copy your current mounts if different (not in my case):

Code: Select all

root@mx1:/home/demo# cp /proc/mounts /mnt/etc/mtab
cp: '/proc/mounts' and '/mnt/etc/mtab' are the same file
Jump into the new root:

Code: Select all

root@mx1:/home/demo# chroot /mnt /bin/bash
Install grub:

Code: Select all

root@mx1:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
I have a different keymap, so I need to set KEYMAP=n in /etc/initramfs-tools/initramfs.conf to KEYMAP=y.
Also need to change special setting for me:

Code: Select all

root@mx1:/# dpkg-reconfigure keyboard-configuration
root@mx1:/# dpkg-reconfigure console-setup
root@mx1:/# dpkg-reconfigure locales
root@mx1:/# dpkg-reconfigure tzdata
Update your ramdisk:

Code: Select all

root@mx1:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-1-amd64
Update your grub config:

Code: Select all

root@mx1:/# update-grub
Generating grub configuration file ...
using custom appearance settings
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-4.15.0-1-amd64
Found initrd image: /boot/initrd.img-4.15.0-1-amd64
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
Install grub again (only for sure):

Code: Select all

root@mx1:/# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
Remove the demo user:

Code: Select all

root@mx1:/# deluser --remove-home demo
Looking for files to backup/remove ...
Removing files ...
Removing user `demo' ...
Warning: group `demo' has no more members.
Done.
Add a new user:

Code: Select all

root@mx1:/# adduser c4os
Adding user `c4os' ...
Adding new group `c4os' (1000) ...
Adding new user `c4os' (1000) with group `c4os' ...
Creating home directory `/home/c4os' ...
Copying files from `/etc/skel' ...
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for c4os
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] y
Adding new user `c4os' to extra groups ...
Adding user `c4os' to group `dialout' ...
Adding user `c4os' to group `dip' ...
adduser: The group `fuse' does not exist.
Adding user `c4os' to group `cdrom' ...
Adding user `c4os' to group `audio' ...
Adding user `c4os' to group `video' ...
Adding user `c4os' to group `plugdev' ...
Adding user `c4os' to group `users' ...
Adding user `c4os' to group `floppy' ...
Adding user `c4os' to group `netdev' ...
Adding user `c4os' to group `scanner' ...
Adding user `c4os' to group `lp' ...
Adding user `c4os' to group `lpadmin' ...
Adding user `c4os' to group `sudo' ...
Adding user `c4os' to group `vboxsf' ...
May lock the root user:

Code: Select all

root@mx1:/# passwd -l root
But I'm not sure if it's the correct way, because I had problems with my user sudo and his password.

Exit chroot with CRTL+D.

Unmount all mounts:

Code: Select all

root@mx1:/home/demo# umount /mnt/proc 
root@mx1:/home/demo# umount /mnt/sys
root@mx1:/home/demo# umount /mnt/run
root@mx1:/home/demo# umount /mnt/dev
root@mx1:/home/demo# umount /mnt/home
root@mx1:/home/demo# umount /mnt/boot
root@mx1:/home/demo# umount /mnt
Now you have done and can reboot! :crossfingers:

Issues:
Message at boot

Code: Select all

WARNING : Failed to connect to lvmetad. Falling back to device scanning
This message is displayed, whether running Debian stable or Debian testing.
To get rid of this message, disable lvmetad in /etc/lvm/lvm.conf

use_lvmetad=0

Update the initramfs for the current kernel your system uses :
update-initramfs -k $(uname -r) -u; sync

Code: Select all

$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-1-amd64
I: The initramfs will attempt to resume from /dev/dm-2
I: (UUID=fe655c35-f51b-434e-b793-3ac00475f2ec)
I: Set the RESUME variable to override this.
I added this issue to the last, because I haven't test it during the installation. On next test I'll change it at the discard/lvm.conf part.
Additionally, don't know where to set the RESUME variable!
Maybe this depend the message when shutdown:

Code: Select all

Stopping remaining crypto disks ... sda2_crypt (busy) ... failed
Hopefully we will get a new feature installer at the next release. It would be great to have the FIRST linux crypt installer which can install a crypt linux behind a windows installation. ;-)

Have a nice weekend and happy testing my friends!

Re: Full disk encryption

Posted: Fri Jun 22, 2018 4:14 am
by c4os
c4os wrote: Wed Jun 20, 2018 4:21 am ...
This manual is for an empty disk, but it also works behind a Windows installation, if Windows has only 3 partitions created.
Normally Windows use a boot, a system and a recovery disk, which are primary disks. In this case the fourth should be an extended partition, which include boot and the rest of LVM partitions.
But we speak about an empty disk and this is only for information.
Also the numbers of partitions into the LVM are not limited. You can create as much as you want. In my manual I created only root, home and swap.
...
As mentioned before if you have a new laptop and want to keep your windows the partitions should be:

/dev/sda1 windows system
/dev/sda2 windows recovery
/dev/sda3 windows boot
/dev/sda4 extended partition
/dev/sda5 /boot
/dev/sda6 unformated for LUKS

The only problem could be, if your manufacturer adds a additional windows partition for diagnostic.

Re: Full disk encryption

Posted: Fri Jun 22, 2018 7:38 am
by c4os
c4os wrote: Fri Jun 22, 2018 3:55 am Message at boot

Code: Select all

WARNING : Failed to connect to lvmetad. Falling back to device scanning
This message is displayed, whether running Debian stable or Debian testing.
To get rid of this message, disable lvmetad in /etc/lvm/lvm.conf

use_lvmetad=0
On my second test installation I hadn't this error! :confused:
To disable the "use_lvmetad" brings me an error:

Code: Select all

root@mx1:/# update-grub
Generating grub configuration file ...
using custom appearance settings
Found background image: .background_cache.png
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
Found linux image: /boot/vmlinuz-4.15.0-1-amd64
Found initrd image: /boot/initrd.img-4.15.0-1-amd64
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
  WARNING: Not using lvmetad because config setting use_lvmetad=0.
  WARNING: To avoid corruption, rescan devices to make changes visible (pvscan --cache).
Found Windows 10 on /dev/sda1
done
No warnings with use_lvmetad = 1

And this error still exits:

Code: Select all

Stopping remaining crypto disks ... sda2_crypt (busy) ... failed

Re: Full disk encryption

Posted: Fri Jun 22, 2018 6:40 pm
by Adrian
Wow! That's a lot, it's a full manual installation. Thanks, we'll probably use some concepts from here in the installer.

Re: Full disk encryption

Posted: Sat Jun 23, 2018 8:17 am
by c4os
With pleasure! Here you got all steps needs todo for crypt installation.
Is the path /live/aufs/ the same what the installer uses? I found the configured lvm dir after my lvm setup.
If you have something to check or test, please let me know. :happy:


For the last issue:

Code: Select all

Stopping remaining crypto disks ... sda2_crypt (busy) ... failed
I compared the MX /lib/cryptsetup/cryptdisks.functions with my last xubuntu version and there are some differences at the stop part.

MX line 669:

Code: Select all

elif [ "$opencount" != "0" ]; then
		device_msg "$dst" "busy"
		if [ "$INITSTATE" = "early" ] || [ "$INITSTATE" = "manual" ]; then
			return 1
		elif [ "$INITSTATE" = "remaining" ]; then
			return 2
		fi
		return 0
Xubuntu line 672:

Code: Select all

elif [ "$opencount" != "0" ]; then
		device_msg "$dst" "busy"
		if [ "$INITSTATE" = "early" ] || [ "$INITSTATE" = "manual" ]; then
			return 1
		fi
		return 0
MX line 765:

Code: Select all

# Removes all mappings in crypttab
do_stop () {
	local dst src key opts opencount major minor

	dmsetup mknodes
	log_action_begin_msg "Stopping $INITSTATE crypto disks"

	egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
		for i in 1 2 4 8 16 32; do
			handle_crypttab_line_stop "$dst" "$src" "$key" "$opts" <&3 && break || ret=$?
			if [ $ret -eq 1 ] || [ $ret -eq 2 -a $i -gt 16 ]; then
				log_action_end_msg $ret
				break
			fi
			log_action_cont_msg "$dst busy..."
			sleep $i
		done 3<&1
	done

	log_action_end_msg 0
}
Xubuntu line 764:

Code: Select all

do_stop () {
	local dst src key opts opencount major minor

	dmsetup mknodes
	log_action_begin_msg "Stopping $INITSTATE crypto disks"

	egrep -v "^[[:space:]]*(#|$)" "$TABFILE" | while read dst src key opts; do
		handle_crypttab_line_stop "$dst" "$src" "$key" "$opts" <&3 || log_action_end_msg $?
	done 3<&1

	log_action_end_msg 0
}
After I removed the lines in MX the message still exists, but it takes no time to wait for poweroff.
This needs to be fixed, because such error looks not good with system installation! :p

Which installation method uses the MX-Installer?
He streams the /live/aufs or /live/linux content direct to the formated disk?
And what are the partition commands?
Sorry, but I'm not so familiar with cpp programming.

Re: Full disk encryption

Posted: Sat Jun 23, 2018 9:24 am
by Adrian
The installer copies from /live/aufs, here's the relevant command:

Code: Select all

    QString cmd = QString("/bin/cp -a /live/aufs/bin /live/aufs/boot /live/aufs/dev");
    cmd.append(" /live/aufs/etc /live/aufs/lib /live/aufs/lib64 /live/aufs/media /live/aufs/mnt");
    cmd.append(" /live/aufs/opt /live/aufs/root /live/aufs/sbin /live/aufs/selinux /live/aufs/usr");
    cmd.append(" /live/aufs/var /live/aufs/home /mnt/antiX");
Even if you don't know cpp it's still pretty readable, it's just a long cp command that copies all those folders to /mnt/antiX where the new root partition is mounted.

Re: Full disk encryption

Posted: Sun Jun 24, 2018 9:15 am
by c4os
Ok, then I did it right. :happy:
Why copy all these folder and not "/bin/cp -a /live/aufs /mnt/antiX"?
Doesn't matter, main thing it works.

I got a couble of questions. How do you calculate the swap space, or do you create a swap file?
Can you send me the correct github link for the installer? I found mx-test-installer and mx-installer.
Can you recommend a good code reader/editor?

About the issues, changing the /lib/cryptsetup/cryptdisk.functions makes no sense, because it will be overwritten on updates.
I saw the installed version is 1.7.3. The actual version is 2.0.3.
https://gitlab.com/cryptsetup/cryptsetup
May we have to update to fix the "remaining" warning.

Re: Full disk encryption

Posted: Sun Jun 24, 2018 9:19 am
by dolphin_oracle
the installer:

https://github.com/gazelle-installer/gazelle-installer

Re: Full disk encryption

Posted: Sun Jun 24, 2018 11:09 am
by c4os
Thanks!

Re: Full disk encryption

Posted: Tue Jun 26, 2018 6:15 am
by c4os
c4os wrote: Sat Jun 23, 2018 8:17 am After I removed the lines in MX the message still exists, but it takes no time to wait for poweroff.
Not really a solution! I had problems to boot my laptop after this changes.
Sometimes it boot into a black screen and looks like it stuck in a resume mode.
It comes up after removing power and battery. No problems with the old config,except the busy timeout like before.

Re: Full disk encryption

Posted: Mon Jul 02, 2018 7:06 am
by c4os
I tried to log my shutdown messages, but can't find a shutdown log (/var/log/wtmp).

Code: Select all

poweroff -w
wont work.

Re: Full disk encryption

Posted: Mon Jul 02, 2018 8:32 am
by HessenZone
c4os wrote: Sun Jun 24, 2018 9:15 am Can you recommend a good code reader/editor?
I don't go beyond simple html, php, and some minor javascript, but my all-time favorite code editor of the past 25 years is .... drum roll please ...

Komodo Edit. These people also make Komodo IDE, but the first one is the free one. Installations for Windows, Linux, and Mac available. Automated embedded functions and customizable like you wouldn't believe. Anyway, here are the links:

http://downloads.activestate.com/Komodo/releases/
Pick whichever version you prefer, then download tar.gz or msi version for Windows. I'm using version 10.2

https://www.activestate.com/komodo-ide
Non-free Komodo IDE for all of the super coders who dream about lines of code at night. ;) :p :happy: :number1:

Re: Full disk encryption

Posted: Sat Jul 07, 2018 2:07 am
by grelos
+1 for FDE.

Re: Full disk encryption

Posted: Sat Jul 07, 2018 1:48 pm
by delm
anticapitalista wrote: Fri May 11, 2018 5:24 pm How many times do you have to input the encryption passphrase?
Does the system use LUKS over LVM? Should it?
Why not adopt the method used by Debian by default:
Prompted once, after the grub. First LUKS, then LVM.

Anyway, if the password is long, it would be logical
to enter the password only once.

Re: Full disk encryption

Posted: Tue Jul 10, 2018 11:31 am
by rghv
FDE for MxLinux would be great! +1 for the feature!

> Why not adopt the method used by Debian by default: Prompted once, after the grub. First LUKS, then LVM.

+1. First LUKS, then LVM.

One helpful reference here is https://www.linode.com/docs/security/en ... ncryption/ which demonstrates the workflow.

As to how that can be added to the installer itself, this is how Calamares seems to have done it. http://linuxbsdos.com/2016/11/08/disk-e ... installer/

BTW, has anyone tried Calamares+MXLinux? If so, FDE would be a solved problem already!

Re: Full disk encryption

Posted: Tue Jul 10, 2018 12:04 pm
by bigbenaugust
The refracta installer used by some Devuan-based distros does it too, you just have to click the right boxes and live with ext4.

Re: Full disk encryption

Posted: Tue Jul 10, 2018 12:09 pm
by dolphin_oracle
rghv wrote: Tue Jul 10, 2018 11:31 am FDE for MxLinux would be great! +1 for the feature!

> Why not adopt the method used by Debian by default: Prompted once, after the grub. First LUKS, then LVM.

+1. First LUKS, then LVM.

One helpful reference here is https://www.linode.com/docs/security/en ... ncryption/ which demonstrates the workflow.

As to how that can be added to the installer itself, this is how Calamares seems to have done it. http://linuxbsdos.com/2016/11/08/disk-e ... installer/

BTW, has anyone tried Calamares+MXLinux? If so, FDE would be a solved problem already!

we looked at calamares earlier this year. we would need to write a new copylinux (or whatever they call it) to install the system since calamares doesn't support our live copy method out of the box. Not impossible, and we may return to it someday, but for now we've stuck with what we know works with our live system.

The point of the double-password question is that it is *possible* to install /boot onto the encrypted root partition, but most distros do not do this, relying on an unencrypted boot partition to actually launch the rest of the system. having the /boot on the encrypted root partition necessitates the extra password entry step, when grub asks for it, then again when the system loads the linux kernel asks for it.

Re: Full disk encryption

Posted: Tue Jul 10, 2018 2:58 pm
by delm
dolphin_oracle wrote: Tue Jul 10, 2018 12:09 pm The point of the double-password question is that it is *possible* to install /boot onto the encrypted root partition, but most distros do not do this, relying on an unencrypted boot partition to actually launch the rest of the system. having the /boot on the encrypted root partition necessitates the extra password entry step, when grub asks for it, then again when the system loads the linux kernel asks for it.
You can solve this problem by creating a LUKS key and placing it in the initrd. If this can't be realized, its better to agree with the logic that Debian uses. Encrypting /boot we increase security not so significantly, but we lose a lot in convenience when entering a password twice. If the user decides to encrypt the entire system, not just /home with eCryptfs or some folders with EncFS, its worth hoping that he does it for important reasons. Then he will use a long and complex password, >20 hard-to-type letters. Entering such a password twice will be annoying.

Could you inform how soon is the FDE option planned for implementation?

Re: Full disk encryption

Posted: Tue Jul 10, 2018 3:19 pm
by dolphin_oracle
delm wrote: Tue Jul 10, 2018 2:58 pm
dolphin_oracle wrote: Tue Jul 10, 2018 12:09 pm The point of the double-password question is that it is *possible* to install /boot onto the encrypted root partition, but most distros do not do this, relying on an unencrypted boot partition to actually launch the rest of the system. having the /boot on the encrypted root partition necessitates the extra password entry step, when grub asks for it, then again when the system loads the linux kernel asks for it.
You can solve this problem by creating a LUKS key and placing it in the initrd. If this can't be realized, its better to agree with the logic that Debian uses. Encrypting /boot we increase security not so significantly, but we lose a lot in convenience when entering a password twice. If the user decides to encrypt the entire system, not just /home with eCryptfs or some folders with EncFS, its worth hoping that he does it for important reasons. Then he will use a long and complex password, >20 hard-to-type letters. Entering such a password twice will be annoying.

Could you inform how soon is the FDE option planned for implementation?
hopefully by the end of the year...

Re: Full disk encryption

Posted: Sat Aug 25, 2018 4:59 am
by c4os
I reduced the password by enable lightdm auto login. So I only need one password.
It's also secure, because it always need the password for encryption.

Re: Full disk encryption

Posted: Sat Aug 25, 2018 5:05 am
by c4os
c4os wrote: Sun Jun 24, 2018 9:15 am Ok, then I did it right. :happy:
Why copy all these folder and not "/bin/cp -a /live/aufs /mnt/antiX"?
Doesn't matter, main thing it works.

I got a couble of questions. How do you calculate the swap space, or do you create a swap file?
Can you send me the correct github link for the installer? I found mx-test-installer and mx-installer.
Can you recommend a good code reader/editor?

About the issues, changing the /lib/cryptsetup/cryptdisk.functions makes no sense, because it will be overwritten on updates.
I saw the installed version is 1.7.3. The actual version is 2.0.3.
https://gitlab.com/cryptsetup/cryptsetup
May we have to update to fix the "remaining" warning.
It looks like this is a problem at the most distributions.

It is possible to reduce the timeout with changing the line in /lib/cryptsetup/cryptdisk.functions:

Code: Select all

#		for i in 1 2 4 8 16 32; do
		for i in 0.001; do

Re: Full disk encryption

Posted: Sat Aug 25, 2018 9:41 am
by Adrian
c4os wrote: Sat Aug 25, 2018 4:59 am I reduced the password by enable lightdm auto login. So I only need one password.
It's also secure, because it always need the password for encryption.
That might be a good option, I wonder if it reduces the security when the computer goes to sleep (does it still ask for password?) or if you log out.

Re: Full disk encryption

Posted: Mon Aug 27, 2018 3:31 am
by c4os
Adrian wrote: Sat Aug 25, 2018 9:41 am
c4os wrote: Sat Aug 25, 2018 4:59 am I reduced the password by enable lightdm auto login. So I only need one password.
It's also secure, because it always need the password for encryption.
That might be a good option, I wonder if it reduces the security when the computer goes to sleep (does it still ask for password?) or if you log out.
You're right! Suspend doesn't ask for a password. Hibernate locks the display after resume. There's a option at energy settings/system.
But I saw the display content for one second until the screensaver locks. So far I don't suspend, but after I played around, I like it and will use this feature more.
So better to disable the autologin! ;-)

Re: Full disk encryption

Posted: Mon Aug 27, 2018 3:39 am
by c4os
c4os wrote: Mon Aug 27, 2018 3:31 am
Adrian wrote: Sat Aug 25, 2018 9:41 am
c4os wrote: Sat Aug 25, 2018 4:59 am I reduced the password by enable lightdm auto login. So I only need one password.
It's also secure, because it always need the password for encryption.
That might be a good option, I wonder if it reduces the security when the computer goes to sleep (does it still ask for password?) or if you log out.
You're right! Suspend doesn't ask for a password. Hibernate locks the display after resume. There's a option at energy settings/system.
But I saw the display content for one second until the screensaver locks. So far I don't suspend, but after I played around, I like it and will use this feature more.
So better to disable the autologin! ;-)
There's no difference between login and autologin! After I disabled the autologin suspend doesn't ask for a password. Hibernate locks the display after resume.
I that normal? I haven't much experience about suspend and I'have installed my system manually with FDE.

Re: Full disk encryption

Posted: Fri Oct 19, 2018 3:45 pm
by bigbenaugust
Our office had an edict come down that everything needed full-disk encryption, so I had to switch distros on a couple of my machines. Let me know if you need someone to test the installer when y'all add this, though. :)

Re: Full disk encryption

Posted: Tue Oct 23, 2018 5:46 am
by info6
No one who is using more than one OS on the same computer wants the whole disk to be encrypted, that makes no sense.

For that reason the expression "full disk encryption" should be changed into "system encryption" or something similar which makes clear that the whole system, including /root, /data, /swap, and /boot is encrypted.

Re: Full disk encryption

Posted: Sun Dec 09, 2018 9:18 pm
by darth.severus
Hi,
I'd like to encrypt my system. I'd like to have as much as possible in one btrfs-filesystem in different subvolumes, so I don't need to decide about the size of the partitions and I can easily make backups and having rollbacks of the system. I'm reading a lot through the Archwiki. However, I'm having some questions, since this stuff is really complex:

- For what do I even need LVM when I'm using btrfs inside of a LUKS device?

- Does MX Linux not support Grub2 Bootloader? Grub seems only to work with LUKS, but not LUKS2. Advantages of LUKS2 here (scrolling down a little).

- Maybe a strange idea: Can I somehow have a some container, move the data from my Windows-8 partition into a virtual partition inside and then also have a LUKS partition for my Linux inside, and also having the boot encrypted? So I could use the space I don't use for Windows for Linux (outside of LUKS) until Windows needs more space? This would be close to perfect.

Re: Full disk encryption

Posted: Sun Dec 09, 2018 11:01 pm
by Mauser
darth.severus wrote: Sun Dec 09, 2018 9:18 pm Hi,
I'd like to encrypt my system. I'd like to have as much as possible in one btrfs-filesystem in different subvolumes, so I don't need to decide about the size of the partitions and I can easily make backups and having rollbacks of the system. I'm reading a lot through the Archwiki. However, I'm having some questions, since this stuff is really complex:

- For what do I even need LVM when I'm using btrfs inside of a LUKS device?

- Does MX Linux not support Grub2 Bootloader? Grub seems only to work with LUKS, but not LUKS2. Advantages of LUKS2 here (scrolling down a little).

- Maybe a strange idea: Can I somehow have a some container, move the data from my Windows-8 partition into a virtual partition inside and then also have a LUKS partition for my Linux inside, and also having the boot encrypted? So I could use the space I don't use for Windows for Linux (outside of LUKS) until Windows needs more space? This would be close to perfect.
MX-17.1 has only Home folder encryption option. Full disk encryption is going to be in MX-18 which is going to be released before the end of the year. As for Grub I highly recommend you don't try Grub2 on MX-17.1 unless you want to break MX Linux.

Re: Full disk encryption

Posted: Sun Dec 09, 2018 11:59 pm
by Richard
I didn't know there were more than 1 grub version 2's. :)

MX Linux has
. . . . .grub-pc_2.02~beta3-5+deb9u1 and
grub2-common_2.02~beta3-5+deb9u1,
but not
. . . . . . grub2_2.02~beta3-5+deb9u1

Re: Full disk encryption

Posted: Mon Dec 10, 2018 12:04 am
by Mauser
Richard wrote: Sun Dec 09, 2018 11:59 pm
As for Grub I highly recommend you don't try Grub2 on MX-17.1 unless you want to break MX Linux.
Is this a typo?
No.

Re: Full disk encryption

Posted: Mon Dec 10, 2018 12:08 am
by Adrian
MX-17.1 uses GRUB 2.02

Re: Full disk encryption

Posted: Mon Dec 10, 2018 5:16 am
by darth.severus
Mauser wrote: Sun Dec 09, 2018 11:01 pmMX-17.1 has only Home folder encryption option.
You mean the installer, I'm talking about doing it myself. However, my questions might also be relevant for why the installer uses which option.
Full disk encryption is going to be in MX-18 which is going to be released before the end of the year.
Good to know. Thanks. However, if MX-18 installer uses options which are not optimal for me, I'll try doing it myself with the new installation. And therefore more information might be helpful.
Adrian wrote: Mon Dec 10, 2018 12:08 am MX-17.1 uses GRUB 2.02
Oh, I'll try to verify this. I was going after the program name like grub-whatever not grub2-whatever.

EDIT: Can someone who tested MX-18 beta please point out how the encryption per installer is working now.
Boot encrypted: Yes [ ] No[ ]

Re: Full disk encryption

Posted: Wed Dec 12, 2018 8:32 am
by rghv
EDIT: Can someone who tested MX-18 beta please point out how the encryption per installer is working now.
Boot encrypted: Yes [ ] No[ ]

Boot encrypted: No
Root encrypted: Yes

fdisk o/p is attached.


Thanks to all those who made FDE a standard feature in the installer. Am sure this begets a lot many onto MX's realm, as many corporate users can now conform to org-wide compliance needs.

Thanks and regards!
All times are UTC-04:00
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited