书写安全Shell脚本的注意事项

【前言】

本文译自《Classic Shell Scripting》

UNIX的安全性一向是恶名在外，几乎从每个角度看，UNIX系统都有或多或少的安全性争议，不过这些大部分都是系统管理者应该担心的。下面列出了一长串“诀窍”，提醒你编写Shell脚本应该注意的地方，以避开安全性问题。这些注意事项，都是UNIX安全性领域的专家所认可的。 
 

勿将当前目录(.)放到PATH中

    可执行程序应该只能放在标准的系统目录下，将当前目录放到PATH里，无疑是打开特洛伊木马的大门.

为bin目录设置保护

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

写程序前，先想清楚

    花点时间想想，你想要做的是什么、该如何实行。不要一开始就在文字编辑器上直接写，而且，在它真的开始运作前，要不断地设计测试。错误与失败的优雅处理，也应该设计在程序里。

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

    如果你期待的是数字，那就验证你拿到的是数字。检查数字是否在正确的范围内。同样的检查也应该出现在其他类型的数据上，SHELL的模式匹配工具(case)可以将这个工作处理的很好

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

    不可预期内的失败情况，很可能是有问题的强迫失败，导致脚本出现不当的行为。 例如:如果参数为NFS加载磁盘或面向字符的设备文件时，即使是以root的身份执行，也可能导致有些命令失败。

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

    如果它们被接下来的命令(例如:TZ,PATH,IFS等)使用时，请检查并重设为已知的值。ksh93会在启动时自动重设IFS为它的默认值，无论当时环境为何，但其他许多Shell就不会这么做了。无论什么情况下，最好的方式就是明确地设置PATH只包含系统bin目录，并设置IFS为"空格-定位字符-换行字符"(space-tab-newline)

从已知的地方开始

    在脚本开始时，确切cd到已知目录，这么一来，接下来的任何相对路劲名称才能指到已知位置。请确定cd操作成功.cd Your-Dir || exit 1      



在命令上使用完整路径

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



使用syslog保留审计跟踪

    记录引用的日期与时间、username,如果没有logger，可建立一个函数保留日志文件:

    logger()

    {

    printf "%s\n" "$*" >> /var/adm/logsysfile

     }

    logger "Run by user" $(id-un) "($USER) at" $(/bin/date)



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

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



勿在用户输入上使用eval

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



引用通配字符展开的结果

    你可以将空格、分号、反斜杠等放在文件名里，让棘手的事情交给系统管理员处理。如果管理的脚本未引用文件名参数，此脚本将会造成系统出问题。



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

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



检查你的代码，并小心谨慎阅读它

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



留意竞争条件

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



对符号性连接心存怀疑

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



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

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



尽可能用setgid而不要用setuid

    简而言之，使用setgid能将损害限制在某个组内



使用新的用户而不是root

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



尽可能限制使用setuid的代码

     尽可能让setuid代码减到最少。将它移到一个分开的程序，然后在大型脚本里有需要时才引用它。无论如何，请做好代码防护，好像脚本可以被任何人于任何地方引用那样！

Bash维护工程师Chet Ramey提供了下列代码的开场白，给那些需要更多安全性的Shell脚本使用: