> 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.

> 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).

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.

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.

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.

> 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.

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.

> 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.

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.

> 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.

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.