Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux Disk Encryption Available After Initial OS Install #112

Open
inferenceus opened this issue Mar 1, 2023 · 2 comments
Open

Linux Disk Encryption Available After Initial OS Install #112

inferenceus opened this issue Mar 1, 2023 · 2 comments
Labels
[c] update existing Existing content updates (beyond trivial fixes)

Comments

@inferenceus
Copy link
Contributor

inferenceus commented Mar 1, 2023

The article Desktop Linux Hardening states disk encryption requires an OS reinstall if it was not enabled on first install. However, it is now possible to encrypt-in-place using cryptsetup's reencrypt feature (using --encrypt argument), which converts a currently unencrypted partition into a LUKS container. Although this approach does require a small amount of free space available at the end of the partition for the new LUKS header (applied using another argument), I have personally used this feature and it works as intended.

Despite the unencrypted data being leaked on the disk due to previously being written unencrypted, the same occurs with an OS reinstall without writing random data such as /dev/urandom when using a HDD, or impossible on an SSD without physical destruction (since ATA Secure Erase can't be trusted to have been implemented correctly without testing beforehand), so it shouldn't be an issue in this aspect.

@TommyTran732
Copy link
Member

TommyTran732 commented Mar 2, 2023

The article Desktop Linux Hardening states disk encryption requires an OS reinstall if it was not enabled on first install. However, it is now possible to encrypt-in-place using cryptsetup's reencrypt feature (using --encrypt argument), which converts a currently unencrypted partition into a LUKS container. Although this approach does require a small amount of free space available at the end of the partition for the new LUKS header (applied using another argument), I have personally used this feature and it works as intended.

Despite the unencrypted data being leaked on the disk due to previously being written unencrypted, the same occurs with an OS reinstall without writing random data such as /dev/urandom when using a HDD, or impossible on an SSD without physical destruction (since ATA Secure Erase can't be trusted to have been implemented correctly without testing beforehand), so it shouldn't be an issue in this aspect.

Which filesystem does it work with? Does it work with XFS? Because afaik XFS cannot be shrunk, so how is one supposed to put the LUKS header in?

@inferenceus
Copy link
Contributor Author

I used it with Btrfs. There is an argument (--reduce-device-size) to automatically shrink the partition to allow the header to fit. I used --reduce-device-size 16M for a 16 MiB shrink and the header fit there when running reencrypt --encrypt.

@wj25czxj47bu6q wj25czxj47bu6q added the [c] update existing Existing content updates (beyond trivial fixes) label Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[c] update existing Existing content updates (beyond trivial fixes)
Development

No branches or pull requests

3 participants