I agree with the sentiment to use swapfiles rather than swap partitions -- the flexibility is appealing (though in practice I rarely need to change the dimensions of mine) and the lack of measurable difference in performance over partitions removes any arguments in favour of dedicated partitions anymore.
But on my secure systems everything other than /boot is encrypted on, so I get encrypted swapfiles just by creating them as /swapfile.x -- I have a saltstack recipe that creates these on new installs automatically now, too, and that doesn't need to be changed for encrypted or non-encrypted root file systems.
The automatic creation of these (and decommissioning them later) based on ephemeral memory usage requirements is an interesting idea, and it's a shame the author hasn't gotten to that point yet. I wonder how useful that'd be in practice, though, especially in an era of 'disk is cheap'.
FWIW it's not specific to systemd -- I've been using /etc/crypttab for full-disk encryption (LUKS) for a few years on Ubuntu. The file is consulted when building the initrd, to build in whatever magic is needed to decrypt the disks at boot.
Another alternative: Self Encrypting Drives (which can be managed on Linux with hdparm).
I'm using this currently on my XPS 13 (2015). Works great. However given the architecture of SED and its implementation in this case, it's not as trustworthy as LUKS, for example.
For general laptop security not involving government intervention, I consider it good enough.
I can believe it. On the XPS 13, even when modifying or NULLing the master password on the internal sata drive, the unit's BIOS will reassign the BIOS (UEFI) admin password as a valid SED drive password, with no user intervention.
It's really just an 'in case of (casual) theft' level of encryption as far as I'm concerned. Good enough on the systems I'm using it on. For everything else, there's LUKS.
For a second I thought it was going to be a short article about installing OpenBSD which encrypts the swap by default since version 3.9 (released 2006). It also encrypts different areas of swap with different keys and, when a particular area isn't needed anymore, the key is erased.
7 comments
[ 4.2 ms ] story [ 24.1 ms ] threadI agree with the sentiment to use swapfiles rather than swap partitions -- the flexibility is appealing (though in practice I rarely need to change the dimensions of mine) and the lack of measurable difference in performance over partitions removes any arguments in favour of dedicated partitions anymore.
But on my secure systems everything other than /boot is encrypted on, so I get encrypted swapfiles just by creating them as /swapfile.x -- I have a saltstack recipe that creates these on new installs automatically now, too, and that doesn't need to be changed for encrypted or non-encrypted root file systems.
The automatic creation of these (and decommissioning them later) based on ephemeral memory usage requirements is an interesting idea, and it's a shame the author hasn't gotten to that point yet. I wonder how useful that'd be in practice, though, especially in an era of 'disk is cheap'.
I'm using this currently on my XPS 13 (2015). Works great. However given the architecture of SED and its implementation in this case, it's not as trustworthy as LUKS, for example.
For general laptop security not involving government intervention, I consider it good enough.
It's really just an 'in case of (casual) theft' level of encryption as far as I'm concerned. Good enough on the systems I'm using it on. For everything else, there's LUKS.