5 ms·

> In practice if you do not trust an application you can isolate it, though it is really futile since applications can simply use other means than X to "spy" yo

by nicce 5y ago

> In practice if you do not trust an application you can isolate it, though it is really futile since applications can simply use other means than X to "spy" you. X already provide functionality for doing that but if you are really paranoid (why are you running untrusted applications in that case?) you can run a nested X... or even X under Wayland under X. This exactly is the point. Wouldn’t it be nice to just use apps without extra steps? It would make Linux better for non-experts. You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing. Applications cannot normally spy on you unless you run everything in root. It is X.org which provides access for keystrokes and windows. > Xorg is an open source program, you can't "end of line" an open source program, it isn't Visual Basic 6 that died because Microsoft decided it should die. As long as someone wants to improve it, it will get improvements. Because the design is bad, it gets harder and harder to add new features. Fixing bug introduces two new ones. Complexity makes it hard to approach project and control everything. Red Hat has maintained it so many years with proper funding, otherwise who knows what would have happened.

yjftsjthsd-h 5y ago
> This exactly is the point. Wouldn’t it be nice to just use apps without extra steps? It would make Linux better for non-experts. non-experts won't use desktop linux regardless, give me back my power tools
GhettoComputers 5y ago
>This exactly is the point. Wouldn't it be nice to just use apps without extra steps? It would make Linux better for non-experts. I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face. >You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing. Not a real world scenario problem. >Because the design is bad, it gets harder and harder to add new features. Fixing bug introduces two new ones. Complexity makes it hard to approach project and control everything. Red Hat has maintained it so many years with proper funding, otherwise who knows what would have happened. Wayland design is... good? So it's taken over a decade to add a fraction of x.org features, and it still crashes? If it so simple and it still sucks, are you calling the programmers incompetent for not making the simple compositor functional?
- nicce 5y ago
  > I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face. The best practice is zero-trust; handle everything equally. You can't fully say by yourself which is really trustable, and if you are, then you are 0,01% of the actual population, and decision cannot be based on that. > Not a real world scenario problem. Of course it is, it is the biggest attack surface for normal application.
  - GhettoComputers 5y ago
    >Of course it is, it is the biggest attack surface for normal application. What real cases have had this happen?
    - shatteredgate 5y ago
      Are you asking when the X server has been exploited? There have been a lot of published root priv exploits published over the years. A few were just published yesterday: https://lists.x.org/archives/xorg/2021-December/060840.html https://lists.x.org/archives/xorg/2021-December/060840.html This type of thing is pretty common in old applications like this with a lot of hand-rolled networking code written in C.
      - GhettoComputers 5y ago
        No, I am asking about attacks in the wild. I know spectre and meltdown were possible to exploit, but its different from it existing as an attack, like a recipe versus a cooked meal. Thank you for your expertise in the thread.
        shatteredgate 5y ago
        I'm not sure what you mean by attacks in the wild. I don't have any news stories talking about how companies lost millions of dollars due to an X.org-based ransomware; but I hope you can see how it's not a good idea to wait for that to happen before fixing a security bug :)
badsectoracula 5y ago
> You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing. Actually you can, the X server can run applications in an untrusted state where they cannot see other resources. It is not straightforward to setup though so running a nested X server is much simpler - at least until you realize that the same "untrusted" app has access to the rest of your system anyway. > It is X.org which provides access for keystrokes and windows. You can avoid that if you want but as others have mentioned you are way more likely to need that functionality for legitimate purposes.
- nicce 5y ago
  You can finetune access control of your app into filesystem for example with AppArmor, but access for X.org is always required, remaining as the biggest attack surface.
  - badsectoracula 5y ago
    If you are going to configure something like AppArmor then you can certainly configure X to treat an application as untrusted.
    - shatteredgate 5y ago
      Neither are really good options for graphical applications. The focus now is on using container sandboxing, at least with things like flatpak and snap anyway.

by nicce 5y ago

yjftsjthsd-h 5y ago

> This exactly is the point. Wouldn’t it be nice to just use apps without extra steps? It would make Linux better for non-experts. non-experts won't use desktop linux regardless, give me back my power tools

GhettoComputers 5y ago

>This exactly is the point. Wouldn't it be nice to just use apps without extra steps? It would make Linux better for non-experts. I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face. >You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing. Not a real world scenario problem. >Because the design is bad, it gets harder and harder to add new features. Fixing bug introduces two new ones. Complexity makes it hard to approach project and control everything. Red Hat has maintained it so many years with proper funding, otherwise who knows what would have happened. Wayland design is... good? So it's taken over a decade to add a fraction of x.org features, and it still crashes? If it so simple and it still sucks, are you calling the programmers incompetent for not making the simple compositor functional?

nicce 5y ago
> I don't run untrusted apps, at the cost of crashing, and less overall functionality? Its cutting the nose to spite the face. The best practice is zero-trust; handle everything equally. You can't fully say by yourself which is really trustable, and if you are, then you are 0,01% of the actual population, and decision cannot be based on that. > Not a real world scenario problem. Of course it is, it is the biggest attack surface for normal application.
- GhettoComputers 5y ago
  >Of course it is, it is the biggest attack surface for normal application. What real cases have had this happen?
  - shatteredgate 5y ago
    Are you asking when the X server has been exploited? There have been a lot of published root priv exploits published over the years. A few were just published yesterday: https://lists.x.org/archives/xorg/2021-December/060840.html https://lists.x.org/archives/xorg/2021-December/060840.html This type of thing is pretty common in old applications like this with a lot of hand-rolled networking code written in C.
    - GhettoComputers 5y ago
      No, I am asking about attacks in the wild. I know spectre and meltdown were possible to exploit, but its different from it existing as an attack, like a recipe versus a cooked meal. Thank you for your expertise in the thread.
      - shatteredgate 5y ago
        I'm not sure what you mean by attacks in the wild. I don't have any news stories talking about how companies lost millions of dollars due to an X.org-based ransomware; but I hope you can see how it's not a good idea to wait for that to happen before fixing a security bug :)

badsectoracula 5y ago

> You can’t even isolate X applications without running other X.org because there is no permission control once the application has access into socket, and with socket it can see everything. And you can’t really rework that. Sometimes you need to rewrite whole thing. Actually you can, the X server can run applications in an untrusted state where they cannot see other resources. It is not straightforward to setup though so running a nested X server is much simpler - at least until you realize that the same "untrusted" app has access to the rest of your system anyway. > It is X.org which provides access for keystrokes and windows. You can avoid that if you want but as others have mentioned you are way more likely to need that functionality for legitimate purposes.

nicce 5y ago
You can finetune access control of your app into filesystem for example with AppArmor, but access for X.org is always required, remaining as the biggest attack surface.
- badsectoracula 5y ago
  If you are going to configure something like AppArmor then you can certainly configure X to treat an application as untrusted.
  - shatteredgate 5y ago
    Neither are really good options for graphical applications. The focus now is on using container sandboxing, at least with things like flatpak and snap anyway.