3 ms·

>Some little things can help you protect your GUI apps if you're extra paranoid Can you explain this? What are the exploits? Is it the equivalent of running a

>Some little things can help you protect your GUI apps if you're extra paranoid Can you explain this? What are the exploits? Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? (Or am I trying to shove my windows ideas into linux?)

smoldesu 3y ago
> Can you explain this? What are the exploits? Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). This works really well for old apps (and admittedly not too bad for new ones) but is very slow and exposes a lot of bugs. On top of this, you have potential exploits in your filesystem from loosely permissioning important settings and identity files. So, the attack surface for a traditional Linux distro is relatively large. > Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? Kinda! Linux software is distributed as packages, which contains a binary (the exe/jar portion), a dependency manifest and whatever static content it needs. A sandbox like Flatpak will take those packages and put it into a sandbox, to prevent hostile interprocess communication and filesystem exploits. None of these mitigations are perfect per-se (nor are they on Mac/Windows), so use them wisely if you intend to use them at all. I have used a non-sandboxed system to run old 90s Windows games for years though, and haven't picked up any significant issues. YMMV, it is Linux after all :P
- hospitalJail 3y ago
  >Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). Oh gosh. I'm getting heart palpitations :P Is this a common attack vector then? Seems like an easy way to get an overflow error, or elevate privilege's.
  - bombolo 3y ago
    Not common at all. Because most software comes from distributions, not from warez.exe. Sandbox comes with a heavy usability price, so they are lax by default. For example you protect your files, but then you can't load your photos to facebook because your browser doesn't have access.
  - t0astbread 3y ago
    There's also a newer protocol called "Wayland" which aims to avoid some issues with X11 (and is also a general architecture overhaul). GNOME and KDE support it out of the box and iirc at least GNOME also enables it by default. There are some tradeoffs though. Some things like screen sharing might be worse on Wayland (e.g. I can't share a single window, only whole screens) and some apps don't support Wayland at all (including for example all of the IntelliJ IDEs). The latter can be circumvented by enabling XWayland (basically an X server running side by side with the Wayland compositor to handle X11-only apps). In that case you're left with the X11 security model for apps not running natively on Wayland.
    - JohnFen 3y ago
      And Wayland doesn't support being able to have multiple logons, each with their own independent desktop, simultaneously like X does. I just like to bring that up even though it's not a common use case, because that's what keeps me from using Wayland.
      - t0astbread 3y ago
        Interesting. Do you know why? I've only ever tried launching nested instances of Sway (the compositor I use) which each use their own sockets and render as a client to the parent compositor and that worked fine. Does it have something to do with rendering to a real display?
        JohnFen 3y ago
        I remember this being brought up early in Wayland development. The stance was taken that it wasn't a popular enough use case to be worth putting work into. I don't think there's any real technical reason why it couldn't be done, but I don't know. I'm not familiar with the architecture of Wayland.
        bandrami 3y ago
        I think seatd allows this now? So it works on the rather small sliver of distros that don't run systemd.
  - bandrami 3y ago
    "more-or-less" is doing a lot of work there. It uses a cookie-based authentication system (in fact I think that's where web browsers got the word "cookie" from) but it was intended for trusted networks; when it's done in other situations it's via kerberos or over an SSH tunnel. It's a pretty elegant setup, honestly, and one thing I miss when I'm on Wayland. The idea is you're at a small desktop on your University's network and you need to use some of the computing power of the big data servers they have. So you run e.g. a graphing program that does all of its computation on the big data machine but does its display on your little desktop (in this setup the big data machine is called the "client" and the tiny little desktop is called the "server" which confuses people a lot at first but makes sense when you get into the architecture). X itself had been moving away from this for years by adding some extensions that don't work well (or at all) over the network, but there are absolutely still lab setups that use the old way because it's pretty much tailor-made for it. The bigger security issue was that X programs could see and modify certain things about each other and about the system as a whole, so for example the program XEyes had a pair of eyes that pointed at the location of the cursor (it sounds silly but this was an accessibility thing). And a screenshot program could take a shot of the screen. And so on. Wayland got rid of all those capabilities, but there turned out to be a lot of baby in that bathwater so they're slowly adding back each of them, one at a time. In another decade a new crop of developers will no doubt say "What's all this needless cruft?! Let's start over!" and the cycle of life will continue.
- anthk 3y ago
  (U)XTerm can lock input to a terminal so snooping it it's impossible.
  - ElectricalUnion 3y ago
    That doesn't help when a bunch of disparate credentials are entered and cached in a shared runtime environment inside the same bunch of processes (aka: your browser). Obligatory XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
    - anthk 3y ago
      You have pledge and unveil under OpenBSD. Or, if you are truly paranoid... just create another Unix user for sensible web browsing and log in with that account: useradd -m webcare passwd webcare Done.

smoldesu 3y ago

> Can you explain this? What are the exploits? Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). This works really well for old apps (and admittedly not too bad for new ones) but is very slow and exposes a lot of bugs. On top of this, you have potential exploits in your filesystem from loosely permissioning important settings and identity files. So, the attack surface for a traditional Linux distro is relatively large. > Is it the equivalent of running a .exe or .jar on windows, but with an extra layer of protection? Kinda! Linux software is distributed as packages, which contains a binary (the exe/jar portion), a dependency manifest and whatever static content it needs. A sandbox like Flatpak will take those packages and put it into a sandbox, to prevent hostile interprocess communication and filesystem exploits. None of these mitigations are perfect per-se (nor are they on Mac/Windows), so use them wisely if you intend to use them at all. I have used a non-sandboxed system to run old 90s Windows games for years though, and haven't picked up any significant issues. YMMV, it is Linux after all :P

