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'.
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 ...
