5 ms·

Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all thi

by nly 11y ago

Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. I like to keep things simple (which is why I use syslinux instead of GRUB as a bootloader. GRUB2 is ugly as sin to configure) On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.

darkr 11y ago
> Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?
- nly 11y ago
  If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.
  - mingus68040 11y ago
    And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.
    - nly 11y ago
      I mainly encrypt in case of theft, /boot contains nothing valuable. / contains a lot of information about my configuration, and installed packages, as well as the key to /home
      - ultramancool 11y ago
        Yeah, encrypting for theft or so you have piece of mind while the machine is off but in sight is a completely valid use case. It all depends on your threat model. In the case someone is taking the machine from me while it is off (ie: most theft or legal problems), I have a chance given FDE. In case someone has physical access to the machine without me around, I have little to no chance, no matter what I do. A threat model which includes an attacker having potential physical access to a machine to perform an evil maid or other blackbag cryptanalysis is a threat model which is very difficulty to accommodate, and indeed replaced boot files are just the start of your problems. A threat model without this however, has no reason to necessitate secure boot. As such, I see no gain in using UEFI or SecureBoot as this guide outlines. It worries me that the author didn't consider a realistic threat model when writing this guide. This guide also suggests: > Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk. So it's highly confusing what sort of threat model the author had envisioned this to be written for.
SmellyGeekBoy 11y ago
It certainly makes sense from a security standpoint, but is there any additional overhead to encrypting swap? This is the first time I've ever seen it mentioned as a security measure.
- Skunkleton 11y ago
  In theory anything could be in ram could also end up in swap. So yes, it is important. And yes, there is overhead, but it isn't too bad if your system isn't RAM constrained, and your CPU supports AES-NI or similar.
- ams6110 11y ago
  Modern systems have enough ram that swap is not much used. If it becomes necessary, the overhead of encrypting will be the least of your concerns. If your system is swapping, it's crawling anyway.
- yellowapple 11y ago
  Ideally, you wouldn't even have a dedicated swap partition. No data is always more secure than even the most perfectly-encrypted data. If you do have swap, though, then the encryption probably won't matter much compared to the fact that your machine is swapping in the first place.
  - vonuebelgarten 11y ago
    Hibernation is a very nice feature (I use it for laptop and desktop machines) and it requires a swap partition. Also, a encrypted swap is even more important in this scenario. In the laptop I'm typing this, swap is one of the partions over a LVM2 physical volume over LUKS.
    - yellowapple 11y ago
      That's why I sad "ideally" :)
dfc 11y ago
You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.
- hueving 11y ago
  >I really do not understand the point of encrypting a subsection of your drive. To prevent people from reading sensitive data on a stolen/lost laptop.
- jokr004 11y ago
  I'm assuming he specifically mentioned encrypting /home because it's on a different partition/disk? I'm guessing /usr is on the root partition which he said he encrypts.
- darkr 11y ago
  I guess that /usr is probably on the same partition as his root.. But depending on the distro, and how the system is managed; it may be the case that every single file in /usr comes from a package, and can be cryptographically verified using your package manager (this is certainly possible with RedHat, Debian + derivatives at least). As long as /var or wherever your package DB lives is encrypted..
- nly 11y ago
  Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.
  - dfc 11y ago
    Have you never used more than one disk in a machine? Locked out of a machine because /var/log is full?
    - nly 11y ago
      More the one disk -> LVM And no, only /tmp has reached capacity for me when building large packages with Archs makepkg.
jszymborski 11y ago
Self-Destructing Cookies is an absolute must. It's fantastic practice that makes sure that you don't have any cookies persisting longer than they should, and really reduces your footprint.

by nly 11y ago

darkr 11y ago

> Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?

nly 11y ago
If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.
- mingus68040 11y ago
  And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.
  - nly 11y ago
    I mainly encrypt in case of theft, /boot contains nothing valuable. / contains a lot of information about my configuration, and installed packages, as well as the key to /home
    - ultramancool 11y ago
      Yeah, encrypting for theft or so you have piece of mind while the machine is off but in sight is a completely valid use case. It all depends on your threat model. In the case someone is taking the machine from me while it is off (ie: most theft or legal problems), I have a chance given FDE. In case someone has physical access to the machine without me around, I have little to no chance, no matter what I do. A threat model which includes an attacker having potential physical access to a machine to perform an evil maid or other blackbag cryptanalysis is a threat model which is very difficulty to accommodate, and indeed replaced boot files are just the start of your problems. A threat model without this however, has no reason to necessitate secure boot. As such, I see no gain in using UEFI or SecureBoot as this guide outlines. It worries me that the author didn't consider a realistic threat model when writing this guide. This guide also suggests: > Unless you have concerns about physical security, it is fine to write down your passphrases and keep them in a safe place away from your work desk. So it's highly confusing what sort of threat model the author had envisioned this to be written for.

SmellyGeekBoy 11y ago

It certainly makes sense from a security standpoint, but is there any additional overhead to encrypting swap? This is the first time I've ever seen it mentioned as a security measure.

Skunkleton 11y ago
In theory anything could be in ram could also end up in swap. So yes, it is important. And yes, there is overhead, but it isn't too bad if your system isn't RAM constrained, and your CPU supports AES-NI or similar.
ams6110 11y ago
Modern systems have enough ram that swap is not much used. If it becomes necessary, the overhead of encrypting will be the least of your concerns. If your system is swapping, it's crawling anyway.
yellowapple 11y ago
Ideally, you wouldn't even have a dedicated swap partition. No data is always more secure than even the most perfectly-encrypted data. If you do have swap, though, then the encryption probably won't matter much compared to the fact that your machine is swapping in the first place.
- vonuebelgarten 11y ago
  Hibernation is a very nice feature (I use it for laptop and desktop machines) and it requires a swap partition. Also, a encrypted swap is even more important in this scenario. In the laptop I'm typing this, swap is one of the partions over a LVM2 physical volume over LUKS.
  - yellowapple 11y ago
    That's why I sad "ideally" :)

dfc 11y ago

You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.

hueving 11y ago
>I really do not understand the point of encrypting a subsection of your drive. To prevent people from reading sensitive data on a stolen/lost laptop.
jokr004 11y ago
I'm assuming he specifically mentioned encrypting /home because it's on a different partition/disk? I'm guessing /usr is on the root partition which he said he encrypts.
darkr 11y ago
I guess that /usr is probably on the same partition as his root.. But depending on the distro, and how the system is managed; it may be the case that every single file in /usr comes from a package, and can be cryptographically verified using your package manager (this is certainly possible with RedHat, Debian + derivatives at least). As long as /var or wherever your package DB lives is encrypted..
nly 11y ago
Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.
- dfc 11y ago
  Have you never used more than one disk in a machine? Locked out of a machine because /var/log is full?
  - nly 11y ago
    More the one disk -> LVM And no, only /tmp has reached capacity for me when building large packages with Archs makepkg.

jszymborski 11y ago

Self-Destructing Cookies is an absolute must. It's fantastic practice that makes sure that you don't have any cookies persisting longer than they should, and really reduces your footprint.