This script wants to modify:
- /usr/local/program/*
- /etc/program/*
- $HOME/.program
Do you want to execute this? [Yes/No]
..because you know, what happens when you execute a script that does rm -rf /usr in the 100th step?
This script wants to modify:
- /usr/local/program/*
- /etc/program/*
- $HOME/.program
Do you want to execute this? [Yes/No]
..because you know, what happens when you execute a script that does rm -rf /usr in the 100th step?
That doesn't mean what you want is completely unattainable, you just need to figure out whether you're okay with false positives, false negatives, or your tool just giving up on certain scripts (or some combination thereof).
Such a static analyser would have two interesting aspects: on the end user side, the one mentioned of outputting the touched paths, and also doubling as being a linter for the script developer.
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.
The argument doesn't rely on infinite memory.
In real systems external inputs provide an infinite source of "memory" to read from.
(you know, like proprietary drivers almost always do)
It would be a huge improvement for sysadmins if a linter could be run in advance of executing a shell script, and use chroot and other sandboxing like creating a user without net cap rights etc in case it found something potentially malicious.
This would still allow the script to steal data though, as installer script generally require internet access.