Free access to my encrypted partition!

Hello
my problem is as follow: my home consist in a LUKS crypted partition shared with a second OS ( Mx21 ); unfortunately through this OS I have a direct access to all my home without necessity of pass phrase : partition is mounted only with root password ! I am then concerned by a such situation as I encrypted this partition for security reasons ( I don’t want a direct access of course , if direct , why to encrypt ? )
Please note partition has been crypted not during install but after and through gnome.disks utility ( std from EOS ) ; with EOS all seems work well and pass phrase is demanded during boot as expected ; home partition is automatically mounted with adequate configuration of fstab and crypttab ! unfortunately this is not working on Mx distro , no possibility to mount automatically the partition but mounted as all others partitions : manually with root password ( as a std partition).
I think it should be necessary to “indicate” to Mx distro where is stored the pass phrase and that the partition is crypted ? but no idea to do that , if somebody can help , I am not confident in LUKS process at the moment.

1 Like

Can you share the output of cryptsetup luksDump <device>

Maybe you saved the password, now it does not require it…?
See the image: “Remember forever”

passwd

1 Like

here data regarding cypted partition

[ecr@ecr-inspiron3910 ~]$ sudo cryptsetup luksDump /dev/nvme0n1p9
LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 5a12885c-bb30-403c-84e7-be41e13ae571
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]

Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 7
Memory: 1048576
Threads: 4
Salt: 43 db 08 f4 28 0e 2d d3 69 fe 1f 8f 78 67 82 1d
09 c2 c3 a7 28 f9 14 4a ae 67 70 3a b8 7c 64 6c
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 6
Memory: 1048576
Threads: 4
Salt: fd c2 c1 9e f1 d2 c8 39 5a f7 93 42 c7 09 64 35
f2 f8 f3 95 d6 c8 f1 91 ec 67 38 79 f8 7c a9 82
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 403919
Salt: e4 60 d6 e5 3f 2d 31 38 8b 7c 1d 54 8b 05 30 93
0e d2 d8 fa 25 3c 42 d8 3d 82 0d 7b 69 e8 9d bd
Digest: de de ba 99 6b fb 6d 71 50 df b6 62 f5 99 a8 63
f8 40 52 ed 53 06 3f cb 45 8e b7 74 b9 98 29 98

1 Like

I confirm I have to enter passphrase during the boot with EOS , not with Mx ; but the input of the passphrase is not according a GUI as shown : it’s entered directly in lines booting infos

I think I misread you original post, sorry.
Can you post the output of “lsblk” from EOS and from MX?
Also, have you tried to boot from the live usb and tried to access your home partition? Do you need the luks password?

1 Like

Why do you have two keyslots? Are you using a keyfile? If so, is it possible the keyfile is available unencrypted to MX linux?

1 Like

Dalto,
I can’t reply to this,as I don’t understand.
Please note I have encrypted the partition through a GUI with gnome.disks app which is included in EOS distro.
All is working correctly ,for me,with EOS only,but enryption is bypassed with Mx.

