Isn't that equivalent to saying that the set of available kernel calls should be more restricted?

(User mode is a kind of sandbox, after all)

But as my other comment mentions [1], I wish I had the knowledge required to understand the meaning / implications of Flatpak apps. Please let me know if I'm misunderstanding :)

Happy Saturday night y'all !

[0] http://docs.flatpak.org/en/latest/working-with-the-sandbox.h... [1] https://news.ycombinator.com/item?id=16351192

At the end of the day people don't care about security that much. Wayland is still getting there. Its getting better, particularly in the last year, but its not a huge priority for many people so it has taken upwards of ten years to become usable.

I think many people are also not aware of how bad X11 security is. The other day I mentioned that X11 applications can read all keystrokes to someone who does system administration/security at an ISP. To my big surprise, he was not aware of this. (Didn't everyone play with xev at some point?)

On Linux, I only use Wayland because of X11's broken security model. Fortunately, it works very well these days with the amdgpu driver.

And let's not forget that just using Wayland doesn't grant any improved security compared to X11. There are numerous other ways to get input data, display contents, etc., so you need further sandboxing anyway, at which point you might just as well sandbox X11 clients you don't trust to get the same security. The benefit here is that you can decide if you trust your color picker and let it do its work by not sandboxing it, while Wayland just decides for you that no color picker can be trusted.

Because you can't do that in Unix. You can't ensure that the process with PID 1234 is really executing /usr/bin/foo.

I read that GNOME just implements both in the same program (and calls it "shell").

> Or how can you ensure that the shell is not a rogue one?

I'm confused. Do you mean this kind of attack would become somewhat more probable or more dangerous if the original shell had some mechanism of allowing certain apps to pick colors?

[1] https://access.redhat.com/solutions/3176 <--- here they show how to turn it off because it's in enforcing mode by default.

Briefly, SELinux adds some new permissions to files, new contexts to users and so on, so what happens is you specify what a given context is allowed to do, to a very granular level. For example, if you take postfix, it's split up into lots of programs, so you could say that the "init" context is allowed to run the postfix startup script but none of the rest of it. The postfix startup script will convert into some "postfix startup" context which is allowed to start the various programs but nothing else. So there will be a a postfix process that allows incoming IP addresses and can send on a specific FIFO and nothing else. There is another program which can read from the FIFO, change certain files and nothing else. So, imagine if you break into the program that talks with the internet: all you can do at that point is talk with the internet and talk with the FIFO. You can't read any files, write anything, execute anything, etc.

So that's kind of the idea of it. The above assumes an extremely tight SELinux configuration and no bugs in SELinux that would allow you to break out of your context. I've never seen a configuration as tight as described above but there did use to be a guy who had a Debian linux machine running on the internet where you could log in as root and try to break stuff. As far as I know, no one ever hacked that machine, starting out as root in a bash shell.

For example, in order for the Color Picker Tool to work, The Gimp should be marked with a "color picked allowed" capability, so when it asks the Wayland server for the color of pixels outside the surfaces it already owns, the server can check it and send the requested info. But a rogue program/process trying to scrap the screen content pixel by pixel shouldn't be able to do that. The inability to safely map processes to executables in Unix (and the possibility of manipulating their running code via exec(), library injection, ...) make it a very hard problem to solve without a paradigm shift that SELinux doesn't provide (as far as I can tell).

So the benefits of the easier sandboxing provided by Wayland are somewhat overstated, at least for typical Linux users.

Like how often does software need to do screenshots, not many. Same with most other app permissions. Most only need network access and a folder.

With the permission model of apps, then we can start having system apps like istat menus being sold on the app store again too.

I think you haven't used iOS that much. In practice it's fairly rare for an app to shut down without a permission unless it's central to the app.

Also android takes a while to propagate new versions onto the majority install base :)

I regularly use Borland C++ 5 (because it has a nice enough customizable IDE and a very fast C compiler which is practically instant on modern PCs), which (IIRC) was released in 1996. And i also use a ton of other stuff from the 90s, including many games.

Things already work without the overhead and resource wastage of virtual machines, all it takes is OSes and libraries try to not break their ABIs.

Not "especially for apps that don't need the Internet", only for apps that don't need the Internet. Anything that connects to the Internet needs constant and rigorous update discipline to stay ahead of a constant stream of exploits.

Sandboxing applications within their own VMs leads to a false sense of security. Now, whoever is responsible for distributing the app, is responsible for distributing the OS that runs the app as well. If the underlying OS doesn't get updated, Murphy guarantees that there will be an OS-level exploit within that VM. And then, even if the exploit is sandboxed to only affect that app and its OS, the attacker still owns anything that the user passes through that app, including but not limited to usernames and passwords (which are often reused across websites and apps), any sensitive information that passes through the app (banking and financial accounts, anybody?), and any privileges existing within the VM (session tokens, client keys, privileged access / firewall passthrough to other machines in the local network, etc.).

It's one thing to sandbox each app within its own userland-level sandbox, but sandboxing each app within its own VM / OS only makes security even more difficult. That kind of deployment model only makes sense if a sysadmin is doing so to make deployments more predictable and has the full power to reinitiate deployments when OS updates are released. On an end-user level, you're either risking the end-user's security (if upstream controls the OS update) or wasting the end-user's resources.

I do. I don't know exactly what my oldest binary is, but it's probably from the 80s (some text processing utilities), and I still actively use apps I wrote myself over a decade ago. Of course, I use Windows which has historically been far better at backwards compatibility than Mac OS.