3 ms·

Looking at this from the other end, the problem is, as long as clients of the window server aren't isolated against each other, any other kind of sandboxing (su

Looking at this from the other end, the problem is, as long as clients of the window server aren't isolated against each other, any other kind of sandboxing (such as restricting file system access) is pointless: a compromised application can just synthesize input events for some other application to give it what it wants. The next step towards real sandboxing is applications with cgroups and namespaces (quite similar to FreeBSD jails), as in xdg-app. https://wiki.gnome.org/Projects/SandboxedApps/Sandbox https://wiki.gnome.org/Projects/SandboxedApps/Sandbox

pdkl95 11y ago
> any other kind of sandboxing (such as restricting file system access) is pointless That's my point - I don't want most of my "desktop" applications sandboxed from each other. That would be unusable. That kind of sandboxing should be done by nesting the entire display server, creating a separation point. In the future, with all clients sandboxed from each other, how can I write a tool that does the following (which was easy under X): * monitors the keyboard input of another process * sends new (synthetic) key events to that process when it sees a certain key press (keyboard macro) * does not depend on any support from the process being monitored * works with any existing program, including proprietary software that cannot be recompiled because the source has been lost Interaction is necessary at the GUI layer, because that's the intended goal of some software. As I initially said, there is certainly room for improvement. However, simply pretending these use-cases don't exist is foolish. As Joel Spolsky so famously explained[1], all that "cruft" that is cut out during a big rewrite is real-world fixes and necessary features that were added over time. Unfortunately, the GNOME team has been engaging in that kind of narcissism for many years, which is why more and more people are ignoring them. > real sandboxing > cgroups and namespaces Good luck with that; cgroups and namespaces are not designed for security. They are only superficially like jails. [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

pdkl95 11y ago

> any other kind of sandboxing (such as restricting file system access) is pointless That's my point - I don't want most of my "desktop" applications sandboxed from each other. That would be unusable. That kind of sandboxing should be done by nesting the entire display server, creating a separation point. In the future, with all clients sandboxed from each other, how can I write a tool that does the following (which was easy under X): * monitors the keyboard input of another process * sends new (synthetic) key events to that process when it sees a certain key press (keyboard macro) * does not depend on any support from the process being monitored * works with any existing program, including proprietary software that cannot be recompiled because the source has been lost Interaction is necessary at the GUI layer, because that's the intended goal of some software. As I initially said, there is certainly room for improvement. However, simply pretending these use-cases don't exist is foolish. As Joel Spolsky so famously explained[1], all that "cruft" that is cut out during a big rewrite is real-world fixes and necessary features that were added over time. Unfortunately, the GNOME team has been engaging in that kind of narcissism for many years, which is why more and more people are ignoring them. > real sandboxing > cgroups and namespaces Good luck with that; cgroups and namespaces are not designed for security. They are only superficially like jails. [1] http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html