Very difficult to do in any kind of robust way. A script can run all kinds of things and use myriad forms of obfuscation, causing all kinds of obscure side effects.
When trying OPs code out, I had all the "linux binaries" in mind, aka all the shitty self-unpacking installers that concat their binaries and dump it in /tmp before executing it.
(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 be defeated by any script that is nondeterministic which is a real possibility if you're trying to defend against malicious scripts or against very poorly written scripts.
But the modifications might not be valid in the real system. For example, imagine a script that adds a new user to the system: in the container, it picks a new user ID that is free. A diff of the filesystem will show a new line being added to /etc/passwd - seems OK, right? But the user ID picked might clash with one on the real system, causing everything to fail when you apply the change.
The sandbox would provide a copy-on-write view of the actual filesystem (hence the possibility of data being stolen), so that scenario would work fine. (Though race conditions may be a concern.)
Comments
Very difficult to do in any kind of robust way. A script can run all kinds of things and use myriad forms of obfuscation, causing all kinds of obscure side effects.
When trying OPs code out, I had all the "linux binaries" in mind, aka all the shitty self-unpacking installers that concat their binaries and dump it in /tmp before executing it.
(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.
I imagine this could be done by actually running the script in some sort of sandbox, having file changes written to overlayfs at first.
This would still allow the script to steal data though, as installer script generally require internet access.
This would still be defeated by any script that is nondeterministic which is a real possibility if you're trying to defend against malicious scripts or against very poorly written scripts.
You wouldn't need to run the script twice. Just apply the file modifications when the user okays them.
But the modifications might not be valid in the real system. For example, imagine a script that adds a new user to the system: in the container, it picks a new user ID that is free. A diff of the filesystem will show a new line being added to /etc/passwd - seems OK, right? But the user ID picked might clash with one on the real system, causing everything to fail when you apply the change.
The sandbox would provide a copy-on-write view of the actual filesystem (hence the possibility of data being stolen), so that scenario would work fine. (Though race conditions may be a concern.)
Sandboxing is plausible. Statically analyzing for potential changes a priori not so much.