Shell 脚本和安全性
TLDP 的高级 Bash 脚本指南指出，shell 脚本不应用于“安全性很重要的情况”需要保证系统的完整性并防止入侵、破解和破坏。”
是什么让 shell 脚本不适合这样的用例？
TLDP's Advanced Bash Scripting Guide states that shell scripts shouldn't be used for "situations where security is important, where you need to guarantee the integrity of your system and protect against intrusion, cracking, and vandalism."
What makes shell scripts unsuitable for such a use case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于 shell 的可塑性，很难验证 shell 脚本是否执行了其预期功能，并且在面对对抗性输入时仅执行该功能。 shell 的行为方式取决于环境以及其自身的众多配置变量的设置。每个命令行都经过多个级别的扩展、评估和插值。某些 shell 结构在子进程中运行，而该结构包含的变量在父进程中扩展。在设计可能受到攻击的系统时，所有这些都违背了 KISS 原则。
Because of the malleability of the shell, it is difficult to verify that a shell script performs its intended function and only that function in the face of adversarial input. The way the shell behaves depends on the environment, plus the settings of its own numerous configuration variables. Each command line is subject to multiple levels of expansion, evaluation and interpolation. Some shell constructs run in subprocesses while the variables the construct contains are expanded in the parent process. All of this is counter to the KISS principle when designing systems that might be attacked.
可能是因为很容易搞砸。当
PATH设置不正确时，您的脚本将开始执行错误的命令。在字符串中的某个位置放置空格可能会导致它稍后变成两个字符串。这些可能会导致可利用的安全漏洞。简而言之：shell 为您的脚本行为提供了一些保证，但对于真正安全的编程来说，它们太弱或太复杂。（对此，我想补充一点，安全编程本身就是一门艺术，任何语言都可能搞砸。）
Probably because it's just easy to screw up. When the
PATHis not set correctly, your script will start executing the wrong commands. Putting a space somewhere in a string might cause it to become two strings later on. These can lead to exploitable security holes. In short: shells give you some guarantees as to how your script will behave, but they're too weak or too complex for truly secure programming.(To this I would like to add that secure programming is an art in itself, and screwing up is possible in any language.)
我不同意这种说法，因为脚本本身并不安全。如果遵循一些简单的准则，Bash 脚本是完全安全的：
如果是这样，请确保只有所有者才能读取它。
不能以任何方式被污染，或者可以检测到被污染的数据
并被丢弃。
脚本？如果是这样，与第一点一样，确保没有人可以执行它，并且最好不要从中读取。对于执行系统功能的脚本来说，chmod 0700 通常是个好主意。
极其罕见
将脚本与已编译程序分开的两点是源代码是可见的，并且解释器会执行它。只要解释器没有受到损害（例如有 setuid 位），就没有问题。
当编写脚本来执行系统任务时，拼写错误、搞砸以及编写脚本时的一般人为错误确实在某种程度上代表了潜在的安全故障，但编译后的程序也会出现这种情况（很多人倾向于忽略这样一个事实：编译的程序也可以反汇编）
值得注意的是，在大多数（如果不是全部）Linux 风格中，大多数（如果不是全部，事实上，想不出任何不是）服务都是通过 shellscript 启动的。
I would disagree with that statement, as there is nothing about scripts that make them inherently unsafe. Bash scripting are perfectly safe if some simple guidelines are followed:
If so, make sure it's only readable by the owner.
can not be tainted in any way, or that tainted data can be detected
and discarded.
script? If so, as with the first point, ensure that nobody can execute it, and preferably not read from it. chmod 0700 is generally a good idea for scripts that perform system functions.
extremely rare
The two points that separate a script from a compiled program would be that the source is visible, and that an interpreter executes it. As long as the interpreter hasn't been compromised (such as having a setuid bit on it), you'd be fine.
When writing scripts to do system tasks, typos and screwups and general human error when writing it do to some extent represent a potential security failure, but that would also be the case with compiled programs (and a lot of people tend to ignore the fact that compiled programs can also be disassembled)
It is worth noting that in most (if not all) linux flavors, most (if not all, in fact, can't think of any that aren't) services are started via a shellscript.