7 ms·

I want to mitigate risks like this. Is there a way to limit access to certain directories only while using certain software?

warmwaffles 5y ago
Yes, don't give your main account admin sudo access without a password. Keep backups on an external file store just in case. Use a filesystem that has snapshot capabilities.
- Gigachad 5y ago
  What is the point of that. Sudo doesn't give access to anything important. Very much reminds me of this https://xkcd.com/1200/ https://xkcd.com/1200/ Snapshots on an external system is useful but few are disciplined enough to take regular enough snapshots.
  - randomhodler84 5y ago
    It kinda does… root can write to places that the user cannot. Like Boot partitions, or entire device nodes, or load kernel modules that the user cannot see. That xkcd is a funny historical joke, but the root/user distinction is still a critical part of operating system security today.
    - derkades 5y ago
      But it is true. Who cares if the program can write to your system configuration when it can encrypt your entire home directory and use your private SSH keys to encrypt all your servers as well. I'd argue the root/normal user separation is largely useless on single user desktop computers.
      - randomhodler84 5y ago
        Presumably only the homedirs of the servers. You want a world where a browser exploit can drop a bootkit? Nahhh
        Gigachad 5y ago
        They could just drop something in bashrc or somewhere else for a persistent exploit. The system files contain nothing worth touching on a personal device.
        randomhodler84 5y ago
        Persistent userspace. And while I understand privesc in major platforms is not the insurmountable problem it seems, it is still a layer of protection important to the model of preventing SMM, hypervisor efi boot and root level persistence, without something else up its sleeves.
schemescape 5y ago
I switched from Node to Deno partly for exactly this functionality. But you’re probably looking for something more general, like containers, virtual machines, or other sandboxes (chroot?).
- cersa8 5y ago
  I don't think fetching arbitrary code over url's is somehow better than npm.
  - machiaweliczny 5y ago
    Deno has module hashing and sanboxes OS access AFAIK
raffraffraff 5y ago
Run it in a container. Don't let the container run as root - create an account which has the same ID as a dummy account on your host system. If you have to volume mount, be very explicit about what paths you mount and use the read only flag if it makes sense. If you can't mount read only because you need to write to certain files, then grant the container account access to those files using ACLs (eg: on Linux user 'chmod' or 'setfacl').
- lmarcos 5y ago
  Running it as user nobody within the container should be enough, no?
  - raffraffraff 5y ago
    That should do it, as long as both host and container systems implement the nobody user on the same ID. Which is likely. But I'd check all the same
gwmnxnp_516a 5y ago
This node npm supply chain attack incident is a wake up call that the current security model of mainstream operating systems such as Linux, MacOSX or Windows are no longer suitable for modern day threats and they need a "zero-trust" like model for applications. Mitigating supply chain attacks like this one requires adopting application sandboxing by default, assuming that any application can be compromised, and capability-based security model like Fuchsia, Genode OS or mobile operating systems like Android or Apple's IOS. In the case of Linux, the most suitable sandboxes are docker container and Firejail tool that can restrict operating system resources which an application can access, including the $HOME directory. Firejail can even provide a fake $HOME directory. In the case of Microsoft windows, there is the Windows Sandbox, but it is only available on Windows pro or enterprise. But even so those countermeasures would only prevent the user data from being damaged, malicious NPM packages could still attempt to send credentials, tokens or database information back to the attacker. More details at: https://hkubota.wordpress.com/2020/12/31/comparing-sandboxing-tools/ https://hkubota.wordpress.com/2020/12/31/comparing-sandboxin... and https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview https://docs.microsoft.com/en-us/windows/security/threat-pro.... Another suitable mitigation strategy may be lock dependencies version or switch to other programming languages with a proper standard library and limited number of packages where one can at least audit the code.
properparity 5y ago
I guess people have forgotten the lessons of 90s Windows: Don't download and run random .exe from the internet, assume they are hostile until proven otherwise. Don't download, install and run random code libraries from the internet, assume they are hostile until proven otherwise.
- jbjohns 5y ago
  I don't think that's really fair. Unity 3d and Vue.js are not random.exe.
  - samhw 5y ago
    I think their point might have been that Unity forgot that lesson. And everyone else, transitively, along the chain. As horrible and impracticable as it sounds, the only way to prevent this happening is to read the source of every (/transitive) dependency you install. Yes, we can trust people, and yes, we can blame them when they betray our trust - we can even prosecute them - but as this shows, that's not always going to stop people. And it's certainly not going to stop attackers who gain control of those dependencies. This is something we really need to think about as a profession. I would favour a system where dependencies are restricted to pure computation only (no syscalls) and any greater permissions must be granted explicitly. But that's extremely onerous, and likely - for many devs - to lead to a 'just click yes' mentality; even besides that, there are doubtless many cases it won't prevent. All I'm sure of is that we can't continue like this.
z3t4 5y ago
yarn install --flat git add node_modules Then the next time you run yarn upgrade: yarn upgrade --flat git diff Carefully read through what changed in each of the packages. git add node_packages git commit -m "yarn upgrade" You will see a lot of bad code, but also learn stuff. But most importantly - your project will be secure.

warmwaffles 5y ago

Yes, don't give your main account admin sudo access without a password. Keep backups on an external file store just in case. Use a filesystem that has snapshot capabilities.

Gigachad 5y ago
What is the point of that. Sudo doesn't give access to anything important. Very much reminds me of this https://xkcd.com/1200/ https://xkcd.com/1200/ Snapshots on an external system is useful but few are disciplined enough to take regular enough snapshots.
- randomhodler84 5y ago
  It kinda does… root can write to places that the user cannot. Like Boot partitions, or entire device nodes, or load kernel modules that the user cannot see. That xkcd is a funny historical joke, but the root/user distinction is still a critical part of operating system security today.
  - derkades 5y ago
    But it is true. Who cares if the program can write to your system configuration when it can encrypt your entire home directory and use your private SSH keys to encrypt all your servers as well. I'd argue the root/normal user separation is largely useless on single user desktop computers.
    - randomhodler84 5y ago
      Presumably only the homedirs of the servers. You want a world where a browser exploit can drop a bootkit? Nahhh
      - Gigachad 5y ago
        They could just drop something in bashrc or somewhere else for a persistent exploit. The system files contain nothing worth touching on a personal device.
        randomhodler84 5y ago
        Persistent userspace. And while I understand privesc in major platforms is not the insurmountable problem it seems, it is still a layer of protection important to the model of preventing SMM, hypervisor efi boot and root level persistence, without something else up its sleeves.

schemescape 5y ago

I switched from Node to Deno partly for exactly this functionality. But you’re probably looking for something more general, like containers, virtual machines, or other sandboxes (chroot?).

cersa8 5y ago
I don't think fetching arbitrary code over url's is somehow better than npm.
- machiaweliczny 5y ago
  Deno has module hashing and sanboxes OS access AFAIK

raffraffraff 5y ago

Run it in a container. Don't let the container run as root - create an account which has the same ID as a dummy account on your host system. If you have to volume mount, be very explicit about what paths you mount and use the read only flag if it makes sense. If you can't mount read only because you need to write to certain files, then grant the container account access to those files using ACLs (eg: on Linux user 'chmod' or 'setfacl').

lmarcos 5y ago
Running it as user nobody within the container should be enough, no?
- raffraffraff 5y ago
  That should do it, as long as both host and container systems implement the nobody user on the same ID. Which is likely. But I'd check all the same

gwmnxnp_516a 5y ago

This node npm supply chain attack incident is a wake up call that the current security model of mainstream operating systems such as Linux, MacOSX or Windows are no longer suitable for modern day threats and they need a "zero-trust" like model for applications. Mitigating supply chain attacks like this one requires adopting application sandboxing by default, assuming that any application can be compromised, and capability-based security model like Fuchsia, Genode OS or mobile operating systems like Android or Apple's IOS. In the case of Linux, the most suitable sandboxes are docker container and Firejail tool that can restrict operating system resources which an application can access, including the $HOME directory. Firejail can even provide a fake $HOME directory. In the case of Microsoft windows, there is the Windows Sandbox, but it is only available on Windows pro or enterprise. But even so those countermeasures would only prevent the user data from being damaged, malicious NPM packages could still attempt to send credentials, tokens or database information back to the attacker. More details at: https://hkubota.wordpress.com/2020/12/31/comparing-sandboxing-tools/ https://hkubota.wordpress.com/2020/12/31/comparing-sandboxin... and https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview https://docs.microsoft.com/en-us/windows/security/threat-pro.... Another suitable mitigation strategy may be lock dependencies version or switch to other programming languages with a proper standard library and limited number of packages where one can at least audit the code.

properparity 5y ago

I guess people have forgotten the lessons of 90s Windows: Don't download and run random .exe from the internet, assume they are hostile until proven otherwise. Don't download, install and run random code libraries from the internet, assume they are hostile until proven otherwise.

jbjohns 5y ago
I don't think that's really fair. Unity 3d and Vue.js are not random.exe.
- samhw 5y ago
  I think their point might have been that Unity forgot that lesson. And everyone else, transitively, along the chain. As horrible and impracticable as it sounds, the only way to prevent this happening is to read the source of every (/transitive) dependency you install. Yes, we can trust people, and yes, we can blame them when they betray our trust - we can even prosecute them - but as this shows, that's not always going to stop people. And it's certainly not going to stop attackers who gain control of those dependencies. This is something we really need to think about as a profession. I would favour a system where dependencies are restricted to pure computation only (no syscalls) and any greater permissions must be granted explicitly. But that's extremely onerous, and likely - for many devs - to lead to a 'just click yes' mentality; even besides that, there are doubtless many cases it won't prevent. All I'm sure of is that we can't continue like this.

z3t4 5y ago

yarn install --flat git add node_modules Then the next time you run yarn upgrade: yarn upgrade --flat git diff Carefully read through what changed in each of the packages. git add node_packages git commit -m "yarn upgrade" You will see a lot of bad code, but also learn stuff. But most importantly - your project will be secure.