[solomatov]

The problem with snaps is that they didn't take security really seriously on desktop: https://www.zdnet.com/article/linux-expert-matthew-garrett-u...

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

[danShumway]

Flatpak has been making moves in what I think is the right direction, which is containerization and dynamic privileges[0].

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.

[0]: https://www.youtube.com/watch?v=4569sjVer54

[icebraining]

On Windows, the equivalent to the X problem was called a Shatter attack: https://en.wikipedia.org/wiki/Shatter_attack

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.

[pjmlp]

That was fixed on Windows 8 and later with all store improvements.

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.

[btashton]

The issues with X11 you mention is part of what Wayland tries to fix. And why early on seemingly benign things like screenshot tools broke.

[solomatov]

Yes, I understand that there're people in the community who try to fix the problems. But it's really unfortunate, that Canonical tells us that it's secure whereas it's not: https://snapcraft.io/

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

[matthewbauer]

From what I gather, Snappy is mostly a marketing gimmick by Canonical. If you want to packages apps, you should use something like FlatPak or AppImage.

[solomatov]

Do you know whether they more secure than snaps? I like the idea of running whatever I want on my hardware without compromising security very much.

[gitgud]

Wow that explains why "Shutter" (screenshot tool) doesn't work with wayland!!

[mikedelfino]

Doesn't Xauthority solve this? I thought we could use xauth to generate an unprivileged cookie and launch the program using it. Then it could not meddle with other X clients or even the clipboard.

Of course you should also prevent the program from reading the original privileged Xauthority data. Running it as a different user does the trick.

[vbernat]

Xauthority isn't fine-grained. Once you get a cookie, you haven't any restriction to what you can do with the X server.

[mikedelfino]

We could generate an "untrusted" cookie. This prevents clients using it from meddling with "trusted" clients.

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.

[codedokode]

In a typical linux distro all apps are run under the same user which means they can do whatever they want to each other and user's files. So X server being secure or not doesn't really change anything.

By the way Android, unlike Linux, runs every app under a different user account.

[drdrey]

In this case though it's not really a security issue as you describe and more of an abusive use of resources. I don't mean to be facetious but that's also what Electron apps do to some extent

[danShumway]

It might not be a full-fledged security issue, but it's at least a user control issue. Why can't we easily set hard CPU/RAM/Storage limits for Electron apps?

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.

[xfer]

How does that help? You already know that app is not going to work (well) with 250M, nagging the user for more RAM doesn't solve anything. Either you run an app written with resource constraint environments in mind or you don't.

[danShumway]

It may not be common, but I occasionally run into apps that will work will with limited resources but that will happily expand outwards if given the opportunity. Perhaps a bad example, but the code for this cryptominer itself checks how many CPUs you have before it starts.

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.

[faho]

But this particular issue doesn't have anything to do with X!

[64kbisalluneed]

One word: lxc

[faho]

And the explanation for that word?

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.

[64kbisalluneed]

Sorry, missplaced my answer. It was regarding the guy above yours concerning apps in general can create havoc to a system. I mean that using containers like lxc can create a sandbox.

[michaelmrose]

Containers under linux aren't in themselves very secure at all. This isn't inherently so. Supposedly solaris can do much better for example.

[irundebian]

What security guarantees cannot be hold by container technologies such as LXC, cgroups, namespaces and docker?

[aritmo]

There's not much to do with X without breaking the protocol.

[detaro]

... without additional overhead and engineering effort. You can sandbox an X application by running a dedicated X server in the sandbox and pass only a secured channel out.

[badsectoracula]

No need for that overhead, simply disallow untrustred clients, trusted clients that explicitly request to drop down to untrusted (e.g. browsers could do that) and clients the user explicitly marks as untrusted to access other clients' data. Xorg already has most of this functionality (AFAIK all remote/socket connections can be made untrusted) and last time i heard about it, it is something some X developers are going to look into improving.

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.

[solomatov]

If nothing can be done, then there should be no claims of security.

[michaelmrose]

I think securing X would reasonably be viewed as a non starter for those who intend to replace X with wayland.

[the_why_of_y]

In the sense that Wayland is what the X.org maintainers came up with as the solution to X11's security design flaws. (There was a previous attempt in XACE, which essentially extended SELinux's security model into the X server, but somehow that never caught on.)

[emersion]

Wayland solves some of these issues.