[HN Gopher] Who keeps an eye on clipboard access?
___________________________________________________________________
Who keeps an eye on clipboard access?
Author : pndy
Score : 239 points
Date : 2022-02-03 14:48 UTC (2 days ago)
(HTM) web link (blog.ovalerio.net)
(TXT) w3m dump (blog.ovalerio.net)
| AshamedCaptain wrote:
| > it seems that due to the nature of X11 it is not possible to
| know which running process owns the window that is accessing the
| clipboard. A shame.
|
| You definitely can. Search for _NET_WM_PID. Now this being X11,
| this is again just a convention, and a client could put any
| information it wants in that property.
|
| > While very useful, this raises a lot of security questions.
|
| Really, it doesn't.
|
| If these programs want to share information, they already can. If
| these programs want to spy on each other's memory contents, they
| already can. Unless you are running these programs as different
| users and with different home directories, which is not usual
| right now in desktop GNU/Linux (but is on Android).
| dethos wrote:
| > You definitely can. Search for _NET_WM_PID. Now this being
| X11, this is again just a convention, and a client could put
| any information it wants in that property.
|
| That was the reason I mentioned that "it is not possible to
| know", perhaps "for sure" is missing at the end of the
| sentence.
|
| > Really, it doesn't.
|
| As a user (at least in my opinion) it does.
|
| > If these programs want to share information, they already
| can. If these programs want to spy on each other's memory
| contents, they already can. Unless you are running these
| programs as different users and with different home
| directories, which is not usual right now in desktop GNU/Linux
| (but is on Android).
|
| The point is, when the user copies a piece of information he
| has a clear target for that information (clipboard is the tool
| he uses do copy from one window to another), why would all
| other apps have access to it?
|
| It is the user that wants to share information not the apps.
|
| Even taking account all those capabilities, many pieces of
| malware rely on detecting and replacing information on the
| clipboard, that is a clear indication that some sort of
| isolation is missing here, or at least, and indication
| regarding that the information was changed/accessed.
| AshamedCaptain wrote:
| > The point is, when the user copies a piece of information
| he has a clear target for that information (clipboard is the
| tool he uses do copy from one window to another), why would
| all other apps have access to it?
|
| Everything that is run by the user runs in the same context.
| There is little point in focusing on the clipboard, because
| any two programs running within the same user can do
| literally anything to each other. Including spying on each
| other keystrokes, modifying each other's text widgets
| contents, and faking whatever text/images they are
| displaying. The fact that they may alter the clipboard
| contents is irrelevant when they can literally monitor and
| inject keystrokes on each other.
|
| This is the security model that we have right now at the
| desktop. Good luck trying to find a better one that just does
| not completely break UNIX and turns it into something like
| Android. One of the benefit of this model is that you (the
| user) have practically unlimited freedom in hooking the
| system in ways that nobody expects (e.g. a clipboard access
| detector), but then so does anybody else you decide to trust
| (by running their program in the same context).
| CyberShadow wrote:
| This is why distributions are moving towards Wayland and
| container-izing most applications; this allows each
| application to be in its own sandbox with no capability of
| interacting with other applications without the
| user/system's explicit consent.
| destructionator wrote:
| It is quite easy to do that with X as well. It doesn't
| transfer data at all until the clipboard data is
| requested, and at that point, the clipboard owner knows
| which window is requesting it and is free to ask the user
| or deny the request. No applications I'm aware of do this
| in practice though, beyond the normal content
| negotiation.
| CyberShadow wrote:
| The protocol actually allows for applications to request
| the clipboard data to be delivered to someone else's
| window. I haven't tried it, but I think it would work.
| CyberShadow wrote:
| > If these programs want to spy on each other's memory
| contents, they already can.
|
| No, they cannot. As an unprivileged process, you cannot access
| other processes' memory, with major distributions' default
| settings, even if the two processes share the same UID. The
| only way to achieve that would be to modify some execution path
| (e.g. .bashrc) to launch an evil wrapper which runs the target
| process in a way that allows reading its memory.
| AshamedCaptain wrote:
| Which distributions and which settings are you talking about?
|
| If you can run gdb on that distribution, then you can
| definitely do it, even if it's just because they whitelist
| gdb in selinux/aa (in which case you can just script gdb).
| And I rather doubt it is a default, since ptrace-based
| sandboxing is a thing (even Firefox was using it).
|
| And as for the second method, that's why I said same home
| directory. But there is a gazillion of ways. You can even
| meddle in practically all IPC done by any two processes of
| the same UID, e.g. attach to sysv or posix shm.
| CyberShadow wrote:
| > Which distributions and which settings are you talking
| about?
|
| kernel.yama.ptrace_scope = 1
|
| > If you can run gdb on that distribution, then you can
| definitely do it, even if it's just because they whitelist
| gdb in selinux/aa (in which case you can just script gdb).
|
| No, you can't. Try it.
|
| > And I rather doubt it is a default, since ptrace-based
| sandboxing is a thing (even Firefox was using it).
|
| You can trace child processes, but not any other process.
| AshamedCaptain wrote:
| Which distribution enables this by default ?
|
| EDIT: Apparently Ubuntu, but not Debian, SuSE, Arch, etc.
| Well, TIL.
|
| > No, you can't. Try it.
|
| You definitely can, it's just that that as you said, gdb
| just can't attach to anything but a child process; making
| gdb only work with a process it spawned itself.
|
| Anyway, in addition to changing .profile, you still can
| do practically everything including modifying SHM
| segments, writing to pipes, sockets, etc. You could start
| closing feature by feature (e.g. remove /proc like
| Android), but for some reason it doesn't seem like the
| right approach.
| CyberShadow wrote:
| > but for some reason it doesn't seem like the right
| approach.
|
| The approach being used in containerization is
| namespaces. You can put new processes into a new IPC /
| user / PID / network / time / etc. namespace, which
| isolates them from the parent namespace. Once that's done
| and you can't mess with other processes via the
| filesystem / kernel, the remaining hole is servers with
| inadequate security models, such as X11.
| AshamedCaptain wrote:
| What I mean is that if you are going to put your
| processes as a different user anyway (or a different user
| namespace), trying to break all the features that allow a
| user to manage same UID processes is unnecessary.
| [deleted]
| rcthompson wrote:
| On recent Android versions you get a pop-up notification whenever
| an app accesses the clipboard. (I think it doesn't notify for the
| active app, or maybe it doesn't notify for explicit user-
| initiated clipboard interactions, I'm not sure exactly what the
| rules are.) If I saw any app repeatedly accessing the clipboard
| for no discernible reason, I would definitely uninstall it.
| jeroenhd wrote:
| Android killed background clipboard access in an Android update
| entirely, except for system and vendor applications. I had to
| root my phone to get clipboard sync working again in KDE
| connect.
|
| I haven't seen the notification myself, but I'm still on
| Android 11. From what I can tell for user-installed
| applications, only the active application and the keyboard get
| clipboard access, regardless of permissions and capabilities
| declared in the app manifest.
|
| I get why they did this but I think it's a bad choice not to
| allow the user to opt into clipboard management. Going back to
| manually typing TOTP codes was more annoying than rooting my
| phone.
| Hallucinaut wrote:
| I have a Pixel 6 and I've noticed an app from some Wi-fi
| lights with an app called TCP Smart copies my clipboard
| whenever I open it. I was disturbed by this and definitely
| didn't do anything special to permit it, so that seems
| somewhat at odds with what you're saying?
| jeroenhd wrote:
| Perhaps I misinterpreted; you're right. Foreground apps are
| perfectly allowed to use the clipboard, it's just
| background app access that got axed. Apps don't even need
| any permissions to respond to clipboard events!
|
| The toasts were added to Android 12
| (https://developer.android.com/about/versions/12/behavior-
| cha...) but the permission required to call from the
| background isn't available to normal apps. The API should
| only show for active applications or input methods, and
| non-IME inputs that call the API (i.e. foreground apps)
| will show a notification if you have this setting enabled.
|
| Basically, it should only happen with the TCP Smart app
| open, and show when the TCP Smart app is using the
| clipboard. It shouldn't just randomly happen inside other
| apps, unless the devs behind that app are somehow bypassing
| Android's security features.
| adrianmonk wrote:
| More info (from
| https://developer.android.com/about/versions/12/behavior-
| cha...):
|
| > _Clipboard access notifications_
|
| > _On Android 12 and higher, when an app calls getPrimaryClip()
| to access clip data from a different app for the first time, a
| toast message notifies the user of this clipboard access._
|
| > _The text inside the toast message contains the following
| format: APP pasted from your clipboard._
| CyberShadow wrote:
| Currently writing a clipboard manager[1], I've seen some things
| as well.
|
| - So far ran into two applications which don't even implement the
| X11 clipboard specification (ICCCM section 2) correctly - xsel
| and Emacs (patches submitted).
|
| - By far the worst offense I've seen in clipboard privacy on the
| Linux desktop is RedHat's virt-manager. It sends your clipboard
| AND selection content to all virtual machines, even when they are
| not focused, with no indication that it's happening, and with no
| GUI option to turn it off. This is at odds with the common
| practice of running untrusted code in virtual machines.
|
| - X11 being network-transparent makes its protocol fairly
| malleable, so it's not difficult to bolt some privacy on top.
| hax11[2] has an option to restrict access to the primary
| selection for configured applications (though, for truly
| malicious applications, you may find X11's security model
| generally lacking).
|
| [1]: https://news.ycombinator.com/item?id=29808487 [2]:
| https://github.com/CyberShadow/hax11
| thrwawy283 wrote:
| I've always wanted an application dedicated to managing the
| clipboard. It would provide security and even offer interchange
| conversion that existing apps do not implement. For example:
| Copying HTML in Windows it has an associated mime type that
| receiving applications can recognize and choose to convert
| from.
|
| I've always wanted a clipboard/paste manager - with history -
| like this, that would allow me to copy, manipulate, and paste
| or share that data to another application.
|
| I don't know how this would look, but even the ability to pop
| open my paste manager and look at the copied contents, filter
| it, or split the text, or (silly stuff) convert text to
| emoji'fied content, or take a screenshot of that (text to
| bitmap), and create a new entry within the paste manager. For
| some of my friends it would be awesome to have a hex editor in
| there.
|
| Perhaps there are 2 focuses: Isolating what is copied from
| applications until the user chooses to expose it, and the
| history function. Being able to send it to another app for
| manipulation and pulling it back is a 2nd responsibility. It
| would be /suave/ to have this all in the same GUI brought up by
| the compositor, though.
| y4mi wrote:
| That does sound great.
|
| While it's not what you're looking for, a lot of people also
| don't know that windows has a built-in copy paste history if
| you use windows+v instead of ctrl-v. That's quiet handy too,
| but a fast cry from what you've proposed there
| indentit wrote:
| For Windows, there is "ClipboardFusion" by Binary Fortress,
| which acts as a scriptable clipboard manager, and could tick
| most of your boxes.
|
| I'm not sure how possible it would be on Windows for a third
| party app to perform isolation - maybe if it registers a hook
| for when clipboard content changes which is somehow
| guaranteed to run first before other applications and any
| hooks they may have, it could swallow the event and clear the
| clipboard so other processes can't see it, and then do
| something similar with paste events maybe?
| filoleg wrote:
| While not scriptable and not super advanced, Windows 10 and
| Windows 11 have a native visual clipboard manager with
| history and some other basic features. And it works quite
| well.
|
| Try pressing Win+V, and the OS will give you a prompt to
| enable clipboard manager in settings. Once you enabled it
| (has to be done once), next time you press Win+V, a panel
| will slide out from the right side, and you can see the
| last N entries in your clipboard (which could include text,
| images, etc.). You can pick anything from there and paste
| it, and you can also pin any item there so that it won't be
| overwritten when the clipboard reaches the limit and starts
| writing over.
| 6equj5 wrote:
| >I don't know how this would look
|
| Probably something like KDE's clipboard? ; p
|
| https://i.imgur.com/zXTLzoO.png
| Rygian wrote:
| > RedHat's virt-manager. It sends your clipboard AND selection
| content to all virtual machines
|
| Do you know what's the CVE for that one?
| CyberShadow wrote:
| Let's see where this goes:
|
| https://github.com/virt-manager/virt-manager/issues/358
|
| Edit: found this, so maybe Red Hat considers this a feature
| which is working by design: https://github.com/virt-
| manager/virt-manager/pull/166
| formerly_proven wrote:
| Qubes distinguishes local and global clipboards for exactly
| this reason.
| octavqq wrote:
| hehehe
| throwntoday wrote:
| iOS/macOS really need to add clipboard to privacy settings. I
| opened monopoly on iOS and the first thing it did was paste my
| clipboard to god knows where.
| alexvoda wrote:
| To what degree does Wayland solve this compared to X?
| jchw wrote:
| I believe in Wayland, only foreground applications can access
| the clipboard. I can't recall how poorly XWayland fares; I
| suspect it just bypasses the security boundary. Nonetheless,
| still useful, especially e.g. for sandboxed apps.
|
| I don't think clients can, without extensions, watch for who's
| snooping the clipboard. However... it probably wouldn't be
| difficult to integrate this into the compositor. You could even
| imagine a Wayland protocol for watching clipboard accesses, or
| god forbid, a dbus service for doing so.
| emersion wrote:
| XWayland as a whole is itself a Wayland client. So as long as
| any X11 window has focus then any other X11 window can steal
| the clipboard. But once a Wayland window is focused, X11
| windows don't have access anymore.
| Arnavion wrote:
| >I believe in Wayland, only foreground applications can
| access the clipboard.
|
| To be precise, Wayland does not care who or what accesses the
| clipboard. Whether or not only foreground applications can
| access the clipboard is determined by which clients the
| particular compositor sends wl_data_offer events to.
|
| So the answer to alexvoda's question is: Wayland doesn't
| solve the problem completely. wl_data_offer events are pushed
| from the compositor to the client rather than the client
| asking for a data offer. The compositor cannot know whether
| the client may want the data offer, so it has to send the
| event to every client regardless of whether the client ends
| up needing it or not. For most (if not all) compositors
| today, "every client" means "clients that are currently
| focused", so while a background application can't snoop your
| clipboard, simply focusing such an application would allow it
| to snoop.
|
| Furthermore, extensions like wlr-data-control are
| specifically designed for background snooping, since they're
| intended to be used by clipboard managers. It's again up to
| the compositor to apply security to this, like only allowing
| a single specific process to be the data control manager and
| not arbitrary programs. For wlr-data-control I'm not aware of
| any compositor that applies such a policy; it would, at the
| very least, break `wl-paste`.
| bagels wrote:
| 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?
| kelnos wrote:
| 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 that you could design the system, such as
| making it so the only way to paste is for the user to hit a key
| combination, or perhaps click on or touch a UI element that is
| known to be controlled/hosted/owned by the OS. Then the OS can
| push the clipboard contents to the foreground application,
| rather than the application trying to pull it. But then that
| becomes very limiting, UX-wise. (For example, you wouldn't be
| able to put a "paste" item in a context menu.)
|
| You could also have a permissions model, where the OS prompts
| for permission every time an app wants to fetch the clipboard
| contents (presumably with an "I trust this app" option to get
| it to stop asking). But that might be considered too intrusive,
| or possibly just ineffective, as people will often just mash at
| whatever button is closest to get a modal dialog to go away.
|
| At any rate, we have these copy/paste mechanisms from when
| people didn't really think about local security in the way we
| do today. Redesigning things would break a lot of existing
| applications. It might be worth it, or it might not.
| BelleOfTheBall wrote:
| 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.
| progval wrote:
| 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 legitimate existing
| apps don't crash because they expect access to something.
| IIRC, macOS and Windows are also working on this.
|
| There is also Qubes OS, taking a more radical approach of
| isolating everything by default, like Android or iOS. But
| it can be painful to use, as apps are not designed to
| support it.
| bryanrasmussen wrote:
| capabilities based security
| http://www.skyhunter.com/marcs/capabilityIntro/index.html
| badsectoracula wrote:
| > Suppose you were running a capability-secure operation
| system, or that your mail system was written in a
| capability-secure programming language. In either case,
| each time an executable program in your email executed,
| each time it needed a capability, you the user would be
| asked whether to grant that capability or not. So
| Melissa, upon starting up, would first find itself
| required to ask you, "Can I read your address book?"
| Since you received the message from a trusted friend,
| perhaps you would say yes - neither Melissa nor anything
| else can hurt you just by reading the file. But this
| would be an unusual request from an email message, and
| should reasonably set you on guard.
|
| > Next, Melissa would have to ask you, "Can I have a
| direct connection to the Internet?" At this point only
| the most naive user would fail to realize that this email
| message, no matter how strong the claim that it came from
| a friend, is up to no good purpose. You would say "No!"
|
| That sounds like a usability nightmare.
|
| Also it is something that users ignore even at the coarse
| level of application permissions on mobile phones -
| imagine having Every.Single.Action on a computer do that.
| Instead of just people ignoring those, they'd turn
| outright hostile to any application doing that.
| bryanrasmussen wrote:
| >That sounds like a usability nightmare.
|
| sure but any email system should not have to request the
| capabilities to do any of these things, so basically if a
| message came in and it started requesting these
| capabilities - it would only be malicious messages that
| would do it.
|
| This is following the principle of least access/authority
| http://wiki.erights.org/wiki/POLA
| badsectoracula wrote:
| An email client certainly needs the capabilities
| mentioned there. The ILOVEYOU virus (which is what the
| page refers to) was an executable (a VBS script but any
| executable could do the same thing) that asked Outlook
| Express for the address book and use it to send mail with
| itself as an attachment. The issue with it was that
| Outlook Express was too happy to run programs attached to
| mail (also that Windows hide file extensions by default
| and... people tend to respond to affection - at the end
| of the day you can't solve social issues with technical
| solutions) without even a warning (though a warning would
| be most likely ignored anyway due to the social aspect of
| the message - which is also what would happen with the
| warning in the dialog mentioned in the linked page too).
|
| And at some point you'll have to request these
| capabilities and the user will have to grant them. So the
| user, as is seen with mobile permissions nowadays that
| serve more to make developers feel good about providing
| security and pat each other on the back about how
| thoughtful they are (meanwhile there is a ton of malware
| on Android phones), will simply grant the permissions
| because they want to run the application - the reason
| they went into obtaining it in the first place.
|
| You can see the issue clearly in that infamous video from
| Linus Tech Tips where Linus tried to install Steam and
| end up breaking his desktop despite lots of warnings from
| the system - he had a goal (to run the program) and in
| the pursuit of that goal he ignored pretty much every
| warning the OS gave him, including even forcing him to
| type "yes i know what i am doing".
|
| These solutions are pointless and only help to make the
| programmers who implement feel good that they implemented
| them. Like the solution to problem above where now you
| have to make a special file in the root folder to do
| that, as if someone who ignores everything in the pursuit
| of a goal to type "yes i know what i am going" aren't
| going to type "sudo touch /.magic_file" (that they copied
| from a forum post).
|
| The only way to stop people from doing something it to
| make it technically impossible to do it. But at that
| point you are starting to make tasks impossible to
| achieve and people use computers to do things and
| anything that goes towards that is missing the forest
| (people using computers to do things) for the tree (some
| things can be unsafe so let's not anyone do it).
| bryanrasmussen wrote:
| so, I can't help but note that when I said an email
| client should not need to request these capabilities and
| anything that did would be malware, you said an email
| client definitely needed to request these capabilities
| and gave as the example the ILOVEYOU virus.
| badsectoracula wrote:
| Yes?
|
| In a system based on permissions (which is basically what
| a capability system is) somehow applications need to gain
| those permissions - so it makes sense that an email
| client will need to request them. Otherwise how is it
| going to work if it cannot access the internet, the
| address book or any other functionality it might need?
|
| BTW the ILOVEYOU virus example is what the linked page
| brought up, not me. They call it "Love Bug" but that is
| just another name for the same virus:
|
| https://en.wikipedia.org/wiki/ILOVEYOU
| dan-robertson wrote:
| You don't need to tab into the app (on a desktop os at
| least). It's generally possible to read the clipboard from
| the background. The app mightn't even need a visible
| window.
| spiorf wrote:
| > accidentally tab into some app
|
| I think in most systems you don't even need to do that. The
| app should be able to get the clipboard while in the
| background.
| wruza wrote:
| _accidentally tab into some app_
|
| Apps do not even have to be foreground to fetch clipboard
| contents, afair. On windows, a clipboard is shared with the
| entire session (i.e. everything that you or the system runs
| for you after you log on).
| pishpash wrote:
| 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 with?
| edave64 wrote:
| 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
| jonnycomputer wrote:
| anything similar for Mac OS?
| dan-robertson wrote:
| The way it works for webapps is that you are only allowed to
| read or write the clipboard in the event handler for certain
| events, but it isn't really watertight and that sort of
| mechanism isn't so feasible outside the web where you don't
| have so much control on how programs handle events.
| tonyg wrote:
| > 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. Other
| uses of the menu would have to synthesise an object of the
| correct type, which they could do, but they wouldn't be able
| to forge access to the user's clipboard.
|
| In general, capability style thinking benefits from removing
| _ambient authority_ such as a global clipboard, replacing it
| with an object explicitly representing the necessary
| authority in each context.
| robertlagrant wrote:
| If you do that then why can't the program invoke methods on
| that object whenever it wants to?
| tonyg wrote:
| Good question. You only pass it with an interaction
| event. (And you revoke the capability once the
| interaction is over.)
|
| Not perfect: stops background pasting without interaction
| tho. To do better, the only way I can think of right now
| is having paste only triggerable by a secure context
| (e.g. keyboard shortcut, as above). Any mechanism by
| which the user can declare "I intend to paste" in so many
| words without the app being able to forge it.
|
| But that needn't rule out context menu paste, I don't
| think, if there's a way for the secure context to
| unforgeably decorate the menu when it declares it wants a
| paste action.
|
| It's a fun thing to think about the design of. I
| encourage us all to try to think creatively about it
| rather than quickly jumping to "it can't be done".
| Findecanor wrote:
| > 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.
| kukx wrote:
| It can be useful of you want to use a non standard way to paste
| stuff, example a right mouse button in putty.
| tonyg wrote:
| Indeed. Our OS security models will keep being broken until
| people start taking object capability design seriously
| -\\_(tsu)_/-
| jchw wrote:
| IMO: you have to look at how OSes and window systems were
| designed and evolved to get a great answer here. Those
| processes resulted in systems where the OS or compositor or
| window system itself can't really know when the user is pasting
| something or not. It could be changed, but it would have lots
| of implications globally, from rewriting framework code, to
| changing JS APIs.
|
| Edge cases would be handled worse, like non-standard paste
| gestures or VM integration.
| lcnmrn wrote:
| Clipboard should be a private and secure enclave (encrypted) in
| the first place. Only the OS should store and retrieve data
| from it.
| edave64 wrote:
| 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
| Gigachad wrote:
| 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.
| edave64 wrote:
| 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.
| kalleboo wrote:
| This depends on the browser. In a privacy-conscious
| browser such as Safari, it will pop up a browser-
| controlled "paste" context menu that the user has to
| explicitly interact with.
| marcosdumay wrote:
| On my browser (Firefox 96), the paste command seems to
| just return false and do nothing.
| edave64 wrote:
| Are you running it as part of a click handler?
| joveian wrote:
| Mozilla's documentation claims paste with
| Document.execCommand is disabled for web content (as it
| should be):
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Document/ex...
|
| On the wider issue, I'd like to only allow a keyboard
| combination from the window manager / compositor to paste
| to the focused window. X11 has three different clipboards
| and I think Wayland has two (I've only seen xsel use the
| X11 secondary selection) while I've only ever heard of
| the one clipboard on Windows.
|
| The kitty terminal has some method of using the clipboard
| that works remotely (though all the magic kitty does
| inspired me to "alias ssh='st ssh'"). I'm not sure if
| anything other than kitty uses it. The permissions have a
| specific "ask" option, which seems like something the
| browsers should support for the Clipboard API.
|
| https://sw.kovidgoyal.net/kitty/kittens/clipboard/
| rank0 wrote:
| Is it possible to deny clipboard access to every application and
| only pass the info through stdin through the explicit ctrl-v or
| pbpaste/xclip/whatever?
| fsflover wrote:
| Yes, on Qubes OS, https://qubes-os.org. It's based on VMs for
| secure and transparent compartmentalization.
| rank0 wrote:
| I am familiar with Qubes, but I'm asking if this specific
| security control could be used elsewhere.
| juglans wrote:
| Bit Warden password manager app for Linux desktop has an option
| to clear the clipboard:
|
| file -> settings [options]'clear clipboard': dropdown select
| range from 10 seconds to 5 mins or never.
|
| Set & forget.
| opan wrote:
| KeePassXC does this as well. Even if just copying the username.
| beermonster wrote:
| Is there a Little Snitch/open snitch/Lulu type tool for Clipboard
| access?
| dethos wrote:
| As far as I'm aware, there isn't. And it would be a nice tool
| to have available, I suspect this could be integrated into
| existing clipboard managers.
| c0l0 wrote:
| I think Linux dynamic user probes would lend themselves quite
| well for something like this. Fooling around with bpftrace for a
| few minutes yielded this one-liner, which catches all the
| conscious X11 selection accesses (and a few unconscious ones, too
| :)) I provoked on my desktop during a few minutes of testing:
| sudo bpftrace -e
| 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S
| ");printf("%-6d\n", pid);}'
|
| I am not familiar with Xlib/X11 at all, so I am not sure which
| library functions one would be most interested in to explore this
| much further.
|
| Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in
| bpftrace invocation.
| CyberShadow wrote:
| I am not familiar with bpftrace (though that does look
| extremely potent), but XSetSelectionOwner is called when an
| application wants to make data available via the clipboard, not
| access it. Also not sure if that would also catch stuff with
| Xlib, and I guess it won't if it's statically linked (this is
| why I pivoted hax11 from hooking library calls to MITM-ing the
| connection).
| c0l0 wrote:
| My bad, I actually had the "production" trace command set to
| look for `XGetSelectionOwner`, but mis-pasted into my comment
| ;) Will that fare any better? It did make a few more
| PIDs/culprits end up in the trace output for me after all.
|
| You are correct that "bringing your own function"/shared
| object will break that particular bpftrace script, but I
| would assume one could find a way to set up a probe in the X
| server, where all clients messing with clipboard state via
| some kind of IPC have to pass thru? (Again, I can only wildly
| speculate how X11 works under the hood - kinda shameful that
| I never bothered to look over all these years :-S )
| CyberShadow wrote:
| I think XConvertSelection would be more effective.
| Applications which use the XFixes extension to receive
| notifications of new owners won't need to use
| XGetSelectionOwner.
| photon12 wrote:
| The Qubes clipboard model is one of the reasons I use that OS:
| https://www.qubes-os.org/doc/how-to-copy-and-paste-text/
| adrium wrote:
| Does it really come as a surprise that apps are exploiting the
| clipboard?
|
| TLDR: Drag and drop sensitive stuff. If necessary, copy only part
| of sensitive information, enter the rest manually.
|
| The amount of usability obstacles in the name of security is
| getting ridiculous. For example, when I got a new company mac, I
| had to enter my keychain access password and grant access to
| folders countless times - and I still have to do that after one
| week of using it occasionally.
|
| Similarly annoying are the cookie questions. In the beginning, I
| found it interesting and tried to reduce the number of cookies as
| much as possible - now I just click what ever button brings me to
| the site fastest (or don't click a button at all, if it is still
| possible to scroll and see about half of the page on mobile).
|
| Don't you also feel some kind of fatigue?
|
| Now please do not cripple the clipboard the same way. By the way:
| Qubes OS takes an interesting approach here. Similar to
| suggestions by some of the commenters. [1]
|
| Don't get me wrong: I am extremely sensible to security - but
| also to usability. I want to use my daily-driver system
| conveniently and it should "just work" and I want to trust it
| fully [2]. I do not just install any trash app, simply because
| there is one available.
|
| On the desktop:
|
| 1. Only applications from the official repos get installed. I may
| install other open source software occasionally. So yes, the
| trust lies with the distro.
|
| 2. Other software (potentially untrusted or good to be isolated)
| like banking or tax software or zoom get a proot environment or a
| new user profile.
|
| 3. Most software can be run in the browser anyway and it is
| actually quite a nice sandboxing tech. Web apps can not simply
| read the clipboard. [3]
|
| 4. Clear cookies on browser exit. I have a whitelist for about
| two or three sites to keep the state for convenience.
|
| 5. Browser extension that manages and fills passwords on
| request(!). No need to copy-paste around. [4]
|
| 6. If I need passwords elsewhere, I use drag and drop. I believe
| this is extremely convenient and very secure. That works 90% of
| the time, otherwise, I copy only part of the sensitive
| information and enter the rest manually.
|
| On mobile:
|
| 1. Same goes for app installation: open-source only from F-Droid.
|
| 2. Other apps get put in a work profile and disabled when not
| used. [5] No trash like games and social media.
|
| 3. Do not copy paste sensitive information, but use IME apps
| (keyboard apps that actually "type" passwords). Personally, I
| like KeePassDX and sometimes use KDE Connect. [6]
|
| Accounts:
|
| 1. I own several domains and mobile numbers, all companies that
| want my info get different data.
|
| 2. Fill in bogus information if possible.
|
| I may have gone overboard with this :-D But I don't even care
| about MFA that much at this point... And it is an interesting
| experiment to see what company leaks data.
|
| [1] https://www.qubes-os.org/doc/how-to-copy-and-paste-text/ [2]
| Kubuntu fanboy here and Android still on version 8 though because
| of ROM customization [3] https://developer.mozilla.org/en-
| US/docs/Web/API/Clipboard/r... [4]
| https://github.com/adrium/easypass [5]
| https://f-droid.org/en/packages/net.typeblog.shelter/ [6]
| https://www.keepassdx.com/ and
| https://f-droid.org/en/packages/org.kde.kdeconnect_tp/ And I
| wrote a KeePass plugin to convert the passwords:
| https://github.com/adrium/KeepassPfpConverter
| ummonk wrote:
| "For example, when I got a new company mac, I had to enter my
| keychain access password and grant access to folders countless
| times - and I still have to do that after one week of using it
| occasionally."
|
| Did you not setup Touch ID?
| adrium wrote:
| Hmm... Yes, but I am only aware to use it for unlocking the
| computer...
| tlarkworthy wrote:
| I have taken to copying a benign string after using a sensitive
| password and I minimize switching tabs during transport of said
| password.
| npteljes wrote:
| That's a good practice. KeePass 2, KeePassX and KeePassXC, and
| KeePassDX on Android do this by default as well. It's even
| better to use the Auto-Type feature of these software, because
| then the password never gets on the clipboard in the first
| place.
| Gare wrote:
| Some password management programs (I know for KeePassXC) clear
| the clipboard automatically after several seconds.
| SubiculumCode wrote:
| This is good to know, but it still doesn't help if there is
| an application phone app, etc, that monitors the clipboard.
| mackatap wrote:
| Bitwarden does as well, though it seems more like 20-30
| seconds.
| gnabgib wrote:
| It doesn't by default (perhaps it depends on which version
| you first installed) but it is available under File ->
| Settings -> Options: Clear Clipboard which can e set to
| never/10s/20s/30s/1m/2m/5m.
| anderspitman wrote:
| I've been thinking it would be fun to make a self-hosted web
| clipboard that lets you paste text/files into a simple web page,
| and have them available on all your devices. Sort of like
| cl1p.net but e2ee and it would maintain history.
|
| You wouldn't need an account because your password could be
| hashed to yield a unique URL.
|
| Only reason I haven't hacked it together already is because I
| don't trust myself to get the crypto right yet.
|
| Anyone aware of something like this already existing?
| Damogran6 wrote:
| I had thought about something similar, only with publishable
| subscriuptions so N people could share the same clipboard. Only
| I wanted the opposite: It would be ephemeral, only as long as
| you subscribed to the 'feed' would you see what was there,
| there would be no history, and pragmatically, no long term
| retention in the cloud...mostly as a cost savings measure.
|
| I got so far as thinking you'd have two guids: One to subscribe
| to, and the other to revoke the feed.
|
| It never got past the thought stage...and I made a logo and
| registered a URL that I've since let expire as the coding took
| longer than my attention span.
| tomerv wrote:
| You're just a few steps away from reinventing Twitter!
| tiku wrote:
| I have removed the LinkedIn and Twitter app because they force
| directed the website to the app, but good to know that it could
| also see my clipboard and even track it perhaps..
| backtoyoujim wrote:
| Then what watches the clipboard watcher ?
| alkonaut wrote:
| That 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 being in focus or sent any
| input first.
| badsectoracula wrote:
| > 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
| nsgi wrote:
| 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
| badsectoracula wrote:
| > Sure, but that should really be a permission you have to
| grant explicitly.
|
| That could work but still feels dodgy since if you can
| grant that permission to a clipboard manager, you can also
| grant it to something like a TikTok client or an Adobe DRM
| reader or whatever else program you want to use (ie. the
| reason you are using your computer in the first place) but
| also might want to snoop for your data.
|
| IMO a better solution that wouldn't break existing
| clipboard usage is to have a second "secure" clipboard that
| you can lock as tight as you want with explicit permissions
| for reading it, notifications for writing to it and
| whatever else you want. Then password managers would copy
| data to that and text editors and browsers can have a "Copy
| Sensitive Data" (or something better worded) in addition to
| "Copy" that will place data there.
|
| Sure some people will still use Copy but some people will
| also stick post-it notes with their passwords on their
| monitors and give thousands of dollars to Nigerian princes
| - you shouldn't to punish everyone for the ignorance of a
| few.
|
| > 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
|
| This only works if all applications are using the same
| framework and toolkit and target the same OS. Meanwhile
| notice how even when you limit yourself to applications
| targeting Windows alone there are tons of different
| frameworks - let alone cross platform applications that
| tend to use a lowest common denominator approach.
|
| IMO if you want to get more secure functionality, you need
| to do it in a way that works alongside existing practice -
| hence containers and sandboxing for untrusted applications
| working alongside trusted applications that can do what
| they want. Unless you start everything from scratch on a
| brand new computing approach (like mobiles did and even
| then it barely works and despite people treating mobiles
| almost like consumables), trying to force a top-down
| approach to security is doomed to fail.
| summm wrote:
| Why does it feel dodgy? When I want to give Adobe DRM or
| TikTok those permissions, I should be able to. They just
| shouldn't have the option to force me, or else stop
| running. Do you really condone the trendy dumbing down to
| an user-hostile walled garden? It's even Windows
| nowadays: They make it super hard to change file
| associations, change it back to Edge on every update, and
| even don't let other programs support the user. All under
| the pretext of "protect the user from bad applications",
| but really misuse it to drive usage of their own apps.
| The same will happen with that clipboard function.
| badsectoracula wrote:
| It feels dodgy because they give a false sense of
| security, i wrote about it in another reply:
| https://news.ycombinator.com/item?id=30220373
|
| > Do you really condone the trendy dumbing down to an
| user-hostile walled garden?
|
| The complete opposite in fact, i dislike the increasing
| usability nightmare that modern desktop OSes creep in in
| the name of protecting users who are going to do their
| thing regardless unless the relevant functionality is
| completely removed - at which point someone should stop,
| take a few steps back and think why people use computers
| in the first place.
| laumars wrote:
| > IMO a better solution that wouldn't break existing
| clipboard usage is to have a second "secure" clipboard
| that you can lock as tight as you want with explicit
| permissions for reading it, notifications for writing to
| it and whatever else you want.
|
| If we are going to break standard APIs then why not do
| away with the clipboard for secrets entirely and have a
| global secrets store that applications can pull
| credentials from directly and securely instead of passing
| secrets via a clear text protocol.
|
| This is how Linux and macOS work (albeit I wish 3rd party
| stores could natively integrate with them). This is how
| cloud computing works too (eg AWS Secrets Manager). Using
| a clipboard for copying secrets is completely the wrong
| approach regardless of how much you over-engineer your
| clipboard manager.
| badsectoracula wrote:
| Note that what i refer to is not about breaking any
| standard API but adding a secondary one that is
| explicitly about secret/sensitive stuff. Current
| applications will of course be still using the clipboard
| but the situation wont be any worse than it currently is
| and new applications as well as applications currently
| active development can be made to use the new one, so
| things can be better.
|
| IMO this is a much better approach and way more likely to
| be adopted than anything that breaks existing
| applications and workflows.
|
| Also while people use passwords as an example, this is
| just an example. What you are copying can be some secret
| government-issued number (that you can't replace with
| anything else), some sensitive photo or anything else
| that you want to be exact at both ends of the operation.
|
| If the source of the data to be placed in the secure
| clipboard (for lack of a better name) is some encrypted
| storage (like a local secrets manager) or a plain text
| file is irrelevant here.
| laumars wrote:
| > Note that what i refer to is not about breaking any
| standard API but adding a secondary one that is
| explicitly about secret/sensitive stuff.
|
| But it still requires developers to use a new API. So why
| get them to used a half arsed security enclave when you
| can design a proper secrets store instead?
|
| > If the source of the data to be placed in the secure
| clipboard (for lack of a better name) is some encrypted
| storage (like a local secrets manager) or a plain text
| file is irrelevant here.
|
| It's very relevant because:
|
| * clipboards are temporary which means you need to copy
| data into them. This creates an extra step for users to
| follow as opposed to applications querying the secrets
| store directly
|
| * clipboards don't have RBAC unlike password stores.
| Which means any application with permissions to read from
| the clipboard can read any secret that any other
| application had written to it. Your solution of having an
| additional permissions set where you chose which
| applications have that permission is solved with secrets
| store where each application only has permission to the
| secrets it creates. Thus zero risk of leakage
|
| * secrets managers are encrypted, clipboard isn't
|
| * secrets managers can store multiple secrets, a
| clipboard cannot. Thus you then still need to have a
| secrets manager to copy your password into the clipboard
| anyway. So why not do away with that middleman entirely?
|
| I get the incentive of wanting to "fix" the clipboard but
| if you're going to introduce a new API for secrets then
| you might as well do it properly from the outset.
| badsectoracula wrote:
| > But it still requires developers to use a new API. So
| why get them to used a half arsed security enclave when
| you can design a proper secrets store instead?
|
| Because the entire point of this is _NOT_ to store
| something but to transfer something from one application
| to another without both applications explicitly knowing
| about each other (so they can 't just communicate in a
| P2P fashion). The rest of your message is about storing
| data, which is not what the clipboard use is all about.
| Which is why i wrote it is irrelevant - you refer to
| something else.
|
| E.g.
|
| > clipboards are temporary which means you need to copy
| data into them. This creates an extra step for users to
| follow as opposed to applications querying the secrets
| store directly
|
| The API i mention is not about permanently storing data,
| it is explicitly about having a secure _temporary_ store
| with the same(ish) UX as a clipboard but for secure data.
|
| Applications can also use a secure store for that and the
| data that is being copied to the secure clipboard could
| also come from an application that stores its own data to
| it from there, but again this is a separate issue, this
| is orthogonal to what a discuss here.
|
| > secrets managers are encrypted, clipboard isn't
|
| This is irrelevant as the data isn't stored elsewhere
| outside the memory of the process that would manage the
| secure clipboard's functionality (and of course you could
| encrypt that if you'd like but IMO that'd be pointless
| since it'd need to be decrypted at some point anyway and
| these would be meant for temporary storage - regardless
| of you do or not encrypt it though it'd be again
| orthogonal to the rest of what i describe).
|
| > secrets managers can store multiple secrets, a
| clipboard cannot. Thus you then still need to have a
| secrets manager to copy your password into the clipboard
| anyway. So why not do away with that middleman entirely?
|
| Because this isn't about storage.
|
| > if you're going to introduce a new API for secrets then
| you might as well do it properly from the outset.
|
| That'd be a "proper" solution for a different problem,
| hence barely a solution at all.
| laumars wrote:
| I get that you're not storing something long term, but
| you are still storing it even if it is short term and
| thus presenting a risk. And you are still sharing secrets
| between applications thus presenting a risk. And all your
| suggestion is doing is offering a kludge around a
| solution you've already said is crappy, rather than
| switching to a robust and battle tested solution that
| literally every other platform already supports.
|
| If you want to pass secrets securely between applications
| then you use a secrets manager. It's how Linux and macOS
| work. It's how secure systems in the cloud works. And
| thus it makes complete sense for Windows to follow suit.
| We aren't talking about some theoretical concept here. It
| is absolutely how passing secrets between applications
| _should_ be done.
|
| If you have scepticism about this approach then you need
| to read up in this topic rather than pushing for a half
| baked kludge around something you've already acknowledged
| isn't fit for security.
|
| Sorry if this sounds blunt but this is a solved problem
| you're trying to re-engineer and your solution is worse
| than the industry standard in a number of ways which I've
| already highlighted. And ironically it isn't even just
| worse for security but also worse for usability well
| (you're creating administrative overhead with the user
| approving safe applications. This wouldn't be needed with
| a secrets manager since each application only has
| visibility of its own enclave). And if you remember back
| to your first post, usability was the entire reason you
| designed this solution in the first place.
| badsectoracula wrote:
| I do not know why you mention Windows, i never referred
| to any specific platform (you mention Linux, Linux does
| not actually have what you describe because Linux is a
| kernel and what you describe is something that would live
| on the userland - the userland heavily relies on what
| software is installed and many setups, like mine, do not
| have such a thing).
|
| What i refer is how to provide a more secure approach to
| to THE SAME THING that people are already doing with
| clipboard copy/paste without breaking the versatility of
| the clipboard, workflows or even existing applications
| and can be supported with minimal changes in existing
| applications and pretty much zero re-learning by users.
| It is about being able to copy/paste stuff securely
| _anything_ that can already be copy /pasted between
| applications and not just passwords or other stuff you'd
| need to store permanently. It can even be made to work in
| a backwards compatible way - with some additional though
| minimal effort from the user - for applications that do
| not support the functionality.
|
| What you refer to is having a different workflow, have
| applications add explicit support for the specific data
| mentioned and be accessed in a different way and up to
| the last reply you were referring to permanent storage.
|
| You ask people to change how they use software, i ask
| them to use a different menu option for sensitive stuff.
| What exactly do you think is the more likely to happen?
|
| (well, assuming anything would happen, in practice most
| likely nothing will change)
|
| I do not have skepticism about what you refer to, i do
| not even think what you refer to is wrong for the stuff
| it is intended for, i am just not referring to the same
| stuff you do.
| laumars wrote:
| > I do not know why you mention Windows, i never referred
| to any specific platform
|
| Because this is already a solved problem on all popular
| platforms aside from Windows.
|
| Plus others earlier in this discussion singled Windows
| out too (likely for the same reason I cited above).
|
| > Linux does not actually have what you describe because
| Linux is a kernel and what you describe is something that
| would live on the userland - the userland heavily relies
| on what software is installed
|
| It's pretty normal for people to talk about Linux as a
| computing platform. You know this yourself so making the
| "it's just a kernel" argument is next level pedantry.
|
| > and many setups, like mine, do not have such a thing
|
| I'd put money on you having one installed and not even
| realising it (eg gnome-keyring, which is a dependency for
| many desktop applications even without having gnome
| installed)
|
| > What i refer is how to provide a more secure approach
| to to THE SAME THING that people are already doing with
| clipboard copy/paste without breaking the versatility of
| the clipboard
|
| I understood what your approach was. The issue isn't that
| I don't understand it. The issue is that you are
| unwilling to accept the last 20 years of development in
| this field.
|
| I mean have you never even used password management in
| Firefox / Chrome? Avoiding the need of clipboard for
| sharing secrets is a security and usability _feature_.
| Your solution is terrible in comparison and this is
| precisely why browsers have integrated password stores.
|
| > What you refer to is having a different workflow, have
| applications add explicit support for the specific data
| mentioned and be accessed in a different way and up to
| the last reply you were referring to permanent storage.
|
| Your solution was to add a new API. You stated that
| explicitly. You then said users should authorise which
| applications have authority to use that API, that's a new
| workflow too. The standard approach (ie that way the
| industry works, this isn't something I've just made up)
| allows applications to communicate directly to your
| secrets store. This doesn't add a new workflow, it
| removes an existing one entirely.
|
| Plus you still need to copy your passwords from somewhere
| to use your API so why bother with it in the first place?
| It's literally just adding in a process for the sake of
| it. Except that process is insecure, a usability
| nightmare and contradicts decades of established
| solutions in this precise domain.
|
| The fact that you're refusing to even look into this
| concept is astonishing tbh
|
| > am just not referring to the same stuff you do.
|
| indeed, your stubbornly clinging onto a terrible idea and
| rejecting decades of industry best practices.
|
| The idea you're proposing has already been superseded by
| years of research and development towards much better
| solutions. And you can install them right now if you
| wanted. I'm not making this shit up.
| [deleted]
| pmontra wrote:
| Of course if an app asks for some very dangerous
| permissions somebody will grant them to it even if they
| don't belong to the app's advertised functionality.
|
| Naming and description could help a little: Full access
| to copy and paste (maybe somebody doesn't know what
| clipboard means), it allows this app to access everything
| is selected and copied including passwords, private data,
| etc. Only keyboards and clipboard managers should get
| this permission.
| badsectoracula wrote:
| > Naming and description could help a little: Full access
| to copy and paste (maybe somebody doesn't know what
| clipboard means), it allows this app to access everything
| is selected and copied including passwords, private data,
| etc. Only keyboards and clipboard managers should get
| this permission.
|
| I don't think the problem of users not reading the text
| in warning messages can be solved with having them read
| even more text.
|
| Actually this is an old problem, people do not read
| message boxes, popups, warnings, etc:
|
| http://www.zuschlogin.com/?p=53
| kibwen wrote:
| _> That 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._
|
| To be clear for others who may be reading this, this statement
| isn't a hypothetical, web browsers _do_ prevent web pages from
| reading the clipboard.
| dethos wrote:
| > 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 being in focus or
| sent any input first.
|
| Author here, yes, this is indeed the point of the article.
| Desktop operating systems could/should have implemented such a
| feature a long time ago, it is clearly a security "blind spot"
| at the moment.
| IshKebab wrote:
| Not really though. It makes sense for mobile OSes because
| they have proper isolation of apps, but desktop OSes don't
| have that. Apps can pretty much do anything.
|
| What's the point of copy notification if apps can just read
| all your emails and steal all your files anyway.
|
| Android and iOS both have this feature already. That's the
| best we can do for now.
| nitrogen wrote:
| Desktop OSes all have some form of optional sandboxing now,
| so it makes sense to keep chipping away at the edges of the
| attack surface.
| phkahler wrote:
| It would make sense to sniff clipbaod paste commands and offer
| the active app a one time read access for each user provided
| interaction.
|
| Not sure about the value of requiring the same for writes, but it
| wouldn't hurt.
|
| Any time an unauthorized read is attempted the user could be
| informed.
|
| Not sure where this would get plumbed in. Needs support at the
| toolkit level (menu->edit->paste) and some higher level outside
| apps.
|
| The idea is to obey the users implicit concent and flag
| everything else.
| DavideNL wrote:
| Related tool for macOS: https://langui.net/clear-clipboard/
|
| _Clear Clipboard allows you to clear the clipboard content
| manually or automatically, preventing your clipboard data from
| being peeped while you are absent._
|
| _You can chose to clear the clipboard content every few seconds
| and enable clearing clipboard on computer sleep / display sleep /
| screen lock to maximize protection of your sensitive clipboard
| data._
| jonnypotty wrote:
| I used to support a terminal services/citrix environment and we
| had repeated instances of people trying to copy and paste data
| and getting other peoples data. Never got anywhere investigating
| and boss refused to go to Microsoft. I'd forgotten about it till
| I read this.
| abaines wrote:
| With most installations of X11 / Xlib, there is also an extension
| library: libXFixes. With this, it is possible to receive an event
| whenever the clipboard (or any other selection) changes (even if
| our program is not the owner). [0]
|
| I used this in the past when porting a Windows text editor to
| Linux that needed to know when the clipboard had changed.
|
| In the C bindings, it corresponds to
| XFixesSetSelectionOwnerNotifyMask / XFixesSelectionNotifyEvent.
| There is also a SelectionNotify event in the core X11 protocol,
| but I'm pretty sure it is different (occurs in response to
| XConvertSelection - asking for the clipboard contents). Though it
| has been some time since I wrote the code I'm looking at.
|
| [0]:
| https://www.x.org/releases/current/doc/fixesproto/fixesproto...
| (6. Selection Tracking)
| CyberShadow wrote:
| I think the goal here is to be notified when an application
| accesses the clipboard, not modifies it. You need to be the
| owner to do that (excluding some system-wide hack like patching
| the X server or MITM-ing all X11 connections).
| ZeroGravitas wrote:
| This is part of the reason I don't set Vim to automatically fill
| the system clipboard and only do so on demand.
|
| I think a few other geeky apps let you cut and paste internally
| as a separate thing from the global clipboard, which seems wise
| as a mitigation.
| root5 wrote:
| As iOS and macOS share their clipboard over BLE, one can abuse
| this feature for various things like smart home automation.
|
| https://twitter.com/m33x/status/1489236070151737351
| pierrefermat1 wrote:
| If I read the tweets correctly this is only capable of
| capturing the event happening and not the content? I don't see
| this too much of a privacy issue
___________________________________________________________________
(page generated 2022-02-05 23:02 UTC)