[SOLVED] Creating a separate encrypted /home partition?

[saturnalia0]

Given recent events in my country, I believe it to be in my best interest to have my devices encrypted. My first instinct was to go with FDE, but AFAIK that would require a fresh install and has its own set of pitfalls. So I'm thinking about creating a separate partition for my /home and have only that encrypted. Maybe it's not the best, and I accept any comments on that, but I think it would fit my threat model of having things like the browser folder encrypted when I turn off my device. That being said, I found the following wiki page:

https://wiki.gentoo.org/wiki/Encrypt_a_ ... h_ECryptfs

As far as I understand, this does not create a new encrypted partition for /home, rather, it just creates an encrypted mount point. Which may be fine, but I wonder if a separate partition wouldn't be better? In the sense that things are then truly isolated. Sorry but I'm a bit of a noob when it comes to anything but file-level encryption. Any guidance is appreciated.

[pietinger]

Maybe read this thread
viewtopic-t-1169021.html

I am using fscrypt as mentionend in my post there. fscrypt also has the great advantage that it comes with a pam_fscrypt.so, which ensures that the /home directory (or every directory you want = you have encrypted) is also unlocked at the same time as the login (so you don't need two logins/password inputs).

[saturnalia0]

Thanks, I'll review that. I actually suggested some file-level encryption there myself, but I didn't remember the thread. I'll review your suggestion

[arran4]

There seems to be work on per-file / folder encryption going, I was watching https://www.youtube.com/watch?v=6YIc2fVLVPU talk about it. I believe homed can do this on btrfs (using fscrypt.)

[mega_flow]

Or Systemd homeD . that 1 can encrypt too .Using for more ten a year now and work fine for me

[lars_the_bear]

I'm a long-term user of ecryptfs and, while I'm aware of problems with it, it's hugely convenient.

In my view, anything short of whole-disk encryption of all storage devices runs the risk of a false sense of security. You need to keep track of every place that sensitive content might be written, and ensure that's in an encrypted container of some sort. Many applications write temporary and working files in all sorts of places -- /tmp, hidden directories under $HOME, and so on. And, if you're really paranoid, you need to wonder about what's going into the swap partition, if you have one.

I believe that all forms of per-directory or per-partition encryption are quite weak. But they're strong enough for the threats I believe I face in my personal use of a computer. For business I always use whole-disk encryption. I'd do the same for my home computers, if I felt that I was genuinely exposed to governmental or military threats.

BR, Lars.

[saturnalia0]

So, my understanding is fscrypt is file-level encryption using the crypto support from the kernel.

This section from Arch wiki on fscrypt seems insightful:

Alternatives [to fscrypt] to consider

To protect an entire file system with one password, block device encryption with dm-crypt (LUKS) is generally a better option, as it ensures that all files on the file system are encrypted, and also that all file system metadata is encrypted. fscrypt is most useful to encrypt specific directories, or to enable different encrypted directories to be unlockable independently—for example, per-user encrypted home directories.

Compared to eCryptfs, the Linux native file encryption controlled by fscrypt does not use file system stacking, which makes it more memory-efficient. It also uses more up-to-date cryptography and does not require root privileges to set up, which avoids the need for setuid binaries. eCryptfs is also no longer being actively developed, and its largest users (Ubuntu and Chrome OS) have migrated to other solutions.

This comparison to eCryptfs, which I originally considered, is very much relevant.

Since I want to encrypt the entire /home (so not per-user), maybe dm-crypt would be a better alternative to fscrypt? Seems like I could apply my original plan of creating a new encrypted /home partition, copying my files there, then shredding the originals. I.e. use dm-crypt for block device level encryption on that partition (but not the whole disk, i.e. not FDE). This seems to be exactly the scenario covered here:

https://wiki.archlinux.org/title/Dm-cry ... #Partition

I think this is the way to go for me, with pam_mount to decrypt at login.

[simplycorbett]

I would personally just encrypt the entire drive or at least the / partition with /home.

If you want to encrypt just /home, my recommendation:

1) create a separate /home partition on a LUKS encrypted device
2) on boot when you get to the login screen change your terminal/monitor tty so you get a text session. Login as root (not the user and make sure root can be logged into).
3) unlock the encrypted home partition and mount it. Logout.
4) change your tty back to the login screen and proceed to login as normal.

You're done.

If you don't care about encrypting /boot, you can encrypted / as well. GRUB is able to unlock it. Make sure you make changes to your use flags so the system builds with support for this.

If you also want to encrypt /boot and the swap partition, it's a bit more complicated.

[simplycorbett]

As a side note if you boot up a livecd you can backup the entire home directory with this:

Code: Select all

cd /mnt/gentoo/home
tar -cvpzf backup.tar.gz --exclude=backup.tar.gz --one-file-system .
move file off partition

Once you recreate the home partition in luks and mount it, do the following:

Code: Select all

cd /mnt/gentoo/home
move file back
sudo tar -xvpzf backup.tar.gz -C . --numeric-owner

you're done.

[Hu]

Rather than create the file on the partition and then move it, why not create it where you want it to be? Likewise, there is no need to move the tar file back onto the encrypted partition before unpacking it.

[simplycorbett]

Rather than create the file on the partition and then move it, why not create it where you want it to be? Likewise, there is no need to move the tar file back onto the encrypted partition before unpacking it.

TBH I have very little understanding of the tar command. It’s just something I copy/pasted from an article years ago that works for me. I’ve kept it saved in my notes.

You’re right, you don’t have to move the file back. I use a storage server and use scp to move the file. If it’s on a locally mounted drive it should be okay.

[saturnalia0]

Just in case it's useful for anyone finding themselves here through a web search, this is what I ended up doing and worked well for me:

1. Create a /home partition in a new drive

For this just follow the handbook: https://wiki.gentoo.org/wiki/Handbook:A ... T_for_UEFI

Create the partition but not the filesystem.

2. Setup encrypted storage for the partition

Basically follow the wiki: https://wiki.gentoo.org/wiki/Dm-crypt

I've upgraded the wiki page with some details that I found useful.

3. Move to the new home

With the encrypted partition created, manually opened, and mounted to /mnt/home, copy the files to the encrypted home:

Code: Select all

rsync -av /home/ /mnt/home/
mv /home /old_home

Then finish dm-crypt setup per the aforementioned wiki, editing fstab such that the new encrypted home is auto-mounted to /home once the unencrypted UUID becomes available.

I've decided to move the old home and once I verified everything is working / after a baking period I intend to shred the old files (see https://wiki.archlinux.org/title/Securely_wipe_disk).

I did not need pam_mount in the end, as I'm prompted for the password on boot, which is fine for my single (physical) user setup.