Well, detecting potentially malicious shell scripts is merely a matter of solving the halting problem...

Food for thought: http://www.cs.dartmouth.edu/~sergey/langsec/

Would there be any benefit in creating a VM on the fly, running the shell script in the VM and there reporting back on what was modified by the shell script. If all goes well, I reckon you can then safely run the script on the host machine.

Even if you can be bothered to semi-manually audit the changes a script applies to the VM and can afford the time and space overheads of such a "guess-and-check" approach, a malicious server could send you a different script the second time you requested it, or the script could in turn pull down other payloads differently the second time it executed. If you try to extract a diff of the changes applied to the VM and then reapply it to your host machine to ensure the behavior is the same, why not simply have an installer system which behaves in a more restricted way to begin with? The root of the problem is that shell scripts fetched from remote servers are far too flexible to be 'safe'.

Or... use Docker!

Seriously, Docker is perfect for creating a sandbox with all dependencies to help new users get up and running quickly and safely. Every project should come with a Dockerfile and/or Vagrantfile.

... except when someone writes a script that guesses (or reliably detects, depending on container technology) whether it's running in a VM/container and acts differently then. Or if it only acts maliciously say, one out of five times ("old school" viruses would often do that - destroy your floppies sometimes, but most of the time just spread).

Sounds like a great application of Docker, come to think of it. I'm sure it's quite possible to spin up a new docker VM from a shell script and do exactly that.

Hm, the only problem is installing Docker in the first place ...

We're working on a few things that will make that much easier :)

I am not very good at unix command line, but maybe it could be done like this: curl http://get.docker.io > /tmp/docker-install && sh /tmp/docker-install && rm /tmp/docker-install that gives quick and easy way to inspect by executing only first command and then inspecting the source, i.e., 1) copy just first part curl http://get.docker.io > /tmp/docker-install 2) then inspect, e.g. cat /tmp/docker-install 3) run the install sh /tmp/docker-install && rm /tmp/docker-install or, if not reviewing run whole at once

p.s. I know, that there should not be direct copy-paste from browser to console and this method leaves a file in /tmp on installation failure

> The usability of the curl pipe approach is here to stay, so the least we can do is help people be safe with it.

I don't think this is true. It's just going to take a very popular project getting their DNS hijacked before everyone wakes up.

Well, you are right about the usability part. That part is amazing. It's just that curl-pipe is not the answer.