I am sorry, but I fail to see how this would be of any help.
It is known that piping unknown scripts to bash is a bad thing. So when somebody decides to pipe into bash, they are either (1) sure of the source or (2) completely clueless about what the hell they are doing. In case (1) there is no need for the tool, and in case (2) asking "do you really want to run this?" will not make any difference since they just typed 'curl <whatever> | sh' into their shell.
This.
What if OP inspected the script and highlighted potential harmful commands? Changes in security configurations, manipulation in critical libraries, start-up scripts, and so forth.
Not sure how much that would help to the novice, but it's at least actionable (user can look the commands up and understand the implications.
vipe[0] from moreutils is a bit more general purpose command than this. It does not dictate the receiving end. So you can quickly check and correct data between pipes. Nifty stuff...
I'm not sure that this is as safe as you may think.
EDIT More info. Yes this is better than curl ... | sh. But less has a lot of functionality (more than you'd expect) and a carefully written script could exploit some of this.
Basically the tldr is that gnu less is a program that has been engineered to do a lot of things over the years and this has created attack surfaces which mean that if someone was to curl .... | less on a carefully designed payload it could allow the payload to obtain a shell.
I wasn't saying that it isn't safer just that it isn't totally safe.
Would that really be any different that downloading the script, then opening it with less/vim/whatever locally, which is typically going to be pretty safe, unless the script is accidentally executed somehow.
I like the sentiment, but I kinda doubt that the group of folks who would inspect the script before running if only it wasn't so inconvenient to do so has many members.
We live in an era of unsigned images and arbitrary code. This is about time and money, and I don't think any amount of astonishment from the larger community is going to reverse that trend.
Just brain storming... could another possible solution be to create a public list of hashes of well known scripts, and then write a small `sh` wrapper that verifies that hash of the script it's about to execute?
You shouldn't always trust even 'trusted' scripts due to the potential for various types of man in the middle attacks. True, though, that with all things being equal some scripts are more trustworthy than others, but if you're on a compromised network then you can't trust any.
What would it do which can't already be done with normal nix permissions and/or ACLs? The solution is to create a user account, like www-run or redis or Postgres or any of the other tons of things which already do this.
An even better idea is jails, or something like Docker.
25 comments
[ 3.1 ms ] story [ 66.7 ms ] threadIt is known that piping unknown scripts to bash is a bad thing. So when somebody decides to pipe into bash, they are either (1) sure of the source or (2) completely clueless about what the hell they are doing. In case (1) there is no need for the tool, and in case (2) asking "do you really want to run this?" will not make any difference since they just typed 'curl <whatever> | sh' into their shell.
[0]: https://joeyh.name/blog/entry/moreutils/
Thats generally what I do when I encounter the curl -> bash instructions on the web.
EDIT More info. Yes this is better than curl ... | sh. But less has a lot of functionality (more than you'd expect) and a carefully written script could exploit some of this.
Basically the tldr is that gnu less is a program that has been engineered to do a lot of things over the years and this has created attack surfaces which mean that if someone was to curl .... | less on a carefully designed payload it could allow the payload to obtain a shell.
I wasn't saying that it isn't safer just that it isn't totally safe.
We live in an era of unsigned images and arbitrary code. This is about time and money, and I don't think any amount of astonishment from the larger community is going to reverse that trend.
Just: $ sandbox 'curl http://whatever | sh'
With predefined permission profiles or interactive permission system.
An even better idea is jails, or something like Docker.
Jails or Docker are practically heavyweight sandboxes and they need root access.