[PATCH] treewide: more portable bash shebangs

[Jörg Thalheim]

On 17/07/2019 18.32, Jordan Glover wrote:
> On Tuesday, July 16, 2019 10:08 PM, Jörg Thalheim <joerg at higgsboson.tk> wrote:
>
>> On 16/07/2019 18.32, Jordan Glover wrote:
>>
>>> On Tuesday, July 16, 2019 12:21 PM, Jörg Thalheim joerg at higgsboson.tk wrote:
>>>
>>>> While /usr/bin/env is more or less available on all POSIX systems
>>>> /bin/bash might not be. This is particular the case on NixOS and the BSD
>>>> family (/usr/local/bin/bash). Downstream packagers would often rewrite
>>>> those shebangs back automatically as they can rely on absolute paths
>>>> but having portable shebangs in the repository helps to run the code
>>>> without any further modification.
>>> The reason almost everyone hardcodes bash to /bin/bash is the potential
>>> environment attack where someone create malicious "bash" and export it in PATH:
>>> https://developer.apple.com/library/archive/documentation/OpenSource/Conceptual/ShellScripting/ShellScriptSecurity/ShellScriptSecurity.html
>>> Obviously wg scripts are handling quite sensitive data like private keys...
>>> Seriously if you except that downstream packagers would rewrite it back to
>>> /bin/bash then why the others can't rewrite it to /usr/bin/env bash right
>>> now if this is something they want?
>>> Jordan
>> This argument does not apply here since all commands internally could
>> be redirected by a PATH change as well since the PATH is not set in the scripts.
> Yep, that's something to actually fix as you won't fix things by making it worse.
It does not make anything worse. Your threat model is unreasonable and out of scope
of what the scripts are intended to guarantee.
There are tones of other environment variables like LD_PRELOAD or LD_LIBRARY_PATH

that would also need to be sanitized so they could run in an untrusted environment.

Hard-coding all these would make the scripts unportable for no good reason.

>
>> I am also not quite sure what threat model here is?
>> The scripts changed here are not designed to run from a CGI context
>> and are not hardened for that purpose.
>> The idea is that you can run the scripts unmodified from the repository
>> without having to alter the files, which is convenient for development w.r.t to git.
> Then simply run "bash <script.sh>" and call it a day.

I came across this because wireguard was used in a third-party build system not controlled by me,
so this is not a general solution.


>
> Jordan
>
>