Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Indeed. Our OS security models will keep being broken until people start taking object capability design seriously ¯\_(ツ)_/¯
Who keeps an eye on clipboard access?
31–40 of 147 posts
Re: Who keeps an eye on clipboard access?
#32Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
> For example, you wouldn't be able to put a "paste" item in a context menu
Maybe the menu item could be a special window/widget type specific for the "paste" action, controlled by the UI server. An app could be restricted in how many of these it could have and what to display in it.
Re: Who keeps an eye on clipboard access?
#33Earlier quoted context omitted.
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
Forget a permissions model. How about an informed notification model, where the OS marks the application with a badge notification whenever it requests a paste? And you can see a history of what it requested? Generally I find it odd that there is so much hand-wringing over basic transparency. As with companies giving away private data to third parties, before talking about consent, how about a paper trail to start wi…
That is exactly what is discussed in the article. A way to notify the user if a program request the contents of the clipboard. iOS apperently does just that.
The thing with the clipboard is that the feature is ancient. And back then, most applications were generally very unconcerned with security. So now the genie is out of the bottle, and it's difficult to convince some people that it's a problem.
The article's POC works for X only, which, as far as I understand, doesn't even prevent applications from reading each others keystrokes, much less clipboard. That just wasn't any kind of priority when it was created
Re: Who keeps an eye on clipboard access?
#34Why can apps even read it in the first place, as opposed to the os sending it only to apps the user initiates a paste in?
Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.
The applications still need to retrieve data for the clipboard to be of any use to anyone. E.g. Editor widgets like to have a paste button. Edit > Paste is a fairly common pattern, too.
Without having the OS in charge of managing the entire UI, it's difficutlt to make that work
Re: Who keeps an eye on clipboard access?
#35Earlier quoted context omitted.
Clipboard should be a private and secure enclave (encrypted) in the first place. Only the OS should store and retrieve data from it.
It’s pretty safe in web browsers. Any app can write to it but the only way to read is if the user hits the paste shortcut.
That is not quite true. JS can read the clipboard on any direct user interaction using "Document.execCommand". Also, there is a newer Clipboard API that requires explicit user permission, but as far as I understand once it is given it allows arbitrary reads.
Re: Who keeps an eye on clipboard access?
#36That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same. I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow. Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without b…
> Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access
That would break clipboard managers which are very useful tools to have in various occasions. E.g. in a previous job i worked at, some audio designers used a clipboard manager to quickly fill settings in various tool fields.
Fun fact: most clipboard managers tend to use global shortcut keys for cycling through the recent N copies (or for pasting specifically tagged content, e.g. copy something and mark it to be used for pasting after Shift+Alt+1 is hit, same for Shift+Alt+2 for something else, etc), which is another thing that you'd hear security concerns for :-P
Re: Who keeps an eye on clipboard access?
#37Is there a Little Snitch/open snitch/Lulu type tool for Clipboard access?
Re: Who keeps an eye on clipboard access?
#38Earlier quoted context omitted.
Because the OS doesn't know when the user initiates a paste. The user tells an application that they want to paste, and then the application tells the OS to give it the contents of the clipboard. (Sort of; some windowing systems do it slightly differently, but that's the gist of it.) That's indistinguishable from the application telling the OS it wants to paste when the user hasn't requested it. Sure, there are ways…
> you wouldn't be able to put a "paste" item in a context menu I don't know about that. One approach would be for the menu invocation to accept a capability object representing the active context's interpretations of "copy", "paste", "save" etc. (A "user agent" if you will!) The menu would then invoke methods on that object. That way, interactions triggered by the mouse would propagate the appropriate capability. Oth…
If you do that then why can't the program invoke methods on that object whenever it wants to?
Re: Who keeps an eye on clipboard access?
#39That my web browser process can read my windows clipboard is fine, what’s important is that it prevents the web pages it has loaded from doing the same. I can’t trust all web pages but trusting all my desktop programs is a much easier pill to swallow. Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access, or notifying the user when apps read the clipboard without b…
> Windows could certainly tighten the security by optionally only allowing foreground/focused apps to access That would break clipboard managers which are very useful tools to have in various occasions. E.g. in a previous job i worked at, some audio designers used a clipboard manager to quickly fill settings in various tool fields. Fun fact: most clipboard managers tend to use global shortcut keys for cycling through…
Sure, but that should really be a permission you have to grant explicitly.
For global keyboard shortcuts an app should make commands available and it should be up to the user to tell their OS which shortcuts they want to give an app. Not just for security, but also for customisability and to avoid conflicts
Re: Who keeps an eye on clipboard access?
#40Earlier quoted context omitted.
Wow, I had no idea things worked this way. It makes sense but is also terrifying to think about, that I might be copy-pasting some sensitive data and then accidentally tab into some app and it'd just ghost-paste the data into its cache.
As other pointed out, you don't even need to tab into some app. The security model on desktop OSs is that by default, every app has access to everything owned by the current user, even memory of other apps or hijacking commands by adding scripts in ~/.local/bin. It is slowly being worked on (on Linux, this is done via control groups (containerization), AppArmor, SELinux, ...) but takes time to carefully tune so legit…
capabilities based security http://www.skyhunter.com/marcs/capabilityIntro/index.html