4 ms·

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exceptio

by krick 6y ago

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such. So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).

syockit 6y ago
I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?
- my123 6y ago
  For Windows, there are the Win32 apps that you talk about, which aren't sandboxed. And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.
  - pjmlp 6y ago
    Win32 applications can also be sandboxed, when packaged as MSIX. Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.
- pdimitar 6y ago
  People have praised Qubes OS for its security in the past but I've never tried it.
  - GekkePrutser 6y ago
    I have. It's very secure but too much towards security on the security Vs usability scale for my liking. I use it for specific purposes like possibly hostile browsing environments but I'd never consider it for a mainstream system to work on.
- GordonS 6y ago
  In some ways, things are better there on Windows here, because of code signing - if something isn't code-signed, you get a more prominent warning. I often wish for something like this on Linux (and it would have to be easy to use - no compiling your own kernel with additional modules for example). It's really not easy to get a code signing certificate fraudulently (or to steal someone else's), but of course, there are some issues with code signing: for example, certificates are relatively expensive, so very few OSS/free software projects sign binaries.
- Koliakis 6y ago
  I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes. I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like banking is done in its own VM. Every proprietary application gets its own VM (mainly Teamviewer and VS Code). So if I do happen to run some program that's malicious, it has effectively zero access to anything sensitive unless it's aware of Qubes and knows how to break out of the hypervisor (non-trivial).
  - sdwvit 6y ago
    How slow is it?
  - __turbobrew__ 6y ago
    How is this different than running FreeBSD with a jail per application?
    - Koliakis 6y ago
      Harder boundaries? From what I understand, a hypervisor is much harder to break out of than a FreeBSD jail and provides more isolation between the VMs.
oxylibrium 6y ago
I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway. It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem. macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff. Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem: - App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm. I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs. [0]: https://flatpak.org/ https://flatpak.org/
- tsimionescu 6y ago
  > It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem. This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc. Of course, if we're talking about installers and not random .exe's, where users are already conditioned to allow installers to run as Administrator, the problem re-surfaces. A bit closer to editing .bashrc in Windows is the peculiarity that Windows DLL search order normally starts from the directory where the .exe was loaded from. So, any .exe in a User-writable location that loads a DLL can be tricked into running malware by creating/overwriting a malicious DLL of the same name there (this doesn't work for Windows DLLs, though).
cheph 6y ago
> Linux starts falling behind both MacOS and Windows in this regard Last I installed something with windows it had full write access to my home directory and pretty much everything the user it was running as had access to. Is this no longer the case?

by krick 6y ago

syockit 6y ago

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

my123 6y ago
For Windows, there are the Win32 apps that you talk about, which aren't sandboxed. And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.
- pjmlp 6y ago
  Win32 applications can also be sandboxed, when packaged as MSIX. Windows 10X original roadmap was to merge both sandbox models, and it is also part of Project Reunion goals.
pdimitar 6y ago
People have praised Qubes OS for its security in the past but I've never tried it.
- GekkePrutser 6y ago
  I have. It's very secure but too much towards security on the security Vs usability scale for my liking. I use it for specific purposes like possibly hostile browsing environments but I'd never consider it for a mainstream system to work on.
GordonS 6y ago
In some ways, things are better there on Windows here, because of code signing - if something isn't code-signed, you get a more prominent warning. I often wish for something like this on Linux (and it would have to be easy to use - no compiling your own kernel with additional modules for example). It's really not easy to get a code signing certificate fraudulently (or to steal someone else's), but of course, there are some issues with code signing: for example, certificates are relatively expensive, so very few OSS/free software projects sign binaries.
Koliakis 6y ago
I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes. I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like banking is done in its own VM. Every proprietary application gets its own VM (mainly Teamviewer and VS Code). So if I do happen to run some program that's malicious, it has effectively zero access to anything sensitive unless it's aware of Qubes and knows how to break out of the hypervisor (non-trivial).
- sdwvit 6y ago
  How slow is it?
- __turbobrew__ 6y ago
  How is this different than running FreeBSD with a jail per application?
  - Koliakis 6y ago
    Harder boundaries? From what I understand, a hypervisor is much harder to break out of than a FreeBSD jail and provides more isolation between the VMs.

oxylibrium 6y ago

I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway. It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem. macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff. Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem: - App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm. I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs. [0]: https://flatpak.org/ https://flatpak.org/

tsimionescu 6y ago
> It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem. This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc. Of course, if we're talking about installers and not random .exe's, where users are already conditioned to allow installers to run as Administrator, the problem re-surfaces. A bit closer to editing .bashrc in Windows is the peculiarity that Windows DLL search order normally starts from the directory where the .exe was loaded from. So, any .exe in a User-writable location that loads a DLL can be tricked into running malware by creating/overwriting a malicious DLL of the same name there (this doesn't work for Windows DLLs, though).

cheph 6y ago

> Linux starts falling behind both MacOS and Windows in this regard Last I installed something with windows it had full write access to my home directory and pretty much everything the user it was running as had access to. Is this no longer the case?