4 ms·

One of the reasons why this happens is because Linux uses outdated security model. Linux protects one user's data from other user, but doesn't protect user's da

One of the reasons why this happens is because Linux uses outdated security model. Linux protects one user's data from other user, but doesn't protect user's data from programs run by the user. This means that for example, third-party software like VSCode or Dropbox has permission to read your browser's cookies, history and saved passwords. Or it can debug your browser and read its memory. Linux's security model would work well on multi-user mainframes in 80s but doesn't make much sense for an Internet-connected computer with a single user. The threats now are completely different. For comparison, iOS and Android's security model would not allow a Python package to steal SSH keys. But the best solution would be to implement least privileges principle and do not grant unnecessary privileges to programs. Another solution which could protect from such attacks would be to hire someone to inspect the packages. But it seems thatnobody is providing such services. Is it because people got used to everything being free?

fswd 4y ago
running all apps in something like a lite version of docker in user namespace mode would implement this
- microtonal 4y ago
  Such solutions exist already, see e.g. bubblewrap [1]. The Flatpak ecosystem is slowly trying to add protection by sandboxing applications using bubblewrap. However a contingent of the Linux community meets this with: - Flatpak is terrible because it doesn't follow a file system hierarchy that was invented in the 70ies. - Flatpak is terrible because my early 90ies package manager is the pinnacle of packaging. - Flatpak is terrible because I only trust my distribution's packages. - Flatpak is a security nightmare because it doesn't isolate every application now. (Which is not really possible, because applications/toolkits need to be adapted). - Flatpak is terrible because now my applications cannot open arbitrary files anymore (including ~/.ssh). Conservatism is what holds the Linux ecosystem back. We have seen this story before with systemd. This is sad, because Red Hat and others are doing fantastic work modernizing Linux (see Flatpak, Fedora Silverblue, etc.). [1] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
- npteljes 4y ago
  Qubes OS does it exactly like that: https://en.wikipedia.org/wiki/Qubes_OS https://en.wikipedia.org/wiki/Qubes_OS
shanipribadi 4y ago
For comparison, iOS and Android's security model would not allow a Python package to steal SSH keys. But the best solution would be to implement least privileges principle and do not grant unnecessary privileges to programs. I think even in iOS and Android, the same thing could still happen if the user keep secrets (say private keys) in their file directories, and then the user give permission to the app to access their file directories, which could be legitimate need of common applications like file manager, text editors, etc. I think the main change to solve this would be to not keep secrets in files that are readable by users (or program run by users) implicitly, instead using a secret provider that makes it explicit to the user whenever an application needs to access such secrets.
mkipper 4y ago
This might be a bit pedantic, but “Linux” in the general sense doesn’t use the outdated security model you described. You’re basically comparing discretionary access control (e.g. user/group permissions) with mandatory access control (e.g. SELinux), both of which Linux happily supports… …but the usage of MAC in Linux is so awkward that it might as well not exist, since the majority of distributions, packages and users ignore it completely to avoid all the headaches that come with it. It’s tricky. It would be nice if the maintainers of big distributions/packages took MAC seriously and defaulted to restrictive SELinux policies or whatever, but history has shown this to be _very_ brittle and annoying for users. That’s why you see this stuff enabled in iOS and Android but not general Linux distributions — it’s much easier to lock things down with MAC when you’re developing a singular OS from scratch with apps that run in a sandboxed environment that’s isolated from the “system”. But if you’re maintaining something like python or pip, it’s basically impossible to do that.
jacquesm 4y ago
This is a Python problem first, long before it is a Linux problem. Not every ecosystem suffers from these issues. But both Node and Python have such instances of namespace issues and package confusion with alarming regularity.
- rich_sasha 4y ago
  Is that so? It would seem like any packaging solution that pulls dependencies from GitHub is vulnerable. This is the case for Rust, it seems. Or any GitHub-based project that pulls recursively submodules. Unless you have a curated, audited package repository, i can't see how you easily avoid it. Hence it is reasonable to ask how the OS can help.
  - jacquesm 4y ago
    The OS can't help as long as users can create files. But eco-systems (whether Rust, Go, Node or Python doesn't really matter) can help by managing their name spaces properly. The thing that went wrong here is that someone can silently replace a package in a namespace that you think is unique by overruling it through a namespace that takes precedence. Besides the obvious usability issues (this is not the kind of functionality that you would want in any circumstances) if a package suddenly gets pulled from an entirely different repository compared to where the previous instance came from and does so silently (without throwing an error and without so much as a pause to ask the user whether this really is what they want) then I really don't see what kind of OS level awareness of the world at large would be required to fix that. The problem does not stem from the operating system level, and so it should not be fixed there, and it likely can't be fixed there, at least not without possibly breaking a whole bunch of stuff that is working just fine today.
    - rich_sasha 4y ago
      I agree the issue is not caused by OS; rather my point is, OS is a convenient layer to prevent it. You mention some mechanisms for preventing these issues at packaging level. But so long as bad actors can sneak malicious commits, it's an open problem. Here a whole package was replaced, in another scenario a single line of malicious code can be sneaked in, released, rubber stamped and shipped via bona fide channels. Ensuring no single bad commit is made in any package or its dependency doesn't seem like a realistic task. As other posters suggest, this could be somewhat mitigated by mobile-style finer-grained permissions, even if the problem doesn't stem from an OS failure per se.

