3 ms·
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
by vanviegen 6y ago
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.
- dwohnitmok 6y agoThis 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.
- vanviegen 6y agoYou wouldn't need to run the script twice. Just apply the file modifications when the user okays them.
- joosters 6y agoBut 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.
- vanviegen 6y agoThe 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.)
- mlyle 6y agoSandboxing is plausible. Statically analyzing for potential changes a priori not so much.