1

I am having trouble finding an answer to a question about protecting unencrypted data. I run Ubuntu 12.04. Although I'm not sure that it's relevant, I'll also mention that I use an encrypted home directory (and thus also have encrypted Swap space) but do not use full-disk encryption. My hard drive is formatted with ext4.

I have a text file that contains some application passwords. I keep this file encrypted using GPG. Whenever I want to edit the passwords in the file, I use GPG to write the decrypted contents to disk, edit the text in my favourite text editor (currently, Gedit), have GPG re-encrypt the file, and then rm the unencrypted version.

Recently, I've realized that in being written to disk, the unencrypted text could possibly be read from the disk itself if it's not overwritten. I realize that shred really doesn't work for this purpose with a journaling filesystem like ext4. I read at https://stackoverflow.com/a/12289967 that it's possible to write the unencrypted file to a tmpfs -- i.e., directly to RAM or Swap space. The post that I linked to suggests using /dev/shm; however, my understanding is that that directory is intended to be used for shared memory operations, and has also been deprecated in favor of /run/shm. It sounds like writing to /run might be a better idea, then.

If I were to write the decrypted file to /run (or, for that matter, to /dev/shm), would there be any adverse consequences? Would the file be protected more than if it were written straight to disk (like I've been doing)? Is writing to those directories a bad idea for reasons I don't even know to think of?

I'll be very grateful for any advice that you can offer. Thank you!

3
  • "I have a text file that contains some application passwords. [...]" - Can you please explain why a password manager isn't working out for you? E.g. KeePassX. It's designed to overcome this issue (if it's well designed, not sure on this example in specific).
    – gertvdijk
    Jan 6, 2013 at 10:54
  • @gertvdijk , I haven't been using a password manager because it seemed easier to be able to send the encrypted plaintext file through email to a collaborator. If KeePassX or a similar program makes it easy and secure to send passwords to other computers, I would definitely be willing to check them out. I'll look into KeePassX this week; thank you! In the mean time (and, even if a password manager would work well, for curiosity's sake), would /run be a good directory to use for the temporary, unencrypted data? Thank you!
    – J L
    Jan 6, 2013 at 18:50
  • Good collaborative password managers are hard to find if you exclude browser-based ones. Ugly but working: Keepass 2.x (without the 'X') using Mono on Ubuntu, then store database on WebDAV store and you can real-time collaborate on it using entry-level based locking. :)
    – gertvdijk
    Jan 6, 2013 at 18:52

1 Answer 1

1

If I were to write the decrypted file to /run (or, for that matter, to /dev/shm), would there be any adverse consequences?

  • For your use-case (text files, which can't get very big), no.

Would the file be protected more than if it were written straight to disk (like I've been doing)?

  • You understand things correctly. Saving sensitive data to un-encrypted non-volatile magnetic media is a practice best avoided -- if there's an alternative.

Is writing to those directories a bad idea for reasons I don't even know to think of?

  • Nope. You're good to go. Just keep in mind that if you're writing directly to one of these tmpfs mount points, due-diligence would demand you make sure your shell umask is set appropriately when decrypting the file -- gpg could very well end up creating the decrypted file with world-readble permissions.

Lastly: I won't give any recommendations for password managers because I've never tried any; however, I did develop a comprehensive GnuPG/OpenSSL encryption (GUI) frontend written in Python that you might be interested in. It doesn't save any files to disk (or to tmpfs), unless you tell it to, and it can decrypt gpg-encrypted files, display their contents for viewing and editing, and then allow you to re-encrypt them. Check it out on github.

2
  • @ ryran, perfect; thank you for the point-by-point explanation! In addtion to @gertvdijk's KeePass recommendation, I'll keep in mind your Python GUI, which looks fantastic. I've never played around with changing the shell umask before. I'm doing some reading on it now. In the mean time, would writing a script that runs GPG to decrypt the file to /run and then immediately chmods that new file to, say, 110 (read and write, to my understanding), serve the same purpose as what you suggested? Thank you!
    – J L
    Jan 6, 2013 at 19:50
  • @JL RE umask: you simply need to run the command umask 177 (whether manually or from a script) to make it so that any files created in that shell have 600 perms (i.e., rw-------). You can do this manually, or from a script.
    – rsaw
    Jan 7, 2013 at 3:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .