Show HN: Run unknown shell script with a line-by-line confirmation prompt (opens in new tab)

I would be fine with a static analyser doing the last one (giving up in doubt), considering that install scripts are a smaller subset of all possible shell scripts.

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.

False positives (this program could access these file locations) seems like a reasonable tradeoff.

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.

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.

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 tool sounds amazing. Do you know what happened or the reason why the project got archived by the author?

Yeah, this is an absurd argument. How do I know I can trust Linux unless I personally audit the whole kernel? How do I know if I can trust my processor without an x-ray machine?

I would probably start by reading a book.

I understand your point, but there is a big difference between running a 20 year old program written in C and running a shell script that someone with one or two years of experience hacked out in ten minutes. To answer your question, I do fuzz many of the GNU utilities that I use regularly, and I have discovered vulnerabilities that way. Of course it is unreasonable to read all of the code that runs in our operating systems, but it is not unreasonable to read shell scripts before you run them.

> I want this to run my own shell scripts.

That's really the only use case for this tool that I could get behind, and I commend you for your diligence.

newer versions of gnome-terminal have a feature where it will hold your paste buffer in the linefeed before executing anything, does not matter how long or how many line breaks there are. You can then inspect what you just paste into the terminal, even edit it, before actually executing it.

Excuse my ignorance but when are you copying commands from a site you don't trust? If I don't trust a site I don't run anything it suggests to me, copy hijacking or no.

Open your shell prompt, press ^X^E, paste the script into the opened editor. Check it for anything malicious, save and exit (or exit without saving if you don't want to execute it). The shell will execute the script.

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 if any filesystems that support merges though.

Reflections on trusting trust wouldn't really apply here. The script is not a compiler, is not even compiled, and can be easily understood by reading it. Unless you think there is some vulnerability specific to /bin/sh and this script the citation is just wrong.

Heredocs are a little odd, because you can't see what they might be piping to.

This script, for example looks sort of innocuous when run through your tool because it's not obvious the HEREDOC is going to the stdin of a Perl interpreter. Your tool shows them like they are two separate things that don't do much by themselves.

Looking at the script itself, it's more obvious.

  #!/bin/sh
  cat<<'EOF'|perl -nE'BEGIN{shift(@ARGV)}s#(.*)#$1#ee' /dev/null
  say "hello"; #arbitrary perl code
  EOF

That's probably a nit, really, though. I don't know that anyone would target it on purpose.

Or LFS=

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.