[ckennelly]

Thanks for taking a look.

To go through your points:

* If the "wrong" GPG binary is loaded, the game is likely already up: If an attacker has that degree of control over your machine, they're already on the other side of this airtight hatchway. They can attach to your running programs, read memory contents, and so forth, so compromising the GPG binary isn't necessary.

* Keys are handled by GPG, which normally should mlock key material.

* Part of my plan to switch to handling pages (rather than allowing data to be managed via a std::string) was to be able to use mlock() properly. I'll be adding that soon.

* Since the GPG binary is running as you, it could do Bad Things to the underlying filesystem (or filesystem exported by FUSE), but you do raise a point about closing file descriptors for general cleanliness.

[jude-]

Thanks for your reply. Just a couple of other things:

First, I see from your code that you don't specify an absolute path to gpg. If I can write to a directory in your PATH that gets searched before the location of your desired gpg binary, then I win. Depending on your PATH, I don't need privileges or even a user account--for example, using a browser exploit or some social engineering, I could drop a poisoned gpg into your Downloads directory (or anywhere in your /home or /tmp), and if your PATH searches in your /home first (or searches '.' first), I could get you to use my gpg instead.

Second, regarding preventing plaintext from getting swapped to disk before writing, you have to keep in mind that libfuse will obtain the plaintext from the kernel and then call your write() callback--you're not safe if you only mlock() the data that FUSE gives you, since the data could have swapped to disk between libfuse reading from the kernel and calling write(). Now, I don't know if libfuse mlock's the write buffer first (maybe it's a side-effect of FUSE splicing pages between the kernel and application?), but it is something to keep in mind.