Ask HN: Are there wrapper/runner programs that encrypt writes and decrypt reads?

Are there any wrapper programs that run a program and make the program transparently encrypt its writes and decrypt its reads?

i.e. with the program launched being oblivious to the fact that the file it is reading from and writing to, is in fact encrypted on disk (on top of a file system, what could be an unencrypted file system)

I'm specifically interested in being able to run a program with a wrapper program, type a password, and only that process that is started being able to read from and write to the file, transparently (I don't want to use file permissions to limit which processes can read from or write to the file)

Oh and by the way, I know disk encryption file systems exist, I use LUKS, not really what I'm asking about.

I've done some searches and I was only able to find FUSE filesystems that can transparently encrypt files on top of a file system, they work by initializing a directory, to store the encrypted files in, and then mounting that directory to a FUSE filesystem mount point, a mount point where any process can access and read or write (if one doesn't leverage file-system permissions, which is not what I'm looking for)

Here's a useful page that talks about and compares these open-source file encryption solutions (gocryptfs, encfs, ecryptfs, cryptomator, securefs, CryFS): https://nuetzlich.net/gocryptfs/comparison/ (https://archive.is/gMwpV)

Inspiration to think of using such a program came from reading about NixGL[1], a program that wraps and runs programs (programs installed with Nix on a distro that is not NixOS), to make OpenGL or Vulkan applications able to run and work on distros that are not NixOS, it works like this:

  $ nixGL program
  $ nixVulkan program
I imagine this program does some things so the program it wraps/runs correctly loads the right graphics driver libraries, something that's not really analogous to changing the behavior of file-system operations (I think).

What would it take/require to change the behavior of file-system operations/syscalls/APIs in a program (besides recompiling it)? syscalls or APIs like fopen(), write(), fsync(), fflush(), fclose(), FlushFileBuffers() (on Windows).

How can a program accomplish this? by using/doing something like virtualization? emulation? syscall/API translation? e.g. like WINE?

  [1] https://github.com/nix-community/nixGL

6 points | by wesamco 11 days ago

6 comments

  • cpach 10 days ago
    I assume that in this scenario we don’t want to change the behaviour (program code, source code) of the application itself.

    Why is it important that the syscalls (write et al) encrypts? (Even if they do so only under the hood.) Is it not sufficient that the application writes to a place that is encrypted?

    It’s probably not impossible to modify the syscalls, but I think it would be vastly easier to let the outside system handle the encryption.

    “I was only able to find FUSE filesystems that can transparently encrypt files on top of a file system”

    I believe the reason that you mostly found such solutions is that they are much more “cost-effective” than implementing a system that operates on the syscall level.

    If you need to ensure that the application writes only to the specific mountpoint you can probably use some kind of “jail” to achieve that. Here’s a decent starting point on that: https://blog.mnus.de/2020/05/sandboxing-soldatserver-with-bu... (assuming that the application runs on Linux)

  • solardev 10 days ago
    Can't you just run the program inside a VM of some sort and encrypt the whole image that way? I guess during runtime the contents in RAM won't be encrypted, but when the image gets saved back to disk, it should be.

    e.g. in Parallels, they have built-in AES-based password VM encryption: https://kb.parallels.com/8832

    Or in VirtualBox: https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm...

    [-]
  • nrdxp 10 days ago
    You would have to be able to overwrite a syscall in userspace (which would be a massive security hole) or have some kinda kernel driver (but you said disk encryption doesn't work for some odd reason, otherwise that's your solution right there).

    I guess, as you stated, you might be able to write a fuse application to do it, but I don't see the benefit over just an encrypted disk.

    [-]
    • stop50 10 days ago
      It would be possibe'le, but its very easy to shoot yourself in the foot with that.
  • helpfulfrond 10 days ago
    FHE is interesting: https://en.m.wikipedia.org/wiki/Homomorphic_encryption
    [-]
    • cpach 10 days ago
      Sure, but how does it help in this specific scenario?
  • stop50 10 days ago
    Maybe something like ext4 transparent encryption?