44 ms·

There is the X11 security extension but as far as I understand this only isolates X clients into two domains. Untrusted apps cannot keylog / screenshot your tru

There is the X11 security extension but as far as I understand this only isolates X clients into two domains. Untrusted apps cannot keylog / screenshot your trusted applications, but every untrusted client can keylog / screenshot any other untrusted client. If every client is untrusted this is pretty much useless. If there is a method other than running a dummy xorg server for each application I am very interested.

badsectoracula 5y ago
I haven't tried it for more than one client to make sure and i think there are still some things untrusted clients can do, but basically my point is that the functionality for Xorg to treat clients differently is there. I do not think modifying the code to have each untrusted client in its own domain would be too complex if someone cared to look into it (as well as adding further restrictions if necessary) - the main issue here seems to be that nobody really cared much about changing Xorg towards doing that. But there isn't really any core limitation of how X works that couldn't make it so that, e.g., some "privileged" applications (like the window manager) can decide what other less privileged clients can see and even create "domains" on the fly (as far as the applications are concerned it'd be like clients connecting/disconnecting from the server) for applications to see each other if needed. It could be possible if there were people interested in it (and interested enough to implement it, of course :-P).
- shatteredgate 5y ago
  This comment isn't really correct all, it's not possible to do that with the architecture of X. The best you can get is XSecurity and its related extensions, anything more than that is going to break the protocol. There is quite a good reason that Qubes has not even tried to get X to do this. The main issues are that the protocol is sequential and you can't reorder requests which makes modern polkit-style mechanisms practically infeasible, and also you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib because it is complicated and badly implemented. More about that here: https://news.ycombinator.com/item?id=21267275 https://news.ycombinator.com/item?id=21267275 BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
  - badsectoracula 5y ago
    > This comment isn't really correct all, it's not possible to do that with the architecture of X. Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and... > you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib ...any errors would be the same as if the other clients didn't exist and handled the same way. Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.

badsectoracula 5y ago

I haven't tried it for more than one client to make sure and i think there are still some things untrusted clients can do, but basically my point is that the functionality for Xorg to treat clients differently is there. I do not think modifying the code to have each untrusted client in its own domain would be too complex if someone cared to look into it (as well as adding further restrictions if necessary) - the main issue here seems to be that nobody really cared much about changing Xorg towards doing that. But there isn't really any core limitation of how X works that couldn't make it so that, e.g., some "privileged" applications (like the window manager) can decide what other less privileged clients can see and even create "domains" on the fly (as far as the applications are concerned it'd be like clients connecting/disconnecting from the server) for applications to see each other if needed. It could be possible if there were people interested in it (and interested enough to implement it, of course :-P).

shatteredgate 5y ago
This comment isn't really correct all, it's not possible to do that with the architecture of X. The best you can get is XSecurity and its related extensions, anything more than that is going to break the protocol. There is quite a good reason that Qubes has not even tried to get X to do this. The main issues are that the protocol is sequential and you can't reorder requests which makes modern polkit-style mechanisms practically infeasible, and also you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib because it is complicated and badly implemented. More about that here: https://news.ycombinator.com/item?id=21267275 https://news.ycombinator.com/item?id=21267275 BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
- badsectoracula 5y ago
  > This comment isn't really correct all, it's not possible to do that with the architecture of X. Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and... > you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib ...any errors would be the same as if the other clients didn't exist and handled the same way. Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.