Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wipe passfile before deletion for better security? #14

Closed
phpony opened this issue Jan 24, 2024 · 2 comments
Closed

Wipe passfile before deletion for better security? #14

phpony opened this issue Jan 24, 2024 · 2 comments

Comments

@phpony
Copy link
Contributor

phpony commented Jan 24, 2024

Providing master password to gocryptfs via temporary file may rise some security concerns.

Current workflow is:

  1. Create passfile with plain password in it: var temp_file = File.new_tmp (null, out ps);
  2. Provide passfile to gocryptfs via -passfile option.
  3. Delete passifle: pfile.delete ();

Simple delete () may not be enough in this case, because this temporary file will probably be recoverable for some time (using ext4magic for example). We should either use some kind of "wipe then delete" scenario or implement some kind of virtual passfile.

@moson-mo
Copy link
Owner

Yeah. Now most distros mount /tmp as tmpfs which should usually only reside in RAM I would assume (unless data being swapped to a disk maybe). That being said, not sure how much of a concern that still is. Dunno if simply overwriting the file content with some random garbage multiple times (before deleting it) would be any beneficial (on the other hand, it doesn't really harm either).

Did you actually try to recover it (just curious 😉)?

@phpony
Copy link
Contributor Author

phpony commented Jan 24, 2024

Welp I was able to recover it only with specific TMPDIR environment variable pointing to non tmpfs storage. So it looks like you need to intentionally seriously mess your system for someone be able to exploit his. File.new_tmp relies on get_tmp_dir which is /tmp by default which is tmpfs by default so there's no way to recover deleted files from there. So it is safe.

And If someone is able to grab your tmp file in 1 second between it's creation, passing to gocryptfs and deletion - you have way more serious security problems and it's also unsafe for you to type your password directly into gocryptfs cli.

@phpony phpony closed this as completed Jan 24, 2024
Repository owner locked and limited conversation to collaborators Jan 24, 2024
@moson-mo moson-mo converted this issue into discussion #15 Jan 24, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants