Re: Advice on encrypted filesystem
Thanks -- very helpful! I mayb have some more questions as I triy to digest
this, but can't spend time on it today.
Nothing new below this line.
On Friday, June 26, 2020 09:25:49 AM David Wright wrote:
> On Thu 25 Jun 2020 at 07:40:43 (-0400), rhkramer@gmail.com wrote:
> > On Wednesday, June 24, 2020 10:20:55 PM David Wright wrote:
> > > On Wed 24 Jun 2020 at 21:28:38 (-0400), rhkramer@gmail.com 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[9]
>
> Partitioning is conventional.
>
> # gdisk /dev/sdz
>
> [… etc …]
>
> Creating the encrypted partition.
>
> # cryptsetup --align-payload 2048 luksFormat /dev/sdz9
>
> WARNING!
> ========
> 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).
>
> Finally:
>
> # 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?
> >
> > No.
>
> 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,s
> ize=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.)
>
> Cheers,
> David.
Reply to: