6 ms·

> your package manager that uses TLS would be vulnerable most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues

by sp1rit 3y ago

> your package manager that uses TLS would be vulnerable most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues (but they could obviously still have some sort of other backdoor for gpg). Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.

consumer451 3y ago
This seems like an extremely important point, which applies not just to desktop Linux (my OP,) but especially server Linux. Since I am very much a Linux & infosec muggle, please indulge me with these possibly dumb questions: What are the mitigations for the lack of provenance in pip/npm? Does properly configured SELinux do enough? Or is the fact that many of these packages use 80/443 negate that? Or is the fact that a pip/npm package could be comprised after install, during update the main problem? I always think of that left-pad NPM drama, could that single dev have comprised thousands of systems by changing his update to something much more nefarious, instead of just deleting the package? Again, sorry if these are dumb questions.
- sp1rit 3y ago
  Well, it depends on what you consider "properly configured". But I'd say most systems used by developers aren't secured against these attacks. This mostly boils down to (like discussed elsewhere in this thread) that the developer runs his tools as his user, thus malicious software can modify his .bashrc and using that hijack a later sudo invocation to gain full access. The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.
  - consumer451 3y ago
    Oooof. Thanks. So let’s all pretend that everything is gonna be fine then I guess? Say it was Ubuntu Desktop… would installing the supported EPP, ClamAV help in some regard? It would, right? Should this be a Tell HN type thing? Maybe ClamAV being installed by default, like UFW, is the real (partial) solution?
    - sp1rit 3y ago
      I don't know what EPP provides (I doubt it'll help you in this case), but AFAIK least ClamAV only matches against known signatures (almost exclusively windows malware), so it can't detect newly created malware. To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access). The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).

by sp1rit 3y ago

consumer451 3y ago

This seems like an extremely important point, which applies not just to desktop Linux (my OP,) but especially server Linux. Since I am very much a Linux & infosec muggle, please indulge me with these possibly dumb questions: What are the mitigations for the lack of provenance in pip/npm? Does properly configured SELinux do enough? Or is the fact that many of these packages use 80/443 negate that? Or is the fact that a pip/npm package could be comprised after install, during update the main problem? I always think of that left-pad NPM drama, could that single dev have comprised thousands of systems by changing his update to something much more nefarious, instead of just deleting the package? Again, sorry if these are dumb questions.

sp1rit 3y ago
Well, it depends on what you consider "properly configured". But I'd say most systems used by developers aren't secured against these attacks. This mostly boils down to (like discussed elsewhere in this thread) that the developer runs his tools as his user, thus malicious software can modify his .bashrc and using that hijack a later sudo invocation to gain full access. The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.
- consumer451 3y ago
  Oooof. Thanks. So let’s all pretend that everything is gonna be fine then I guess? Say it was Ubuntu Desktop… would installing the supported EPP, ClamAV help in some regard? It would, right? Should this be a Tell HN type thing? Maybe ClamAV being installed by default, like UFW, is the real (partial) solution?
  - sp1rit 3y ago
    I don't know what EPP provides (I doubt it'll help you in this case), but AFAIK least ClamAV only matches against known signatures (almost exclusively windows malware), so it can't detect newly created malware. To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access). The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).