A rogue npm package is my nightmare scenario, those packages are like the only (or I wish..) untrusted code my OS is running.
That's why I came up with a small script/service waiting for an "inotify" event on a honey-pot SSH key (and some other files like ~/passwords.doc) which will immediately shutdown the computer on any kind of access of those files.
#!/bin/sh
inotifywait -e open --fromfile ~/.config/killer/killer.cfg --outfile ~/.config/killer/killer.log
if [ $? -eq 0 ]; then
poweroff
fi
How does that solve an accidental grep that touches a file being monitored? Grep and your key are both trusted, and there are numerous ways someone can try to read the key despite only running specific things in a vm (and forgetting that VMs aren't bulletproof)
Don't forget about ransomware. Imagine the rogue package encrypted your files and demanded payment to get the decryption key. With public key encryption or a symmetric key that is securely deleted, there is no need for network access for the attack to succeed. A fast shutdown could protect most of your files.
Good point. I haven’t thought about it much since I’m on macOS and Linux but it’s not like they’re immune. The idea of a node module encrypting my home directory (even with backups) makes me a tad nervous.
You don't have to run untrusted npm packages for development. I do all of my development on development servers and just sync over node_modules for IDE autocompletion.
Powering off will destroy valuable evidence, though, most payloads live in-memory nowadays. Maybe just disable the NIC?
It's not going to do much against a determined adversary, anyway. If he's prepared to turn the NIC back on, he would just kill your inotifywatch first.
Honestly, I didn't give it any serious thought, I came up with the idea and quickly executed it as a PoC in a couple of minutes after that compromised npm package incident a while ago.
Disabling the NIC is a nice idea too, it should also be much quicker than shutting the machine down, so, please, feel free to make the script better.
The only "clever" thing I did was making sure the honey-pot key comes first in the ~/.ssh directory and that it's big (to gain time to poweroff while it's being transmitted to somewhere).
Clearly, this is not a protection against a determined adversary.
That's why I came up with a small script/service waiting for an "inotify" event on a honey-pot SSH key (and some other files like ~/passwords.doc) which will immediately shutdown the computer on any kind of access of those files.