fswd 4y ago

running all apps in something like a lite version of docker in user namespace mode would implement this

microtonal 4y ago
Such solutions exist already, see e.g. bubblewrap [1]. The Flatpak ecosystem is slowly trying to add protection by sandboxing applications using bubblewrap. However a contingent of the Linux community meets this with: - Flatpak is terrible because it doesn't follow a file system hierarchy that was invented in the 70ies. - Flatpak is terrible because my early 90ies package manager is the pinnacle of packaging. - Flatpak is terrible because I only trust my distribution's packages. - Flatpak is a security nightmare because it doesn't isolate every application now. (Which is not really possible, because applications/toolkits need to be adapted). - Flatpak is terrible because now my applications cannot open arbitrary files anymore (including ~/.ssh). Conservatism is what holds the Linux ecosystem back. We have seen this story before with systemd. This is sad, because Red Hat and others are doing fantastic work modernizing Linux (see Flatpak, Fedora Silverblue, etc.). [1] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap
npteljes 4y ago
Qubes OS does it exactly like that: https://en.wikipedia.org/wiki/Qubes_OS https://en.wikipedia.org/wiki/Qubes_OS

shanipribadi 4y ago

For comparison, iOS and Android's security model would not allow a Python package to steal SSH keys. But the best solution would be to implement least privileges principle and do not grant unnecessary privileges to programs. I think even in iOS and Android, the same thing could still happen if the user keep secrets (say private keys) in their file directories, and then the user give permission to the app to access their file directories, which could be legitimate need of common applications like file manager, text editors, etc. I think the main change to solve this would be to not keep secrets in files that are readable by users (or program run by users) implicitly, instead using a secret provider that makes it explicit to the user whenever an application needs to access such secrets.

mkipper 4y ago

This might be a bit pedantic, but “Linux” in the general sense doesn’t use the outdated security model you described. You’re basically comparing discretionary access control (e.g. user/group permissions) with mandatory access control (e.g. SELinux), both of which Linux happily supports… …but the usage of MAC in Linux is so awkward that it might as well not exist, since the majority of distributions, packages and users ignore it completely to avoid all the headaches that come with it. It’s tricky. It would be nice if the maintainers of big distributions/packages took MAC seriously and defaulted to restrictive SELinux policies or whatever, but history has shown this to be _very_ brittle and annoying for users. That’s why you see this stuff enabled in iOS and Android but not general Linux distributions — it’s much easier to lock things down with MAC when you’re developing a singular OS from scratch with apps that run in a sandboxed environment that’s isolated from the “system”. But if you’re maintaining something like python or pip, it’s basically impossible to do that.

jacquesm 4y ago

This is a Python problem first, long before it is a Linux problem. Not every ecosystem suffers from these issues. But both Node and Python have such instances of namespace issues and package confusion with alarming regularity.

rich_sasha 4y ago
Is that so? It would seem like any packaging solution that pulls dependencies from GitHub is vulnerable. This is the case for Rust, it seems. Or any GitHub-based project that pulls recursively submodules. Unless you have a curated, audited package repository, i can't see how you easily avoid it. Hence it is reasonable to ask how the OS can help.
- jacquesm 4y ago
  The OS can't help as long as users can create files. But eco-systems (whether Rust, Go, Node or Python doesn't really matter) can help by managing their name spaces properly. The thing that went wrong here is that someone can silently replace a package in a namespace that you think is unique by overruling it through a namespace that takes precedence. Besides the obvious usability issues (this is not the kind of functionality that you would want in any circumstances) if a package suddenly gets pulled from an entirely different repository compared to where the previous instance came from and does so silently (without throwing an error and without so much as a pause to ask the user whether this really is what they want) then I really don't see what kind of OS level awareness of the world at large would be required to fix that. The problem does not stem from the operating system level, and so it should not be fixed there, and it likely can't be fixed there, at least not without possibly breaking a whole bunch of stuff that is working just fine today.
  - rich_sasha 4y ago
    I agree the issue is not caused by OS; rather my point is, OS is a convenient layer to prevent it. You mention some mechanisms for preventing these issues at packaging level. But so long as bad actors can sneak malicious commits, it's an open problem. Here a whole package was replaced, in another scenario a single line of malicious code can be sneaked in, released, rubber stamped and shipped via bona fide channels. Ensuring no single bad commit is made in any package or its dependency doesn't seem like a realistic task. As other posters suggest, this could be somewhat mitigated by mobile-style finer-grained permissions, even if the problem doesn't stem from an OS failure per se.