Some geeky traditions did continue in 2020, including FOSDEM — the Free and Open Source Software Developers' European Meeting. The special 20th-anniversary edition still went off as scheduled in Brussels in early February, giving the community's developers a chance to hear from one another. And last week the videos finally appeared online — including a…

Interesting story about improvements to user’s home directories on Linux.

  • brombek@lemmy.ml
    0·
    4 years ago

    What I am saying is that if you have access to RAM (e.g. via https://en.wikipedia.org/wiki/IEEE_1394#Security_issues or in general https://en.wikipedia.org/wiki/DMA_attack) then not all content of your files is secure unless you “scrub” the entire content of RAM.

    So if you were to scrub page cache, loaded programs will still have some or all parts of the files loaded in RAM. E.g. my vim process will have some of my source code loaded. My SSH agent will have my keys loaded in RAM, my browser will have the very text you are reading loaded in RAM.

    So scrubbing keys from RAM will protect most of your data but not all of your data - false sense of security. So you better understand that trade-off before using such proposed system. It is still better than having you disk wide open but it will never be perfect.

    • federico3@lemmy.ml
      01·
      4 years ago

      the idea of erasing your LUKS key is kinda pointless … opened files in page cache

      So scrubbing keys from RAM will protect most of your data but not all of your data

      Now you are shifting the goalposts.

      This is not a design flaw in LUKS or in ACLs. Applications can be closed, the SSH agent can scrub its memory and so on.