A malicious Pidgin plugin

The "Just use X, it solves all your problems" style post are a menace.

Agreed. Yeah. a general-purpose sandbox probably can't help with that. You'd probably have to put the plugins in a special-purpose sandbox with no TCP/IP access and expose a high-level message-sending API that you could reasonably filter on. Dunno if that would even be practical here.

That said, a good Flatpak-like sandbox should limit what a keylogger could collect, and IMHO that's pretty valuable already.

A Flatpak repository like Flathub is "the same shape" as a mobile app-store like Google Play or Apple's App Store: the developer packages and submits their app, including choosing what sandboxing parameters (permissions) they will ask for, but the app-store curator is in a position to say "no, we think these permissions are excessive, reduce them or we won't publish your app" if they want to. Flathub doesn't have armies of testers and developer contacts (or a large enough budget to have them), so as far as I know it isn't currently particularly proactive about enforcing review before an app update is published, but in principle it could be.

Flatpak is federated, so you don't *have* to use Flathub (you could download your apps from a different repository), but adding a repository as a source of apps does involve extending some trust to the curators of that repository - not as much as with a traditional packaging framework like apt/dpkg, but some.

The user also has the opportunity to look at what the app is asking for[1] and accept or refuse installation accordingly, again similar to the way some of the more "static" permissions are handled by mobile app-stores.

Of course, if an app legitimately needs a "powerful" permission like screen-sharing in order to do its job, then no amount of review or sandboxing can prevent it from exercising that permission in ways that you didn't want it to, so a Flatpak-style sandbox would not protect you from this particular malware. An app that is malicious or compromised can do anything that its sandbox allows, and its sandbox needs to allow everything that was necessary for it to work as designed; even if the user is asked for permission every time, a competent malware author will disguise their request for access as a request for something that is legitimately needed, for example only starting to exfiltrate screen contents when legitimate screen-sharing functionality is activated.

Also, Flatpak's approach to packaging is focused on apps, more than plugins for those apps; and there is typically no privilege boundary between an app and its plugins, because in a typical plugin architecture they're loaded into the same address space as the app itself and can arbitrarily overwrite its memory. That's another reason why Flatpak-style sandboxing would not have helped a whole lot in this scenario, where a non-malicious app (Pidgin) loads a malicious plugin and becomes compromised as a result. If there is no security boundary within the app, a sandboxing framework like Flatpak can't magic one into existence.

---

[1] assuming a high-quality UI; GNOME Software has this, KDE Discover probably does too, and the flatpak(1) CLI has it but only in a developer-oriented format

> Either it has _full_ access to X, or it has _no_ access to X. There is no middle ground.

Yes. And it doesn't need access to X. Just wrap the parts you want to expose to plugins through the plugin API. Just like web browsers do, or even xdg portals on linux already do for things that aren't X.

> as others have pointed out, this plugin was explicitly billed as a screen sharing tool

Browsers are also screen sharing tools. But they have technical controls in place such that random websites in the background can't just start recording your screen. You have to authorize it every time, choose what you want to share and then you get a persistent screen element alerting you to the fact that your screen is being recorded.

In the rare case where you want it to do things outside of that sandbox you have to install a separate program that communicates with the browser, making it very obvious that you're breaching a trust boundary. Compromise through malicious browser plugins has plummeted since the removal of flash.

> even if this plugin's source code was provided and Pidgin compiled the binaries itself, it would have taken a careful manual audit of the source code to discover the plugin was sharing with an additional party.

Yes, which is why you need to set things up such that this is not straightforwardly possible to do. Pidgin had zero of the layers of swiss cheese that could have prevented this and the results are predictable.

> Meanwhile, as others have pointed out, this plugin was explicitly billed as a screen sharing tool. So even if it was technically possible to restrict access to the screen and/or input events (eg through use of Wayland instead of X), the user would have granted those permissions anyway, as that's the reason they installed the plugin in the first place.

For the screen sharing part, sure.

However, I don't know of any (generally-available) mechanism which would allow a Wayland client to receive keyboard input made while none of its own Wayland surfaces have input focus. (There's a portal for global shortcuts, that can't be abused for key-logging though)

Even for Wayland surfaces created by the Pidgin process, if the plugin didn't know their protocol IDs, it would be more difficult for the plugin to access them and their input via the Wayland protocol than it is via X (which makes it trivial really). Might not be impossible though.

Even via Xwayland, in a Wayland session this plugin could only log keystrokes meant for other X clients, not for native Wayland clients, let alone for compositor-internal dialogues.

I'll have to remember this example for next time someone like birdie claims "the Wayland restriction on keyboard input is pointless, there are no key-loggers taking advantage of X".