My previous pc was stolen. It was in the hibernate state when it happened, an there were several encrypted containers open. Hence, the thief could be able to read from the swap data and find the required strings needed to decrypt those containers that were open. I’m looking for ways to avoid this for the future.
Is there an alternative to full disk encryption when the goal is to have hibernate data encrypted?
Full disk encryption may have some potential issues in my setup. What I’m afraid will cause issues is that I’m using ZFS with encryption on individual volumes, where only a few of the filesystems are open at the same time. I prefer to have a minimum of my data exposed, in case someone/something gets into my system. I only decrypt/mount those parts I need for what I’m doing at any given task. If I do full system encryption I guess I will run into issues with two layers of encryption. I’m not sure if that will cause issues or not?
The next idea that came to my mind is to store the hibernate data on a SD-card. That way the card could be taken out and put in a safe place. But I guess this will be way too slow to be practical.
In that state, the machine state is not kept in RAM, but written to swap and then powered off -
and if that swap is encrypted then the system can’t be brought back up again into that state
without supplying a key or a password.
Sleep state may be a different issue, but hibernate to encrypted swap should do what is expected.
If swap is not encrypted … well
the system is wide open then.
While shutdown is a simple thing to do, power on may be quite time consuming when you’re working on projects that requires a lot of things open at the same time.
I don’t think so.
Cause my startup may be open 15 different documents at a particular position,
Open a bunch of online documents at a particular position, that requires different sign-ins…
So I’d either
-have hibernate encrypt during the hibernation process (it does compress, maybe it could encrypt as well?)
-or encrypt the swap partition (how do you get resume to ask for password?)
-or encrypt the full disk. (does anyone have an idea if that will make issues with the encrypted zfs inside it?)
a better one would be in the reverse direction:
what does your current system look like?
zfs means it is custom built anyway
regardless of what file system is used,
suspend writes the machine state to disk (to swap)
and then powers down
If the swap is encrypted, you’ll need to supply a key or password.
If it is not encrypted - it will just resume …
Question is:
How did you set up your system?
Is your swap within the encrypted space like at least part of the rest of your system?
If not: why not?
(swap file vs swap partition - I know very little about zfs - about as much as I know about BTRFS, which is only a little more than nothing at all)
inxi -Fazy
has burnt itself into my memory - even though I know that this is not the most efficient one
My current system is supposed to arrive by mail today.
While waiting for it to arrive I’m trying to figure out how I would like to set it up.
The old system, that was stolen was set up like this:
p1: /boot ext2
p2: swap
p3: / ext4
p4 /home ext4
p5 zpool
p5-1 /home/username/enc/a ZFS z/a
p5-2 /home/username/enc/b ZFS z/b
p5-3 /home/username/enc/c ZFS z/c
p5-4 /home/username/enc/d ZFS z/d
…
From what I’ve been reading up on it should be possible to create partitions 1-4 during installation (leaving room for p5 unpartitioned), and enable encryption. Then when system is installed, I create p5 and zfs.
I don’t feel comfortable using ZFS as root. The installation process looked so complicated. Also ZFS does not support SWAP, at least it didn’t a couple of years ago, so it will need to be handled in some other way.
A couple of years ago there was an issue where openswap was not configured correct with btrfs.
Assuming you are a proficient linux admin - using zfs pool encrypted - Ignoring the btrfs - the concept is valid for any encrypted swap - just modify accordingly.
Thank you. That is a very interesting approach.
Two questions comes to my mind:
I notice Clevo N141 is one of the tested systems. If I assume N141 is similar to the L141 i bios, there is no option i bios to switch disk mode from RAID into AHCI. (You’ll need a hacked bios.) Do this way of installing manjaro not need bios set to AHCI?
Partition config looks like this:
# PARTITION CONFIGURATION VARIABLES
# partition order and size
_efi_part="1"
_efi_size="512M"
_root_part="2"
_root_size="256G"
_swap_part="3"
_swap_size="8G"
Is it so that the sum of sizes will need to be equal to disk total size? The sum here is 264.5GB. It looks like the intention is to install on a 256GB disk. Will the result be a 512M EFI, 8GB swap and “what ever is left” for root? Could I make the partitions smaller, leaving room for creating /home later?
The setup created in the PoC rewrites swap on boot - so it is not suited for hibernation - it will require additional tweaking but it is doable - I even tried but did not succeed - and I never use hibernation - so there is that.
I use sleep - s2idle - and there is no hickups as long as the system holds power.
You can adjust the values of root and swap as you see fit - I just used those values as my systems was running 512G disk.
Generally speaking it is recommended to use AHCI but sometimes loading e.g. the marvell drivers may provide support for software RAID. There is a section on Arch Wiki on the subject
The N141 provides SATA mode to be set to AHCI - the other options Intel Optane - unsupported on Linux - I bought without OS and it simply works with Manjaro.
I don’t know the L141 - it may be different - you may boot the installer, then check if the system identifies the disk device.
There is a place which provides various firmwares for Clevo - you may already know it - I don’t know if it is official - but the sheer amount of Clevo data suggests a tight connection to Clevo.
