#343 Saving the kill ring in .joe_state is a security risk
Imagine you are editing a file containing sensitive information, say a list of passwords, using joe.
The file itself is stored on an encrypted USB pen drive. Your /tmp is a tmpfs, and your swap is triple-encrypted with random keys.
So joe may create all the temporary files it likes in /tmp, yet it is still safe to edit the password file, because no sensitive date will ever be written to disk. At least not unencrypted. Right?
So I thought for a long time.
Until I discovered recently that joe stores the contents of its kill ring into ~/.joe_state by default!
This means it suffices to copy a password line to some other location within the file and then delete the original line - and your super-secret password might end up in .joe_state, which may be located on a completely unencrypted filesystem because the user was not aware of that danger!
Of course one could disable the state file completely. But it is highly useful for remembering the last edit position, find/replace history and the like.
Therefore, I would like to suggest either removing the kill ring from the state file completely, or adding an option to let the user decide whether or not he is ready to accept the risk of revealing the kill buffer to potential intruders at some later point in time.
I also want to point out that deleting or overwriting the state file cannot be a general solution for this kind of problem, because modern journaling filesystems, flash translation layers, wear leveling mechanisms of flash controllers, and automatic bad-block replacement by hard disk controllers may always keep unexpected copies of the original data around, which highly sophisticated intruders may still be able to recover.
I'm not sure of the solution to this yet: we could certainly eliminate the kill ring in the state file or provide an option for it. I'm kind of looking for precedent from other applications. I suppose you are not as worried about backup files since they are not quite "unexpected copies".
Hmm, I guess shell history file is a similar security hole.
Last edit: Joe Allen 2016-03-06
But only if one uses passwords directly in the command line, which should be avoided for a different reason: Every other user who runs "ps -af" at the time when the command is executed would see the password as well.
Therefore, it is unwise to use passwords directly in the command line at all. And then they won't show up in the shell history either.
In the meantime I had an idea about that: Why not adding an option to joe that .joe_state is located relative to $XDG_RUNTIME_DIR rather than to $HOME? If $XDG_RUNTIME_DIR is unset or does not point to a valid directory, $HOME can still be used as a fallback.
As a workaround to the problem, I have currently taken the following measures in to avoid the security problem:
I create a symlink with a known name (say ~/.volatile) in my $HOME directory which points to a secure RAM-based directory.
My login script checks this symlink in order to see whether it actually points to an existing directory, or not.
In the latter case, a new volatile directory is created in $XDG_RUNTIME_DIR (if this is set) or in /tmp (which is a tmpfs in my case) otherwise. In both cases, the temporary directory is created with mktemp using the UID as the base name with a random suffix. After creation, the invalid ~/.volatile symlink is retargeted to point to the newly created temporary directory.
The file ~/.joe_state is made into a symlink to ~/.volatile/.joe_state.
This setup ensures that .joe_state will always be created on volatile storage, and never on disk. The volatile directory will persist as long as the machine is running (or some cleanup cron job wipes /tmp), or until the current session is destroyed (when using systemd and $XDG_RUNTIME_DIR).
This setup requires some scripting in order to work, but it solves the ~/.joe_state privacy problem.
Also, the technique of replacing state files by symlinks to ~/.volatile cannot only be used for joe, but also for other text editors which have similar problems.
For instance, Midnight Commander's mcedit also stores state files, and they can be replaced by symlinks into ~/.volatile as well.
Hello, today I stumbled upon exactly this problem, found this ticket of 2016 and it is not solved yet? Today with all the commercial oses turning into surveillance machines, unices should take some more care of privacy. I recently kicked all my commercial oses into the bucket and am only on linux now. At least I have a chance here to find all the logging and "backup" places.
What is this "joe_state" file good for? It is not described in any documentation, is it?
If the information is only valid for the current session, could you maybe simply write it to a temp file? Maybe as an option?
It stores things such as the last search expression or the current cursor position within the file edited last. And also the contents of the kill ring.
One problem here is how to define "session". On your local machine it might be pretty obvious.
But what if you are being logged into a remote machine with two different shells at the same time? Depending on the point of view this could be interpreted as two different sessions, or just as two different shells kept running in the same "overall session" taking place on the remote machine.
In such a situation you might not want the .joe_state file to be deleted or truncated just because you did logout at the first remote login shell, because you keep using joe in the second remote login shell.
Good point. However, I found out that the joe_state function can be disabled in the joerc file with
--joe_state
which is sufficient for my purpose.