mxlinux18 and luks encryption

[denPes]

So I tried mxlinux18. The desktop experience is very nice, except for some odd mixture of QT and gtk applications. For the installed QT applications there are pretty good gtk alternatives, which would make more sense in a gtk based desktop. But that's a minor thing. But a big compliment to the devs for creating this whole desktop experience, and the mxtools!!

The question I have is related to luks encryption that now comes with mxlinux18. I come from slackware, where I always had to enable luks encryption manually for my systems, so I am not new to this stuff.

First of all, there is a long outstanding bug, where there are problems with cleanly unmount encrypted partions, when rootfs has also been encrypted. When mxlinux18 is configured with full disk encryption, it appears that encrypted partitions are not cleanly unmounted at shutdown. It also shows this in the messages at shutdown ( in red). This has lead to data corruption in the past. The only way to avoid this is to only encrypt home and swap. Btw, i've read that this bug is fixed in newer software, which is not yet in mxlinux.

The question I also have is: why there is a keyfile in /home? This is not really necessary, especially when the whole lvm is being encrypted, since it is one big container. also when encrypting /home, swap can be encrypted randomly. The whole /etc/crypttab also seems weirdly configured ( at least to me.). I mean, it works and all, but why the decision to use a keyfile in /home? I would really try to avoid that, in favor of simplicity.

Anyway, I've manually encrypted home and swap after the mxlinux18 installation, and that works. And I wanted to let users know that there is a problem with unmounting at shutdown, for those who use full disk encryption.

[Jerry3904]

Thanks for the info, and welcome to the Forum!

I personally don't get the full disk encryption thing, but a lot of users have asked for it.

[denPes]

Well, most people don't worry too much about securing stuff, until something happens, and they realize that if they only have it had secured, it would not be so worrying.

For example, you are away, some burglar steals some stuff including your laptop. The laptop is only stuff. just like the other things that have been taken away. However, these days computers are used for almost everything. So you might have sensitive data scattered around on that laptop. Like financial details, email, personal pictures, a diary, financial data from your company ( if you are self employed), passwords. The laptop gone is not worrying, again it is just stuff, but what will the person, that now owns the laptop, do with your data? It's not like your login and password of your system will protect that at all.

Yes, you can encrypt sensitive data individually, but it takes time and discipline. However, full disk encryption, or at least encrypted home, will insure you that your data is always protected by default. and there is hardly any performance hit, since modern processors have aes instruction set. And you won't even notice it, except for the password you have to enter, at boot.

[Jerry3904]

Well that's what I said: I don't get full disk encryption--but I do encrypt /home on my business laptop and production machine.

[dolphin_oracle]

The keyfile is only in /home if the root filesystem is not encyrpted. The keyfile saves you from having to enter a password for swap in that case. When root home and swap are encrypted the keyfile is in /root and is also used to decrypt /home.

We didn't want to out the keyfile someplace that wasn't encyrpted for obvious reasons.

[denPes]

The keyfile is only in /home if the root filesystem is not encyrpted. The keyfile saves you from having to enter a password for swap in that case. When root home and swap are encrypted the keyfile is in /root and is also used to decrypt /home.

We didn't want to out the keyfile someplace that wasn't encyrpted for obvious reasons.

Thanks for your reply.

Yes I have noticed that the keyfile is only present when when home and swap are being encrypted. It was just that I always found it more complicated to use a keyfile for the encrypted swap, since the swap partition can be encrypted with a new randomly generated key at boot, so then it does not need a password and there is no need for a keyfile. But each approach might have it's advantages, I guess.

[Adrian]

Can you restore from hibernation with random encrypted swap? (frankly don't know if hibernation works with our scheme either).

[dolphin_oracle]

The keyfile is only in /home if the root filesystem is not encyrpted. The keyfile saves you from having to enter a password for swap in that case. When root home and swap are encrypted the keyfile is in /root and is also used to decrypt /home.

We didn't want to out the keyfile someplace that wasn't encyrpted for obvious reasons.

Thanks for your reply.

Yes I have noticed that the keyfile is only present when when home and swap are being encrypted. It was just that I always found it more complicated to use a keyfile for the encrypted swap, since the swap partition can be encrypted with a new randomly generated key at boot, so then it does not need a password and there is no need for a keyfile. But each approach might have it's advantages, I guess.

that is an interesting thought, and not one we considered.

[denPes]

The keyfile is only in /home if the root filesystem is not encyrpted. The keyfile saves you from having to enter a password for swap in that case. When root home and swap are encrypted the keyfile is in /root and is also used to decrypt /home.

We didn't want to out the keyfile someplace that wasn't encyrpted for obvious reasons.

Thanks for your reply.

Yes I have noticed that the keyfile is only present when when home and swap are being encrypted. It was just that I always found it more complicated to use a keyfile for the encrypted swap, since the swap partition can be encrypted with a new randomly generated key at boot, so then it does not need a password and there is no need for a keyfile. But each approach might have it's advantages, I guess.

that is an interesting thought, and not one we considered.

Slackware always had the luks encryption instructions on their installation media : http://ftp.slackware.com/pub/slackware/ ... _CRYPT.TXT

At the encrypted swap section, it shows how it is suggested there. Now slackware does not uuid's in fstab, so in their case the method used by mxlinux would be a safer choice (in case of change in disks/partitions). But for mxlinux, the slackware suggested way is probably more suited, for simplicity reasons.

[denPes]

Can you restore from hibernation with random encrypted swap? (frankly don't know if hibernation works with our scheme either).

good question. I don't think it will. Since normally with encryption, you have to give the resume hook the password, i think. I should test that.