61–70 of 86 posts
What would be amazing is a tool that analyses the script first, figures out folders and files (and networking) it influences and allows to sandbox it accordingly. 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?
What would be amazing is a tool that analyses the script first, figures out folders and files (and networking) it influences and allows to sandbox it accordingly. 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?
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.
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.
What would be amazing is a tool that analyses the script first, figures out folders and files (and networking) it influences and allows to sandbox it accordingly. 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?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
Because that's an unrealistic threat model for most users.
I think the most realistic threat model right now is "subverted browser extension", which is effectively equivalent to internet-wide XSS. Luckily I've only been hit once, and with adware, but it's a risk.
Earlier quoted context omitted.
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?
The argument doesn't rely on infinite memory.
I made a little demonstration script.
deno run --prompt https://crux.land/4Lc2E2
Earlier quoted context omitted.
I think the most realistic threat model right now is "subverted browser extension", which is effectively equivalent to internet-wide XSS. Luckily I've only been hit once, and with adware, but it's a risk.
A browser extension is not a threat model, I'm not sure what you mean.