hospitalJail 3y ago
>Traditional desktop Linux allows different apps to more-or-less freely communicate with each other (called the x11 protocol). Oh gosh. I'm getting heart palpitations :P Is this a common attack vector then? Seems like an easy way to get an overflow error, or elevate privilege's.
- bombolo 3y ago
  Not common at all. Because most software comes from distributions, not from warez.exe. Sandbox comes with a heavy usability price, so they are lax by default. For example you protect your files, but then you can't load your photos to facebook because your browser doesn't have access.
- t0astbread 3y ago
  There's also a newer protocol called "Wayland" which aims to avoid some issues with X11 (and is also a general architecture overhaul). GNOME and KDE support it out of the box and iirc at least GNOME also enables it by default. There are some tradeoffs though. Some things like screen sharing might be worse on Wayland (e.g. I can't share a single window, only whole screens) and some apps don't support Wayland at all (including for example all of the IntelliJ IDEs). The latter can be circumvented by enabling XWayland (basically an X server running side by side with the Wayland compositor to handle X11-only apps). In that case you're left with the X11 security model for apps not running natively on Wayland.
  - JohnFen 3y ago
    And Wayland doesn't support being able to have multiple logons, each with their own independent desktop, simultaneously like X does. I just like to bring that up even though it's not a common use case, because that's what keeps me from using Wayland.
    - t0astbread 3y ago
      Interesting. Do you know why? I've only ever tried launching nested instances of Sway (the compositor I use) which each use their own sockets and render as a client to the parent compositor and that worked fine. Does it have something to do with rendering to a real display?
      - JohnFen 3y ago
        I remember this being brought up early in Wayland development. The stance was taken that it wasn't a popular enough use case to be worth putting work into. I don't think there's any real technical reason why it couldn't be done, but I don't know. I'm not familiar with the architecture of Wayland.
        bandrami 3y ago
        I think seatd allows this now? So it works on the rather small sliver of distros that don't run systemd.
- bandrami 3y ago
  "more-or-less" is doing a lot of work there. It uses a cookie-based authentication system (in fact I think that's where web browsers got the word "cookie" from) but it was intended for trusted networks; when it's done in other situations it's via kerberos or over an SSH tunnel. It's a pretty elegant setup, honestly, and one thing I miss when I'm on Wayland. The idea is you're at a small desktop on your University's network and you need to use some of the computing power of the big data servers they have. So you run e.g. a graphing program that does all of its computation on the big data machine but does its display on your little desktop (in this setup the big data machine is called the "client" and the tiny little desktop is called the "server" which confuses people a lot at first but makes sense when you get into the architecture). X itself had been moving away from this for years by adding some extensions that don't work well (or at all) over the network, but there are absolutely still lab setups that use the old way because it's pretty much tailor-made for it. The bigger security issue was that X programs could see and modify certain things about each other and about the system as a whole, so for example the program XEyes had a pair of eyes that pointed at the location of the cursor (it sounds silly but this was an accessibility thing). And a screenshot program could take a shot of the screen. And so on. Wayland got rid of all those capabilities, but there turned out to be a lot of baby in that bathwater so they're slowly adding back each of them, one at a time. In another decade a new crop of developers will no doubt say "What's all this needless cruft?! Let's start over!" and the cycle of life will continue.
anthk 3y ago
(U)XTerm can lock input to a terminal so snooping it it's impossible.
- ElectricalUnion 3y ago
  That doesn't help when a bunch of disparate credentials are entered and cached in a shared runtime environment inside the same bunch of processes (aka: your browser). Obligatory XKCD: https://xkcd.com/1200/ https://xkcd.com/1200/
  - anthk 3y ago
    You have pledge and unveil under OpenBSD. Or, if you are truly paranoid... just create another Unix user for sensible web browsing and log in with that account: useradd -m webcare passwd webcare Done.