Wayland will also solve a few of these problems.
Personally, I'm of the opinion that the Linux security model is a horribly outdated ticking time-bomb and people really aren't taking it seriously enough. It drives me kind of crazy; a lot of people act like X security is no big deal, like it's fine that our primary security model for Linux is just based on file permissions. I think that once we have a better permissions system in place people are going to look back with 20/20 hindsight and say "Well duh, of course apps should be isolated from each other and the system in general. Everyone knows that."
There are two permissions that my desktop/web/mobile environment doesn't ask me for that would prevent most attacks like this: network access and cpu access.
Network access is obvious. It kind of boggles my mind that apps can by default just access the network and make a request to any server that they want. Blocking that alone would take care of a huge number of crypto miners (and spyware), because they all need network access to operate. There are almost no good reasons I can think of for a desktop app to have network access by default.
The less obvious permission that I think is probably worth exploring is CPU access. I don't necessarily know what a control for that would look like in a standard permission system, but if an app wants to start going crazy with my CPU, whether they're being malicious or just innocently inefficient, my OS/browser/phone should probably bring it to my attention and give me the opportunity to either permanently throttle them or set some kind of ground rules.
Vista and subsequent reduced the problem by introduce levels, so that lower-privileged applications can't interact with higher-privileged, but as far as I know they can still interact with applications at the same level.
And Microsoft is still quite confident that eventually Win32 will join Win16, even if it takes considerably longer that they were initially willing to wait for.
>Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification.
Of course you should also prevent the program from reading the original privileged Xauthority data. Running it as a different user does the trick.
It's not really fine grained and also doesn't prevent untrusted clients from meddling with one another, but seems like a starting point for someone inclined to add more security to X.
By the way Android, unlike Linux, runs every app under a different user account.
Regardless of whether you love or hate Electron, its rise in popularity has clearly shown that a number of HN users feel like they don't have complete control over their computer's resources - that their only choice is to either avoid an app entirely or slow down their computers.
A user should be able to pick up an application and easily say something like "you can have up to 2 CPUs and 250mb of RAM. If you want more, come back and ask me." And honestly, if Google couldn't trust that most users would give it unfettered access to 4 gigs of RAM, I bet their engine would magically get a lot more efficient really quickly.
You are often right that you either supply the resources an app needs or you don't. However, there are a growing number of apps I'm seeing that act more like goldfish - they grow to the size of the container they are put in.
I also occasionally run into apps where I'm OK with bad performance, I just don't want them to interfere with other tasks that I have.
I might decide that I'm OK with a version of Slack on my work computer that runs poorly and that occasionally starts caching stuff to disk - as long as the rest of my computer doesn't slow down. Not every app that I'm using needs good performance - some are more important than others. This is especially true for background apps like a backup system, file sync, update, anything where I don't really care if a task takes longer to finish.
It also might be worth exposing some kind of more fine-grained policy; something like "I want this app to have full access to my CPU if it's in the focus, but if I minimize it, I want you to reduce its resources or even suspend it."
And of course there is the (perhaps naive) hope that as CPU and RAM become a resource where users control access in the same way that they control location or camera access, developers might start to include resource-heavy features as progressive enhancements. This has... sort of... worked on the web with resources like location. So it's unlikely, but possible.
It's still nothing to do with X, and it's not certain that it would plug the "hole" that is being used here.
This "exploit" requires unfettered (or at least not completely throttled) access to the CPU and a way to send the spoils home via the network.
Would this actually be stopped with "lxc"? I doubt it'd do much to curb the CPU abuse, and network access is something games frequently demand (in something like this for e.g. leaderboards or a social sharing feature), so I'd bet that nobody would bat an eye.
This way you don't have any overhead, you preserve backwards compatibility with the protocol, existing programs that need the functionality of accessing each others' data (window managers, panels, tools like xdotool, screenshotting tools, etc) can keep working like they always were and you still get to implement sandboxing (with or without snaps/flatpack/etc) without breaking the Linux desktop.
>"X has no real concept of different levels of application trust. Any application can register to receive keystrokes from any other application. Any application can inject fake key events into the input stream. An application that is otherwise confined by strong security policies can simply type into another window," he wrote.
They might have wrapped X protocol to provide more security and control. Instead they decided not to.
They might have created a system which is as bulletproof as on iOS where you can install any apps and be 99.9999% sure that they won't steal your data unless you allow them to. But they created this instead.