Hacker News Reader

Hacker News

Comment by tomphoolery | Hacker News Reader

Full thread

tomphoolery

it would be cool if there was a way to show which commands npm was running in its scripts.

View on HN

Or if it saw anything dangerous, it'd confirm that you want to run it.

Edit: Fair points on all the comments below, pardon my ignorance :)

See Halting Problem:

http://en.wikipedia.org/wiki/Halting_problem

ELI5: It is proven to be impossible to tell exactly what a program is going to do without executing it.

The Halting Problem says it’s impossible to tell whether a program will naturally finish what it’s going to do without doing it.

You can obviously tell what a trivial program will do by looking at it.

For systems like rubygems and npm, a build tool that installs the gems with sudo on a clean system and flags obvious issues would be a good thing.

(If the halting problem is a problem, try executing it in a sandbox.)

While that may be true for an unrestricted language, it doesn't need to be true of the programs we design. There's no reason that an installer needs to be written in a completely unrestricted way. NPM could use a DSL which would make it possible to review what an installer is going to do.

This is an idea I (with some collaborators) have explored in a more general way for secure shell scripting: shill-lang.org.

How would it catch something like

  cp /bin/rm ponies ; ./ponies -rf /

or you can create a ponies alias, even more harmless-looking

The same way checkinstall detects which files have been installed - it overrides the relevant syscalls when running the program/script: http://asic-linux.com.mx/~izto/checkinstall/installwatch.htm...

Of course, not everything is as obvious to detect as deleting files :)

Well, checkinstall acts at the dynamic linking level. If you use ASM to call the syscall directly (or more generally, a statically linked binary) then checkinstall will not even see it (strace/DTrace/ktrace would.)

The problem is that identifying a dangerous command via a blacklist ends up being pretty difficult. This is why VMs and chroots and the like end up being so useful: the best way to make sure a command only accesses what it should is usually to give it specific explicit access to the resources it should have, rather than blacklisting what it can/cannot run.

`--verbose`

Reply on news.ycombinator.com