Blacklist or remove clipboard data like passwords when an application clears it

[JPvRiel]

As a feature request to make this extension more security friendly, it would be good to have an option to blacklist data that is copied from password managers into the clipboard and/or remove data from the clipboard when an application clears it.

It does sound complicated to look into this given:

1. the clipboard doesn't identify which application pasted the data
2. another application might change the clipboard content before the password manager clears it after a timeout

For example, applications like KeePass remove the password on the CLIPBOARD after 30 seconds. However, this extension will keep that data and store it its cache/registry file.

Similarly, and issue was logged for GPaste: Application blacklist needed. The solution there, while not ideal, was to add an extra key binding to pop the item out.

It might, at minimum, be possible to detect if the clipboard data is cleared and honor that.

Current workarounds with manual intervention by user

• Private mode
• Clear history

[Tudmotu]

I'm not sure if we can identify the source of the clipboard, but maybe a "safe copy" shortcut can work? Maybe we can add a shortcut that adds stuff to clipboard without saving it in the app history. WDYT?

[JPvRiel]

Yeah, I feel bad for raising an issue I don't have a good or clear suggestion for. Shortcut can work, but there's a bit of snag.

• Some password managers have an autotype feature which means they'd probably bypass the shortcut key.
• But for folks who want to explicitly cut and paste, that could help

Honestly, I get the feeling I need to file an upstream enhancement with gnome/kde/opendesktop.org type places to add a function to clipboard objects that allows permitted applications to query the source process name (which in itself would create a security risk if there was malware hoping to know what exactly to steal from a clipboard...)

Without the window manager/shell providing data origin info from the clipboard, the other nasty workaround could be:

• keep track of which window is in focus
• if the window is in the blacklist, don't record the data copied to the clipboard

[JPvRiel]

Just to add a thought about this, another feature or workaround for this is to have an option to store clipboard history in memory rather than storage:

• security conscious folk can choose (opt in) for in memory history - con is doesn't persist across reboots/instances of gnome shell.
• default could remain storing history in current location - persists, not that secure.

Isn't too hard to do if one can leverage /var/run/user which is mounted with only user access in memory as tmpfs on most distros.

But nonetheless, it's not going to help that much given the general insecure state of X and the lack of boundaries between applications running under a single user ID (compare that to Android which has a different user ID for each app). So blacklist is still more ideal.

[JPvRiel]

I looked into this some more. The registry.txt file used to cache the copy paste history is only only accessible to the user, given $ ls -ld ~/.cache is drwx------ (in Ubuntu 16.04 at least). Even if ~/.cache/clipboard-indicator@tudmotu.com/registry.txt gets the default umask 0002 and is world readable, the parent directory will make it inaccessible to other users.

However, in cases where people don't use encrypted home directories, or storage, this file could be read in offline attack scenarios (e.g. bootable ISO).

I tried a hacky workaround using systemd user mode to move the file into the /var/run/$UID tmpfs location. This mitigates the offline attack, but still has drawbacks:

• All other processes for the current user can still read the file
• Now the history will not persist between reboots
• Large history sizes could consume more RAM. E.g. if the extension was extended to keep image copy paste operations, this could be a problem.

Again, an option to only cache the history/registry in the extension's process memory space is still better more secure than the example below.

Systemd user unit to move registry.txt to a tmpfs mounted location

Create dir for per user units

mkdir ~/.config/systemd/user/

Edit ~/.config/systemd/user/gnome-clipboard-indicator-registry.service

[Unit]
Description=Gnome Clipboard Indicator set to use tmpfs registry

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/mkdir "/var/run/user/%U/clipboard-indicator@tudmotu.com"
ExecStart=/bin/chmod 0700 "/var/run/user/%U/clipboard-indicator@tudmotu.com"
ExecStart=/bin/setfacl -R -m d:u::rwx "/var/run/user/%U/clipboard-indicator@tudmotu.com"
ExecStart=/bin/rm -f "%h/.cache/clipboard-indicator@tudmotu.com/registry.txt"
ExecStart=/bin/touch "/var/run/user/%U/clipboard-indicator@tudmotu.com/registry.txt"
ExecStart=/bin/ln -s "/var/run/user/%U/clipboard-indicator@tudmotu.com/registry.txt" "%h/.cache/clipboard-indicator@tudmotu.com/registry.txt"
ExecStop=/bin/rm "%h/.cache/clipboard-indicator@tudmotu.com/registry.txt"
ExecStop=/bin/rm -r "/var/run/user/%U/clipboard-indicator@tudmotu.com"
TimeoutSec=1

[Install]
WantedBy=default.target

Run/test the service

systemctl --user daemon-reload
systemctl --user start gnome-clipboard-indicator-registry.service

Enable it for every time the user first logs in

systemctl --user enable gnome-clipboard-indicator-registry.service

[JPvRiel]

#78 adds an option so that the on disk cache / regsistry.txt file won't store clipboard content, inlcuding passwords. However, that knowingly breaks clipboard history persistence between gnome-shell sessions (reboot, logoff & login).

Doesn't fix/close this issue. Just a possible mitigation.

[JPvRiel]

Thinking about it some more, #60 is more or less a duplicate of this?

[NinjaTurtle007]

So are any password privacy features going to be implemented?

[frock81]

Hi all. My suggestion would be the same as this. To put an ignore icon near the trash icon. Clicking on the ignore icon would add the entry hash to a blacklist. New clipboard entries would be hashed and the hashes compared to the blacklist. If there is a match the entry is ignored.

[santrancisco]

Hi all,
I just found this extension today and had the same worry. I looked up gnomeshell doc and found it is possible to get the title of the current focus_window so you should be able to filter out and ignore a blacklist of windows of your choice. (eg keepassx, keeweb, etc) . For now i only needed to ignore keeweb so I ended up hardcode it into extension.js just below PRIVATE mode check but I hope someone would have more time to properly create a menu item to add comma separated filter list, that would be great?

if (PRIVATEMODE) return; // Private mode, do not.
if (global.display.focus_window.get_title().toLowerCase().match("keeweb") != null) return;

(of course, it does not change the fact that you could accidentally leak things when copying sensitive data off your browser, documents, slack etc.. so it wont addresses all the concerns :( )

[Tudmotu]

Sorry, I don't plan on supporting any of these requests.
This extension will not keep a list of all the password managers that exist in the world. It will not happen.
You have two options:

1. Open a ticket on the repo of the password manager you use, and ask them to stop using the clipboard to store passwords
2. Fork this repo and build your own extension :)

Sorry for the inconvenience, and good luck!