Live data from Hacker News

Show HN: Run unknown shell script with a line-by-line confirmation prompt

gist.github.com

81–86 of 86 posts

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#81

Earlier quoted context omitted.

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.)

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#82
post #45

Earlier quoted context omitted.

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.

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.

Sandboxing is plausible. Statically analyzing for potential changes a priori not so much.

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#83

Earlier quoted context omitted.

You could snapshot your filesystem, then run the script and diff against the snapshot. Isolating executables (even shell scripts) is really outside the scope of what a shell normally provides.

This sort of provides rollbacks but not isolation. You would have to rollback all chances that happened to the filesystem (or the whole system if you don't know what filesystems were touched by the program) during the period between snapshot and when you finish your inspection. It would be interesting if you could mount the snapshot then attempt to merge in the changes to the live system once approved. I don't know i…

Yeah, a shell is never going to provide isolation. If you want isolation, then snapshot your filesystem, assign it to a VM and run the script there. But this isn't actually useful because:

1. You probably will need network to run whatever script this is. Once you give the script network access, you are open to a whole bunch of issues. Perhaps your ssh private keys leave your system for example.

2. If you don't give it network access, it probably won't do anything malicious. Most of these scripts exist just to download some "thing", install it, maybe run it, and maybe update an RC file. The malicious code might be in the executables downloaded by the script rather than the script itself.

3. Just because a script does something reasonable in a VM doesn't mean it isn't malicious and won't do something else when it is run on bare metal.

In the end, you have to trust whatever software you decide to run (scripts included). How you gain that trust is up to you. I would steer away from gaining that trust by running the script and seeing what happens. Personally, I just rely on the reputation of the source of the software.

Verifying that some script doesn't screw up the configuration of my machine is a different story. I hate it when some script decides to run "pip install" or some other thing that subverts my package manager. Here, taking a snapshot is a reasonable choice.

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#84

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?

That sounds a lot like what maybe[1] does. [1] https://github.com/p-e-w/maybe

This tool sounds amazing. Do you know what happened or the reason why the project got archived by the author?

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#85
post #75

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?

You could do this by running your script pivot mounted into a namespace that mounts your "real" filesystem as readonly and layers with overlayfs to log changes. You can then terminate the script if the overlay diff gets too large (I assume on a 100GB disk you don't want 60GB of changes, and in any case you could tell it what to expect beforehand). That saves you having to do all this complicated analysing for files a…

Not without danger or failure if the scripts depend on internet connectivity, since they could either ex-filtrate data or change their behavior based on the connection being present or not.

Re: Show HN: Run unknown shell script with a line-by-line confirmation prompt

#86
post #22
post #8

Possibly relevant, the bash restricted shell (bash -r): https://www.gnu.org/software/bash/manual/html_node/The-Restr...

> When a command that is found to be a shell script is executed (see Shell Scripts), rbash turns off any restrictions in the shell spawned to execute the script. Can you provide example of a scenario where this restricted shell is useful?

Oh, I'd say when you're running your own stuff, it's only guardrails. I don't think anybody's gonna say it should be any account's login shell or anything. Sure, there's the idea that attackers could break out of it with such a simple featurebug, but it's nice to be able to shed functionality when automating things that could go very wrong.
Post reply on HN