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

jiabanl

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