+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: Linux on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=114)
+--- Thread: Encrypted disk (/showthread.php?tid=8008)
Pages:
1
2
Encrypted disk - jpakkane - 09-27-2019
Has anyone looked into running the pbpro with full disk encryption? It works really nicely on x86, but since the whole boot mechanism is different, there is no guarantee it will work out of the box.
Thanks,
RE: Encrypted disk - Arwen - 09-27-2019
(09-27-2019, 02:29 PM)jpakkane Wrote: Has anyone looked into running the pbpro with full disk encryption? It works really nicely on x86, but since the whole boot mechanism is different, there is no guarantee it will work out of the box.
Thanks,
One thing I plan to look into, is to use an encrypting file system like OpenZFS or BTRFS. Both also allow alternate boot environments using snapshots, which save space. OpenZFS allows having an encrypted root filesystem, if the "/boot" is un-encrypted.
I've used LUKS before, but there are certain advantages to FS managed encryption.
RE: Encrypted disk - Skywheel - 11-01-2019
(09-27-2019, 04:22 PM)Arwen Wrote:(09-27-2019, 02:29 PM)jpakkane Wrote: Has anyone looked into running the pbpro with full disk encryption? It works really nicely on x86, but since the whole boot mechanism is different, there is no guarantee it will work out of the box.
Thanks,
One thing I plan to look into, is to use an encrypting file system like OpenZFS or BTRFS. Both also allow alternate boot environments using snapshots, which save space. OpenZFS allows having an encrypted root filesystem, if the "/boot" is un-encrypted.
I've used LUKS before, but there are certain advantages to FS managed encryption.
I'm highly interested in any how-to for such encryption for PBP as well.
RE: Encrypted disk - Solra Bizna - 11-01-2019
I was able to set up crypttab just like on other arches and it works great, BUT I had to build a custom version of mrfixit2001's kernel with DM_CRYPT enabled in the config, and create and configure an initramfs. Not the most newbie-friendly way to do full disk encryption, but it proves that it's possible.
RE: Encrypted disk - Der Geist der Maschine - 11-03-2019
Getting filesystem encryption up and running on Debian was more effort than I thought. It should be easier on Ubuntu as it comes with a dm-crypt module and an initrd.
My notes on how I encrypted the /home partition on Debian are available on my website (click on the website icon below). You definitely need to understand what you are doing.
By setting up filesystem encryption, you lose the ability to run MrFixIT's update script as this takes the liberty to overwrite files which I replaced a/o edited. You need to manually merge his updates from then on.
RE: Encrypted disk - jpakkane - 11-04-2019
If encrypting just the home directory is enough (and for most people it is), then ecryptfs is an option. It won't work on the Debian image, though, because the required kernel module is not available.
RE: Encrypted disk - Der Geist der Maschine - 11-04-2019
(11-04-2019, 11:02 AM)jpakkane Wrote: If encrypting just the home directory is enough (and for most people it is), then ecryptfs is an option.
I have to admit I have never heard of eCryptfs.
Benchmarks: https://www.phoronix.com/scan.php?page=article&item=ext4-crypto-418&num=1: eCryptfs is slower and has a higher cpu overhead.
Functionality:
ECryptsfs can't encrypt swap.
ECryptfs does not require a dedicated partition. That's not a problem on my desktop where I have lots of hard disk space, but a big plus on my Pinebook Pro where I can't afford to "lose" diskspace by having free diskspace on the wrong partition.
By the way, what does one gain by full-disk encryption? The term is misleading as one does not encrypt the /boot partition including the kernel and initrd.
If one wants to prevent someone from tempering with the root filesystem, then that's also possible by replacing the initrd with one that that includes a backdoor. The backdoor can modify the root filesystem right after it's unencrypted and before the boot continues.
(11-04-2019, 11:02 AM)jpakkane Wrote: It won't work on the Debian image, though, because the required kernel module is not available.
There is no voodoo magic in building the right kernel module.
RE: Encrypted disk - lordcirth - 11-04-2019
Quote:By the way, what does one gain by full-disk encryption? The term is misleading as one does not encrypt the /boot partition including the kernel and initrd.
If one wants to prevent someone from tempering with the root filesystem, then that's also possible by replacing the initrd with one that that includes a backdoor. The backdoor can modify the root filesystem right after it's unencrypted and before the boot continues.
A number of things, compared to filesystem-layer encryption:
- While you can keep all private data in your homedir, it's easy to leak outside that - /var/log, swap, /etc, /tmp, etc.
- Performance & reliability - dm-crypt translates one block device to another. eCryptFS has to implement a POSIX filesystem that saves to another POSIX filesystem.
- Metadata leakage: while eCryptFS encrypts filenames, the directory structure, file count, file size, etc is all preserved in the encrypted version. If I can see that you have a directory with around 1000 files in it, whose directory structure and file sizes match an untarred torbrowser.tar.gz, that's information.
RE: Encrypted disk - Der Geist der Maschine - 11-05-2019
You answered what I was asking for but not what I meant
I was interested in the advantage of luks / over luks /home. I think that boils down to:
Quote:While you can keep all private data in your homedir, it's easy to leak outside that - /var/log, swap, /etc, /tmp, etc.
Swap can be trivially encrypted with luks as well. /tmp can be made a memory filesystem - that's not the default in our Debian, though. It's really not great exposing /var/log and /etc.
RE: Encrypted disk - lordcirth - 11-06-2019
(11-05-2019, 08:56 PM)Der Geist der Maschine Wrote: You answered what I was asking for but not what I meant
I was interested in the advantage of luks / over luks /home. I think that boils down to:
Quote:While you can keep all private data in your homedir, it's easy to leak outside that - /var/log, swap, /etc, /tmp, etc.
Swap can be trivially encrypted with luks as well. /tmp can be made a memory filesystem - that's not the default in our Debian, though. It's really not great exposing /var/log and /etc.
Yeah, so LUKS on home+swap is in between FDE and eCryptFS /home. However, on my PCs I generally use a Btrfs or ZFS root partition, with a subvolume for /home. This allows space to be shared freely between /, /home, and other volumes, unlike partitioning. So I have a small /boot, and everything else is in one partition (swap is a file on /). So FDE is simpler and more convenient, IMHO.