here lsblk for both distros : difference for p9 which is mounted automatically ( with passphrase at boot) for EOS and not for Mx (can’t boot with p9 in fstab without “nofails” ) .Mx reject the auto-mounting , due to encryption I suppose; also p9 not seen as crypted for Mx ( How to indicate it’s crypted ? )
2-6-23 lsblk Mx
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 3,8G 0 disk
└─sda1 8:1 1 3,8G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 200M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 65G 0 part
├─nvme0n1p4 259:4 0 990M 0 part
├─nvme0n1p5 259:5 0 18,6G 0 part
├─nvme0n1p6 259:6 0 1,4G 0 part
├─nvme0n1p7 259:7 0 58,6G 0 part
├─nvme0n1p8 259:8 0 244,1G 0 part /home
├─nvme0n1p9 259:9 0 39,1G 0 part
└─nvme0n1p10 259:10 0 48,8G 0 part /
lsblk EOS
[ecr@ecr-inspiron3910 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 1 3,8G 0 disk
└─sda1 8:1 1 3,8G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 200M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 65G 0 part
├─nvme0n1p4 259:4 0 990M 0 part
├─nvme0n1p5 259:5 0 18,6G 0 part
├─nvme0n1p6 259:6 0 1,4G 0 part
├─nvme0n1p7 259:7 0 58,6G 0 part /
├─nvme0n1p8 259:8 0 244,1G 0 part /home
├─nvme0n1p9 259:9 0 39,1G 0 part
│ └─luks-5a12885c-bb30-403c-84e7-be41e13ae571 254:0 0 39G 0 crypt /home/ecr/Datacrypt
└─nvme0n1p10 259:10 0 48,8G 0 part

The encrypted data isn’t mounted at all under MX.

Just to make sure we have a shared understanding here. Your /home isn’t encrypted.

The only thing that you encrypted is the data you have stored at /home/ecr/Datacrypt on EOS.

1 Like

Dalto
the lsblk for Mx was made prior mounting p9 as it’s impossible to mount it automatically : it’s in the fstab but with “no fails” option so that it’s not mounted ; mounting of it is manually only but without pass phrase. I don’t see then none difference between lsblk .
Here lsblk with p9 mounted

Blockquote
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 3,8G 0 disk
└─sda1 8:1 1 3,8G 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 476,9G 0 disk
├─nvme0n1p1 259:1 0 200M 0 part /boot/efi
├─nvme0n1p2 259:2 0 128M 0 part
├─nvme0n1p3 259:3 0 65G 0 part
├─nvme0n1p4 259:4 0 990M 0 part
├─nvme0n1p5 259:5 0 18,6G 0 part
├─nvme0n1p6 259:6 0 1,4G 0 part
├─nvme0n1p7 259:7 0 58,6G 0 part
├─nvme0n1p8 259:8 0 244,1G 0 part /home
├─nvme0n1p9 259:9 0 39,1G 0 part
│ └─luks-5a12885c-bb30-403c-84e7-be41e13ae571 253:0 0 39G 0 crypt /home/ecmx/Datacrypt
└─nvme0n1p10 259:10 0 48,8G 0 part /

Here the lucksDump from Mx ( no differences it seems)

LUKS header information
Version: 2
Epoch: 4
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 5a12885c-bb30-403c-84e7-be41e13ae571
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]

Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 7
Memory: 1048576
Threads: 4
Salt: 43 db 08 f4 28 0e 2d d3 69 fe 1f 8f 78 67 82 1d
09 c2 c3 a7 28 f9 14 4a ae 67 70 3a b8 7c 64 6c
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 6
Memory: 1048576
Threads: 4
Salt: fd c2 c1 9e f1 d2 c8 39 5a f7 93 42 c7 09 64 35
f2 f8 f3 95 d6 c8 f1 91 ec 67 38 79 f8 7c a9 82
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 403919
Salt: e4 60 d6 e5 3f 2d 31 38 8b 7c 1d 54 8b 05 30 93
0e d2 d8 fa 25 3c 42 d8 3d 82 0d 7b 69 e8 9d bd
Digest: de de ba 99 6b fb 6d 71 50 df b6 62 f5 99 a8 63
f8 40 52 ed 53 06 3f cb 45 8e b7 74 b9 98 29 98

1 Like

I fear the conclusion is : LUKS is totally unsafe and useless , you can by-pass it by simply installing in parallel a second distro ! Do you know an alternative for a safe encryption?

Do you want everything encrypted, or just some important files?

Encrypting everything turned out to be a hassle for me. So I create a directory or directories and encrypt that / those directories. Encrypted directories are usually referred to as vaults.

There are several apps that will do this. The one I use has a GUI for encrypting and mounting the vaults.

One example is I have a 5 GB vault, and I installed Turbo Tax (MS windows) inside the vault directory. So when the vault is closed, trying to start Turbo Tax results in a not found error. Open and mount the vault and clicking the Turbo Tax icon launches as normal. Do what is needed done, and close the vault. Works great for rarely used apps. Same with Family Tree Maker.

Of course, this is not the best solution for a Lap Top.

Not for everyone, but it works for me.

Pudge

This is absolutely not the case, something else is going here.

I would try adding a new passphrase into one of the keyslots and then removing the ones from the original keyslots.

2 Likes

It pretty clear that you likely have your MX root password installed in one of the keyslots on the LUKS partition allowing for more than one way to unlock your LUKS partition. LUKS is completely safe, this is clearly a case of user error. I second Dalto’s suggestion.

1 Like

I can garrantee you I never added the root pwd as pass phrase to my crypted partition ; does this means it’s automatically added?
Anyway I confirm I can open a crypted partition without entering passphrase through an another distro , then if you consider that as safe ? the passphrase consist in 16 caracters , the root pwd only 6 , it’s then different…

The fact that you can access it without a password tells me and anyone else that something was not set up correctly. On Linux this generally means user error. Do us all a favor and a new slot and remove the preexisting ones. The other issue here is you used a GUI to handle this for you making it harder to dissect what exactly it did.

Luks does not allow that. I can’t say exactly what happened because I don’t know exactly what has been done but Luks volumes don’t unlock themselves.

That being said, you have 2 passphrase slots in your Luks volume which seems pretty strange to me since you don’t know why you have two. To be clear, that means you have 2 different passphrases on that partition. You mention that the passphrase is 16 characters but what about the second one?

That is why I recommend creating a new one and removing the old ones. That way your system is in a known state instead of the current unknown state.

2 Likes

News from this morning : I modified my passphrase from Mx distro - with GUI app disks which is gnome.disks idem than EOS- and now passphrase is requested from Mx ,also root passwd ( both requested to open luks partition) ; From EOS no change , new passphrase is still requested during boot , then it’s OK.
Then remain the matter on Mx : impossible to boot if luks partition is automounted in fstab/crypptab ( presently boot possible only with “nofails” option). If you have an idea, let me know.Probably Mx " not aware" of this crypted partition created through an other distro).
Of course this is not at all modifying my position regarding luks : still possible to open without passphrase through a second distro.
I would know if same matter exist if the crypted partition is created during EOS installation? and if passphrase is also requested during boot?