5 ms·

"read scripts before you run them" is a good bit of advice. Some little things can help you protect your GUI apps if you're extra paranoid (eg. Wayland is more

"read scripts before you run them" is a good bit of advice. Some little things can help you protect your GUI apps if you're extra paranoid (eg. Wayland is more secure, Flatpak offers additional sandboxing with bubblewrap) but not everything is necessary. If you use a mainstream distro like Fedora or Ubuntu, its default configuration should be safe enough to use like Windows. Just remember that there isn't really any antivirus or Microsoft Defender to save you if you really mess up. I do offline backups of important work on all my devices, for this reason partially.

hospitalJail 3y ago
>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?
TacticalCoder 3y ago
> "read scripts before you run them" is a good bit of advice. I always read the script and do also verify they're only using ASCII chars (and if they're not, I check which Unicode shenanigan is ongoing). For example: ... $ file /usr/local/bin/somescript.sh /usr/local/bin/somescript.sh: Bourne-Again shell script, ASCII text executable FWIW most of the scripts out there are only ever using ASCII chars.
- chaxor 3y ago
  How do you check it without running something that may execute it? Many scripts will execute if opened with vi or even cat or printf from what I understand.
  - cyberbanjo 3y ago
    Source for executing files with cat? That certainly defies my understand of how cat works.
    - RadiozRadioz 3y ago
      Maybe they mean that it can include control characters that mess up your terminal and make it look like something malicious is happening, which of course is not the same as executing it (and has a warning anyway).
  - JohnFen 3y ago
    > Many scripts will execute if opened with vi I haven't encountered this. You can execute scripts intentionally in vi, and I assume you could configure it to happen automatically, but can this happen without you making some sort of effort to enable it? What scripts present such a risk? What vi configuration is required to stop this? Same question wrt cat.
  - deadbunny 3y ago
    (n)vi(m), cat, less/more do not execute scripts on read. That would be utterly insane.
  - deleted 3y ago

hospitalJail 3y ago

>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?

TacticalCoder 3y ago

> "read scripts before you run them" is a good bit of advice. I always read the script and do also verify they're only using ASCII chars (and if they're not, I check which Unicode shenanigan is ongoing). For example: ... $ file /usr/local/bin/somescript.sh /usr/local/bin/somescript.sh: Bourne-Again shell script, ASCII text executable FWIW most of the scripts out there are only ever using ASCII chars.

chaxor 3y ago
How do you check it without running something that may execute it? Many scripts will execute if opened with vi or even cat or printf from what I understand.
- cyberbanjo 3y ago
  Source for executing files with cat? That certainly defies my understand of how cat works.
  - RadiozRadioz 3y ago
    Maybe they mean that it can include control characters that mess up your terminal and make it look like something malicious is happening, which of course is not the same as executing it (and has a warning anyway).
- JohnFen 3y ago
  > Many scripts will execute if opened with vi I haven't encountered this. You can execute scripts intentionally in vi, and I assume you could configure it to happen automatically, but can this happen without you making some sort of effort to enable it? What scripts present such a risk? What vi configuration is required to stop this? Same question wrt cat.
- deadbunny 3y ago
  (n)vi(m), cat, less/more do not execute scripts on read. That would be utterly insane.
- deleted 3y ago