Such can be easily implemented on top of Docker filesystem overlays/snapshots. You just run the script in question e.g. in fresh Ubuntu container and then compare overlay directories to see what changed.
If you are happy with running it only once in the container, yes.
But if you run it first in the container to see whether is does anything bad and then run it on the host (or a more valuable container), no.
The script might check whether it runs in a container. It might depend on the wall clock time. On /dev/urandom, whatever. As somebody already mentioned, the halting problem. No can do.
Comments
Such can be easily implemented on top of Docker filesystem overlays/snapshots. You just run the script in question e.g. in fresh Ubuntu container and then compare overlay directories to see what changed.
If you are happy with running it only once in the container, yes.
But if you run it first in the container to see whether is does anything bad and then run it on the host (or a more valuable container), no.
The script might check whether it runs in a container. It might depend on the wall clock time. On /dev/urandom, whatever. As somebody already mentioned, the halting problem. No can do.
doesn't the halting problem only hold if you have infinite memory?
That's probably correct. But any reasonable execution environment has so many states that doing a full enumeration is infeasible.
I've seen this argument that 'halting problem is undecideable': http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html
The argument doesn't rely on infinite memory.
With finite memory and no external inputs an observer can enumerate all possible states.
In real systems external inputs provide an infinite source of "memory" to read from.