Re: Advice on encrypted filesystem
On Thu 25 Jun 2020 at 07:40:43 (-0400), email@example.com wrote:
> On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote:
> > On Wed 24 Jun 2020 at 21:28:38 (-0400), firstname.lastname@example.org wrote:
> > > On my Wheezy system, I used cryptsetup to set up a LUKs encrypted file
> > > system on a dedicated partition
> > What were the contents of this partition: the OS itself, or /home,
> > or an independent filesystem that you'd probably mount under /media?
> an independent filesystem mounted as a top level directory
Then I can't see any point in involving the Debian installer.
Some of the details depend on what scripts you use to unlock
and mount. My own method for creating a filesystem is
(from my notes):
If encrypting an entire disk, scramble the disk first, then partition.
If only encrypting a partition, partition the disk first.
Alignments should be at least 2M (4096 x 512B sectors).
Scramble any sensitive pre-existing contents:
# dd bs=1M if=/dev/urandom of=/dev/sdz
Partitioning is conventional.
# gdisk /dev/sdz
[… etc …]
Creating the encrypted partition.
# cryptsetup --align-payload 2048 luksFormat /dev/sdz9
This will overwrite data on /dev/sdb1 irrevocably.
[… etc …]
Add more passphrases:
# cryptsetup luksAddKey /dev/sdz9
[… etc …]
Create the filesystem:
# cryptsetup open --type luks /dev/sdz9 thename
# mkfs.ext4 -L name09 /dev/mapper/thename
[… etc …]
# e2label /dev/mapper/thename name09 (if forgotten above).
# cryptsetup luksClose thename
(I mangle the device names to make copy/paste less dangerous.)
> (I have some scripts to allow me to easily open (and close) those filesystems
> -- when they open, the unencrypted content is put on a ramdisk (with the
> intent if somebody gets physical possession of the device (which is a desktop,
> not a laptop), the enencrypted data disappears on power off.)
As I encrypt /home, it wouldn't make sense for me to copy it all.
I assume that nobody's going to freeze my PC when they steal it.
My scripts use LABELled filesystems (as seen above), so there's nothing
unusual about /etc/fstab; and I unlock with udisksctl, using the
/dev/disk/by-partlabel value, so there's no entry in /etc/crypttab.
> Well, the Buster system is a laptop, Jessie is a desktop. I don't plan to put
> much, if any, sensitive data on the laptop. (I don't really even intend to
> take the laptop out of the house, especially during this Covid thing -- I
> installed Buster on it because I needed GCC 7+ and couldn't (easily) do that
> on the Wheezy or Jessie systems.
> > Do you use suspend?
Then you could encrypt swap with a random key. My method for that
is unusual, in that the swap partition is specified in fstab by
its (tiny) filesystem's LABEL. Its /etc/crypttab is thus fixed:
swap LABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512
> > Desktops?
> See above.
> > Do you boot them remotely?
> No, but they do stay up 24/7 unless there is a (longer that 2 minute (power is
> UPS supported)) power outage, or a (very rare) reboot.
OK. This only really matters if you're encrypting /home (as I do)
or the system itself, as you then need a method of supplying the
passphrase before any users can login. (I use a pseudo-user whose
~ is in /var/local/home/ with a crafted .bash_profile.)