4 ms·

Firejail and apparmor have existed for years. If you don't use them maybe it's your fault? Also the very same npm backdoors have already hit android apps. What

by guappa 1y ago

Firejail and apparmor have existed for years. If you don't use them maybe it's your fault? Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app?

aragilar 1y ago
Or go old-school with multiple users and chroots? You could even install from (and host) a trusted repository, where the source and binaries are vetted (and you can pay people to do this for you).
- xorcist 1y ago
  Server software is usually compartmentalized in uid:s but desktop software seldom is, if ever. Package managers and maintainers could do a lot here to make it easier. Some things long time Linux users like to do, like running Firefox as a separate user, is still a much more involved process than it should be. A lot of it is probably standards and culture work, like where a user can expect to store files and have them readable by Firefox in this example. So perhaps this is something the GNOME/Freedesktop people could have been interested in and made a difference? Instead we have things like Flatpak, which is good but not the lowest hanging fruit here.
  - aragilar 1y ago
    For user-facing stuff, I agree it's hard because of the challenge of managing access to data (and I would argue no system does this well, Android has a different set of failure modes, and I've not used QubesOS but presumably it has it's own issues as well), but in the top-level comment, the concern was around using pip/npm, which to me is almost a solved problem if you care enough and are willing to put the effort (and money) in. It's also not like Linux is any different with respect to installing random PyPI/npm packages on any other desktop/laptop OS (https://xkcd.com/1200/ https://xkcd.com/1200/), so I'm not sure anything desktop Linux does here would change the fact that installing random software from the internet may be a bad idea sometimes ;)
    - taeric 1y ago
      Completely agreed on this. Linux, by and large, should actually be far easier here? Have a "work account" for your machine where you do these tasks and you are basically there. Switching to a gaming account or your banking/etc. seems easy enough?
  - guappa 1y ago
    You're going to deal with the users who can't attach a file to an email because the firefox process has no access to it?
    - taeric 1y ago
      To be fair, if firefox had the intelligence to know that it was being asked to attach a file it didn't have access to, it could prompt for a password. I don't expect full TRAMP like smarts from Emacs, but I don't see why this wouldn't be doable? Granted, I'm viewing this as far easier than the sandbox "fake file system" approach? Firefox would be able to see the file exists, most likely, but just not have read rights to it. Yes, you can have some things it can't list, but I would expect that to be low on probability to want to attach to an email?
    - yencabulator 1y ago
      The Flatpak/XDG people are standardizing the concept of "portal"s for doing things that need help from outside the sandbox. A properly sandboxed Flatpak app can only open files bind-mounted for it via a portal call.
    - xorcist 1y ago
      That's exactly my point. Users expect desktop software to read their home directory, which is an artefact of running under the same uid. The same can not be said for server software, where the expectation is different. Linux desktop environments had the chance to set a precedent here where software could for example have had a directory named after the application under the user's home, and use subuid to access files. That is simply an example, but would be a backwards compatible way to create a shared culture how Linux desktop software operate, and easen a transition where desktop software could be limited to "their" own directory. Instead they squandered this chance by focusing all effort on moving dotfiles around (.config was such a waste of energy where we the heated debate could have been about something more useful, such as the above). Now we have Snap and Flatpak which both try to solve a culture problem (where we store our files) with technical solutions (bind mounts! modal gui:s! popup dialogs!). These will not improve the situation. In the best case it will train users to click "Yes" more, which we know not to help security.
tholdem 1y ago
Sandboxing should be built in and by default, not DIY and glued on, like with apparmor and firejail. "Your car does not come with a seatbelt? Seatbelt parts are easy to order online and assembled on any car, it's your fault for not using one." > Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app? The whole point of sandboxing is that one compromised app can not compromise the whole system and other apps. Compromised dependency on my banking app on Android or iOS only compromises that banking app and nothing else.
- dustbunny 1y ago
  Fedora Silverblue is this
  - tholdem 1y ago
    It may be in the future, but for now it is no different from Fedora Workstation in terms of security. Please correct me if I am wrong. AFAIK Silverblue has no additional sandboxing or any other improvements to security.
    - JCattheATM 1y ago
      Pretty sure Fedora, being based on Red Hat, has the strongest SELinux policy in place by default, and SELinux is pretty much the best sandboxing option available other than actual virtualization.
      - tholdem 1y ago
        Yes, but this was about Silverblue and how it implements some additional sandboxing, which it doesn't. SELinux is great, but maintaining it and creating configs is huge amount of work and where on AOSP, every process is strictly confined with SELinux, on Fedora, not so much. Not to mention the additional software the user installs. Not at all comparable to real Android or iOS sandboxing.

by guappa 1y ago

aragilar 1y ago

Or go old-school with multiple users and chroots? You could even install from (and host) a trusted repository, where the source and binaries are vetted (and you can pay people to do this for you).

xorcist 1y ago
Server software is usually compartmentalized in uid:s but desktop software seldom is, if ever. Package managers and maintainers could do a lot here to make it easier. Some things long time Linux users like to do, like running Firefox as a separate user, is still a much more involved process than it should be. A lot of it is probably standards and culture work, like where a user can expect to store files and have them readable by Firefox in this example. So perhaps this is something the GNOME/Freedesktop people could have been interested in and made a difference? Instead we have things like Flatpak, which is good but not the lowest hanging fruit here.
- aragilar 1y ago
  For user-facing stuff, I agree it's hard because of the challenge of managing access to data (and I would argue no system does this well, Android has a different set of failure modes, and I've not used QubesOS but presumably it has it's own issues as well), but in the top-level comment, the concern was around using pip/npm, which to me is almost a solved problem if you care enough and are willing to put the effort (and money) in. It's also not like Linux is any different with respect to installing random PyPI/npm packages on any other desktop/laptop OS (https://xkcd.com/1200/ https://xkcd.com/1200/), so I'm not sure anything desktop Linux does here would change the fact that installing random software from the internet may be a bad idea sometimes ;)
  - taeric 1y ago
    Completely agreed on this. Linux, by and large, should actually be far easier here? Have a "work account" for your machine where you do these tasks and you are basically there. Switching to a gaming account or your banking/etc. seems easy enough?
- guappa 1y ago
  You're going to deal with the users who can't attach a file to an email because the firefox process has no access to it?
  - taeric 1y ago
    To be fair, if firefox had the intelligence to know that it was being asked to attach a file it didn't have access to, it could prompt for a password. I don't expect full TRAMP like smarts from Emacs, but I don't see why this wouldn't be doable? Granted, I'm viewing this as far easier than the sandbox "fake file system" approach? Firefox would be able to see the file exists, most likely, but just not have read rights to it. Yes, you can have some things it can't list, but I would expect that to be low on probability to want to attach to an email?
  - yencabulator 1y ago
    The Flatpak/XDG people are standardizing the concept of "portal"s for doing things that need help from outside the sandbox. A properly sandboxed Flatpak app can only open files bind-mounted for it via a portal call.
  - xorcist 1y ago
    That's exactly my point. Users expect desktop software to read their home directory, which is an artefact of running under the same uid. The same can not be said for server software, where the expectation is different. Linux desktop environments had the chance to set a precedent here where software could for example have had a directory named after the application under the user's home, and use subuid to access files. That is simply an example, but would be a backwards compatible way to create a shared culture how Linux desktop software operate, and easen a transition where desktop software could be limited to "their" own directory. Instead they squandered this chance by focusing all effort on moving dotfiles around (.config was such a waste of energy where we the heated debate could have been about something more useful, such as the above). Now we have Snap and Flatpak which both try to solve a culture problem (where we store our files) with technical solutions (bind mounts! modal gui:s! popup dialogs!). These will not improve the situation. In the best case it will train users to click "Yes" more, which we know not to help security.

tholdem 1y ago

Sandboxing should be built in and by default, not DIY and glued on, like with apparmor and firejail. "Your car does not come with a seatbelt? Seatbelt parts are easy to order online and assembled on any car, it's your fault for not using one." > Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app? The whole point of sandboxing is that one compromised app can not compromise the whole system and other apps. Compromised dependency on my banking app on Android or iOS only compromises that banking app and nothing else.

dustbunny 1y ago
Fedora Silverblue is this
- tholdem 1y ago
  It may be in the future, but for now it is no different from Fedora Workstation in terms of security. Please correct me if I am wrong. AFAIK Silverblue has no additional sandboxing or any other improvements to security.
  - JCattheATM 1y ago
    Pretty sure Fedora, being based on Red Hat, has the strongest SELinux policy in place by default, and SELinux is pretty much the best sandboxing option available other than actual virtualization.
    - tholdem 1y ago
      Yes, but this was about Silverblue and how it implements some additional sandboxing, which it doesn't. SELinux is great, but maintaining it and creating configs is huge amount of work and where on AOSP, every process is strictly confined with SELinux, on Fedora, not so much. Not to mention the additional software the user installs. Not at all comparable to real Android or iOS sandboxing.