一起学shell（十一）之安全的shell脚本：起点

煮酒品茶：安全性shell脚本提示、限制性shell、特洛伊木马、为shell脚本设置setuid:坏主意，ksh93与特权模式。这章基本上是完全抄吧，因为这是原作的纯经验，也不敢自己去随便修改。

以下都是重点：

为bin目录设置保护

确认$PATH下的每一个目录都只有它的拥有者可以写入，其余任何人都不能，同样的道理也应应用于bin目录里的所有程序。

写程序前，先想清楚

花点时间想想，你想要做的是什么，该如何实行。

应对所有输入参数检查其有效性

如果你期待的是数字，那么验证拿数字。

对所有可返回错误的命令，检查错误处理代码

不在预期内的失败情况，很可能是有问题的强迫失败，导致脚本出现不当的行为。

不要信任传进来的环境变量

如果它们被接下来的命令（例如TZ、PATH、IFS）使用时，请检查并重设为已知的值。

从已知的地方开始

在脚本开始时，请切cd到已知目录，这么一来，接下来的任何相对路径名称才能指到已知位置。请确认cd操作成功

[root@localhost new]# cd ~ ||exit 1

在命令上使用完整路径

这么做使你才能知道自己使用的是哪个版本，无须理会$PATH设置

使用syslog保留审计跟踪

当使用该输入时，一定将用户输入引用起来

如："$1"与"$*"，这么做可以防止居心不良的用户输入作超出范围的计算与执行

勿在用户输入上使用eval

甚至在引用用户输入之后，也不要使用eval将它交给shell再处理，如果用户读了你的脚本，发现你在使用eval，就能轻松地利用这个脚本进行任何破坏。

利用通配字符展开的结果

你可以将空格、分号、反斜杠等放在文件名里，让棘手的事情交给系统管理员处理，

检查用户输入是否有meta字符

如果使用eval或$(....)里的输入，请检查是否有像$或'这类的meta字符

检测你的代码，并小心阅读它

寻找是否有可被利用的漏洞与错误，把所有坏心眼的想法都考虑进去，小心研究你的代码，试着找出破坏它的方式，再修正你发现的所有问题。

留意竟争条件

攻击者是不是可以在你的脚本里的任两个命令之间执行任意命令，这对安全性是否有危害，如果是，换个方式处理你的脚本。

对符号性连接心存怀疑

在chmod文件或是编辑文件时，检查它是否真的是一个文件，而非连接到某个关键性系统文件的符号连接（利用[ -L file] [-h file]）检测file是否为符号性连接。

找其他人重新检查你的程序，看看是否有问题。

通常另一双眼睛才能找出原作者在程序设计上陷入的盲点。

尽可能用setgid而不要用setuid

使用新的用户而不是root

如果你必须使用setuid访问一组文件，请考虑建立一个新的用户，非root的用户做这件事并设置setuid给它。

尽可能限制使用setuid的代码

限制性shell

是将用户置于严格限制文件写入移动的环境中，用户多半是使用访客帐号

变更工作目录：cd是没有作用的。如果尝试使用它，会收到错误信息

不允许重定向输入到文件：重定向运算符>,>|,<>,>>都不被允许，这点不包含exec的使用。

指定新值给环境变量ENV,FPATH,PATH.SHELl或试图以typeset改变它们的属性。

标题任何带有斜杠（、）的命令路径名称，shell权执行在$PATH里找到的命令。

使用builtin命令，增加新的内置命令。

特洛伊木马

为shell脚本设置setuid坏主意

为用户设置一个用户ID这是一个特殊限位。

Ksh93与特权模式

特权模式设计就是为了对付setuid的shell脚本，这是一个set -o选项，无论何时当shell执行之脚本已设置setuid伴时，shell便会自动输入它，也就是说，当有效用户ID与实际用户ID不同时。

煮酒品茶：到这里其实大章就已经看完了，很多东西其实还都没完全懂，所以还需要翻阅多次，从读脚本到评论脚本最后到写脚本的过程是要慢慢来的。这章的内容写的非常深入我心，一个好的脚本就是要把所有未知和有害的因素考虑进去。故，努力吧。

<完>