5 ms·

I'm most amused by this comment in the original post: (Context: the discussion is around the drawback that memfd_secret must disable hibernation) > That's why

I'm most amused by this comment in the original post: (Context: the discussion is around the drawback that memfd_secret must disable hibernation) > That's why the only way to introduce new security feature is with “more security” choice being the only option. > ... eventually, Chrome and Firefox would join the crowd. At that point it would become a moot point if you want to use hibernation or not: you system wouldn't be much useful if you would choose the hibernation. Always interesting to see how ignorant some "security experts" are and how they love to hijack users and sabotage user experience using the excuse of "security".

captainmuon 5y ago
The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password. This would require some cooperation with the login program, and maybe with the user app, so it's hard to organize in the Linux world. I think something like this is available on Windows, but I'm not sure. It would be also great if you could use the graphical login (greeter) to decrypt your disk (at boot or after sleep). I think some of the neccessary infrastructure would be the same for both features.
- api 5y ago
  Why can’t the kernel just generate a random secret at boot and encrypt swap and hibernate files automatically? MacOS does this. I thought Linux did already. With AES in hardware it’s not much more costly than memcpy.
  - jchw 5y ago
    This is done for Linux Lockdown. For memfd_secret, it might not be considered good enough; I think the memory needs to be evicted.
    - api 5y ago
      What is the threat model for this? If it’s a highly advanced attacker with physical access not even that is good enough. The best we can do is a true hardware enclave.
- josephcsible 5y ago
  > The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password A third option: do neither, and just accept that hibernation temporarily drops the security guarantees that the feature usually offers.
  - Arrath 5y ago
    I would think that a temporary loss of security guarantee is tantamount to a complete loss of security guarantee.
    - josephcsible 5y ago
      Isn't this built to protect against stuff like Spectre, not arbitrary kernel code execution? Couldn't the order of operations be suspend all user processes, do CPUID on every core (i.e., stop all speculative execution), unprotect the memory, save everything to disk, and then the reverse to wake back up?
- yencabulator 5y ago
  Here's how your typical Linux desktop app can be notified of an upcoming hibernation, and prepare accordingly: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ (I'm assuming hibernation is not a requirement outside of the desktop space.)
rfoo 5y ago
Real "security experts" do know that a security feature had to be usable :)
api 5y ago
Good security experts know a security feature can’t sabotage usefulness or usability or people won’t use it. Another gripe I have about infosec people is that they tend to fear the wrong things. They tend to be paranoid about the minutia of network firewalls and encryption while ignoring the fact that most compromises are inbound and due to malware or phishing. They will obsess over how “smooth” the firewall is, then type “npm install” as root on production.
- staticassertion 5y ago
  There's a lot of "security experts" getting thrown around here. None of my peers in security would tell you that malware/ phishing are anything other than the #1 threat to your organization 99% of the time. We all have dealt with stupid security people just as we've all dealt with stupid people in general. It's unfortunate but competency is on a power curve across disciplines.

captainmuon 5y ago

The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password. This would require some cooperation with the login program, and maybe with the user app, so it's hard to organize in the Linux world. I think something like this is available on Windows, but I'm not sure. It would be also great if you could use the graphical login (greeter) to decrypt your disk (at boot or after sleep). I think some of the neccessary infrastructure would be the same for both features.

api 5y ago
Why can’t the kernel just generate a random secret at boot and encrypt swap and hibernate files automatically? MacOS does this. I thought Linux did already. With AES in hardware it’s not much more costly than memcpy.
- jchw 5y ago
  This is done for Linux Lockdown. For memfd_secret, it might not be considered good enough; I think the memory needs to be evicted.
  - api 5y ago
    What is the threat model for this? If it’s a highly advanced attacker with physical access not even that is good enough. The best we can do is a true hardware enclave.
josephcsible 5y ago
> The solution is to either encrypt or evict the secret memory on hibernation, and then decrypt it or have the app derive the secrets again when the user enters their password A third option: do neither, and just accept that hibernation temporarily drops the security guarantees that the feature usually offers.
- Arrath 5y ago
  I would think that a temporary loss of security guarantee is tantamount to a complete loss of security guarantee.
  - josephcsible 5y ago
    Isn't this built to protect against stuff like Spectre, not arbitrary kernel code execution? Couldn't the order of operations be suspend all user processes, do CPUID on every core (i.e., stop all speculative execution), unprotect the memory, save everything to disk, and then the reverse to wake back up?
yencabulator 5y ago
Here's how your typical Linux desktop app can be notified of an upcoming hibernation, and prepare accordingly: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ https://www.freedesktop.org/wiki/Software/systemd/inhibit/ (I'm assuming hibernation is not a requirement outside of the desktop space.)

rfoo 5y ago

Real "security experts" do know that a security feature had to be usable :)

api 5y ago

Good security experts know a security feature can’t sabotage usefulness or usability or people won’t use it. Another gripe I have about infosec people is that they tend to fear the wrong things. They tend to be paranoid about the minutia of network firewalls and encryption while ignoring the fact that most compromises are inbound and due to malware or phishing. They will obsess over how “smooth” the firewall is, then type “npm install” as root on production.

staticassertion 5y ago
There's a lot of "security experts" getting thrown around here. None of my peers in security would tell you that malware/ phishing are anything other than the #1 threat to your organization 99% of the time. We all have dealt with stupid security people just as we've all dealt with stupid people in general. It's unfortunate but competency is on a power curve across disciplines.