Shell脚本和安全性

Question

TLDP的高级Bash脚本指南指出不应将shell脚本用于“situations where security is important, where you need to guarantee the integrity of your system and protect against intrusion, cracking, and vandalism。”

是什么让shell脚本不适合这种用例？

Answer 1

由于shell的可塑性，很难验证shell脚本是否执行其预期的功能，而仅在面对对抗输入时是如此。 shell的行为方式取决于环境，以及自身众多配置变量的设置。每个命令行都有多个级别的扩展，评估和插值。一些shell构造在子进程中运行，而构造包含的变量在父进程中扩展。在设计可能受到攻击的系统时，所有这些都与KISS原则背道而驰。

Answer 2

可能因为它很容易搞砸了。如果未正确设置PATH，脚本将开始执行错误的命令。在字符串中的某处放置空格可能会导致它稍后成为两个字符串。这些可能导致可利用的安全漏洞。简而言之：shell会为您的脚本行为提供一些保证，但它们对于真正安全的编程来说太弱或太复杂。

（对此我想补充一点，安全编程本身就是一门艺术，并且可以用任何语言进行搞砸。）

Answer 3

我不同意这种说法，因为没有任何关于使它们本身不安全的脚本。如果遵循一些简单的指导原则，Bash脚本是非常安全的：

• 脚本是否包含其他人无法查看的信息？ 如果是这样，请确保它只能由所有者读取。
• 脚本是否依赖于someWherE的输入数据？如果是，请确保输入数据 不能以任何方式受到污染，或者可以检测到污染的数据 并丢弃。
• 如果其他人试图运行它，那是否重要？ 脚本？如果是这样，与第一点一样，确保没有人可以执行它，最好不要从中读取。对于执行系统功能的脚本，chmod 0700通常是一个好主意。
• 你希望脚本有一个setuid（通过它的解释器）的情况是 非常罕见

将脚本与已编译程序分开的两点是源是可见的，并且解释器执行它。只要解释器​​没有被泄露（比如有一个setuid位），你就可以了。

编写脚本来执行系统任务时，拼写错误以及写入时的一般人为错误在某种程度上表示潜在的安全性失败，但编译程序也是如此（而且很多人都忽略了编译程序也可以被反汇编的事实）

值得注意的是，在大多数（如果不是全部）Linux风格中，大多数（如果不是全部，实际上，不能想到任何不是）服务都是通过shellcript启动的。

Answer 4

• 坏男孩更容易让shell脚本以不同的方式工作（它与其他进程，PATH，shell函数，prifile交互很多）
• 好男孩更难处理敏感数据（传递密码等）