3 ms·

Speaking very generally (there's always room for improvement), this is a feature. X programs are able to interact in interesting ways. Isolation can be a good t

by pdkl95 11y ago

Speaking very generally (there's always room for improvement), this is a feature. X programs are able to interact in interesting ways. Isolation can be a good thing and I would love to have more options for sandboxing programs (with or without X), but stuff like keylogging and sending events to windows are very useful. Removing the ability to do stuff like query the state of the mouse would break useful tools I use. The ability to keylog my keyboard or mouse is a potential risk, but it's also a necessary feature. As DHH explained[1], nerfing useful tools just causes people to find other ways to do the same thing, sometimes with worse consequences. The "window composition only" approach of Wayland where it is simply assumed that this can be handled in e.g. the GUI toolkit is problematic if you have programs that don't use that toolkit. The windowing server is really the wrong layer implement this isolation - it makes useful things much harder while not actually providing a lot of security; if a malicious program is already running as the user, there are already endless ways it can harm the user without touching the UI. Real sandboxing would be, for example, a way to open a Wayland-style framebuffer that can be handed to a FreeBSD-style jail (or as "hardware" in a full VM). [1] https://vimeo.com/17420638#t=27m27s https://vimeo.com/17420638#t=27m27s

deleted 11y ago
[deleted]
the_why_of_y 11y ago
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

by pdkl95 11y ago

deleted 11y ago

[deleted]

the_why_of_y 11y ago

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