级别： 初级 Gary McGraw (gem@cigital.com), 负责企业技术的副总裁, Cigital
John Viega (viega@cigital.com), 资深副研究员兼顾问, Cigital
2000 年 11 月 01 日 在本专栏中，Gary 与 John 介绍了能够帮助您除去代码中大多数安全性问题的 10 个原则。
上一篇文章中，他们讨论了适时提供冗余安全性措施以及如何从错误中安全地恢复。这一次，他们主要讨论在少量地给予权限时保持吝啬的重要性，即只对必需的访问给予尽可能短的时间。确保系统一部分的失败不会影响整个系统也很重要。
原则 4：最小特权
最小特权原则规定：只授予执行操作所必需的最少访问权，并且对于该访问权只准许使用所需的最少时间。
当您给出了对系统某些部分的访问权时，一般会出现滥用与那个访问权相关的特权的风险。例如，我们假设您出去度假并把您家的钥匙给了您的朋友，好让他来喂养您的宠物、收集邮件等等。尽管您可能信任那位朋友，但总是存在这样的可能：您的朋友未经您同意就在您的房子里开派对或发生其它您不喜欢的事情。
不管您是否信任您的朋友，一般不必冒险给予其必要的访问权以外的权利。例如，如果您没养宠物，只需要一位朋友偶尔收取您的邮件，那么您应当只给他邮箱钥匙。即使您的朋友可能找到滥用那个特权的好方法，但至少您不必担心出现其它滥用的可能性。如果您不必要地给出了房门钥匙，那么所有一切都可能发生。
同样，如果您在度假时确实雇佣了一位房子看管人，那么您不可能在没有度假时还让他保留您的钥匙。如果您这样做了，那么您使自己陷入额外的风险之中。只要当您的房门钥匙不受您的控制，就存在钥匙被复制的风险。如果有一把钥匙不受您的控制，而且您不在家，那么就存在有人使用钥匙进入您房子的风险。当有人拿了您的钥匙，而您又没有留意他们，那么任何这样的一段时间都会构成一个时间漏洞，在此段时间内您就很容易受到攻击。为了将您的风险降到最低，您要使这段易受攻击的时间漏洞尽可能的短。
现实生活中的另一个好的示例是美国政府的忠诚调查系统 ―“需要知道”政策。即使您有权查看任何机密文档，您仍不能看到您知道其存在的
任何机密文档。如果可以的话，就很容易滥用该忠诚调查级别。实际上，人们只被允许访问与那些交给他们的任务相关的文档。
UNIX 系统中出现过一些违反最小特权原则的最著名情况。例如，在 UNIX 系统上，您一般需要 root 特权才能在小于 1024 的端口号上运行服务。所以，要在端口 25（传统的 SMTP 端口）上运行邮件服务器，程序需要 root 用户的特权。不过，一旦程序在端口 25 上运行了，就没有强制性要求再对它使用 root 特权了。具有安全性意识的程序会放弃 root 特权并让操作系统知道它不应再需要那些特权（至少在程序下一次运行之前）。某些电子邮件服务器中存在的一个大问题是它们在获取邮件端口之后没有放弃它们的 root 权限（Sendmail 是个经典示例）。因此，如果有人找到某种方法来欺骗这样一个邮件服务器去完成某些恶意任务时，它会成功。例如，如果一位怀有恶意的攻击者要在 Sendmail 中找到合适的栈溢出（请参阅
参考资料），则那个溢出可以用来欺骗程序去运行任意代码。因为 Sendmail 在 root 权限之下运行，所以攻击者进行的任何有效尝试都会成功。
另一种常见情况是：一位程序员可能希望访问某种数据对象，但只需要从该对象上进行读。不过，不管出于什么原因，通常该程序员实际需要的不仅是必需的特权。通常，该程序员是在试图使编程更容易一些。例如，他可能在想，“有一天，我可能需要写这个对象，而我又讨厌回过头来更改这个请求。”
不安全的缺省值在这里可能还会导致破坏。例如，在 Windows API 中有几个用于访问对象的调用，如果您将“0”作为参数传递，那么这些调用授予所有的访问。为了更有限制地进行访问，您需要传递一串标志（进行“OR”操作）。只要缺省值有效，许多程序员就会坚持只使用它，因为那样做最简单。
对于受限环境中运行的产品的安全性政策，这个问题开始成为其中的常见问题。例如，有些供应商提供作为 Java applet 运行的应用程序。applet 构成移动代码，Web 浏览器会对此代码存有戒心。这样的代码运行在沙箱中，applet 的行为根据用户同意的安全性政策受到限制。在这里供应商几乎不会实践最小特权原则，因为他们那方面要花太多的精力。要实现大体意思为“让供应商的代码完成所有的任务”的策略相对要容易得多。人们通常采用供应商提供的安全性策略，可能是因为他们信任供应商，或者可能因为要确定什么样的安全性策略能最佳地使必须给予供应商应用程序的特权最小化，实在是一场大争论。
原则 5：分隔
如果您的访问权结构不是“完全访问或根本不准访问”，那么最小特权原则会非常有效。让我们假设您在度假，而你需要一位宠物看管人。您希望看管人只能进出您的车库（您不在时将宠物留在那里）但是如果您的车库没有一把单独的锁，那么您别无选择而只能让看管人进出整幢房子。
分隔背后的基本思想是如果我们将系统分成尽可能多的独立单元，那么我们可以将对系统可能造成损害的量降到最低。当将潜水艇构造成拥有许多不同的船舱，每个船舱都是独立密封，就应用了同样原则；如果船体裂开了一个口子而导致一个船舱中充满了水，其它船舱不受影响。船只的其余部分可以保持其完整性，人们就可以逃往潜水艇未进水的部分而幸免于难。
分隔原则的另一个常见示例是监狱，那里大批罪犯集中在一起的能力降到了最低。囚犯们不是居住在营房中，而是在单人或双人牢房里。即使他们聚集在一起 ― 假定，在食堂里 ― 也可以加强其它安全性措施来协助控制人员大量增加带来的风险。
在计算机世界里，要举出糟糕分隔的示例比找出合理分隔容易得多。怎样才能不分隔的经典示例是标准 UNIX 特权模型，其中安全性是关键的操作是以“完全访问或根本不准访问”为基础的。如果您拥有 root 特权，那么您基本上可以执行您想要的任何操作。如果您没有 root 访问权，那么就会受到限制。例如，您在没有 root 访问权时不能绑定到 1024 以下的端口。同样，您不能直接访问许多操作系统资源 ― 例如，您必须通过一个设备驱动程序写磁盘；您不能直接处理它。
通常，如果攻击者利用了您代码中的缓冲区溢出，那人就可以对磁盘进行原始写并胡乱修改内核所在内存中的任何数据。没有保护机制能阻止他这样做。因此，您不能直接支持您本地磁盘上永远不能被擦去的日志文件，这意味着直到攻击者闯入时，您才不能保持精确的审计信息。不管驱动程序对底层设备的访问协调得多么好，攻击者总能够避开您安装的任何驱动程序。
在大多数平台上，您不能只保护操作系统的一部分而不管其它部分。如果一部分不安全，那么整个系统都不安全。有几个操作系统（诸如 Trusted Solaris）确实做了分隔。在这样的情况中，操作系统功能被分解成一组角色。角色映射到系统中需要提供特殊功能的实体上。一个角色可能是 LogWriter 角色，它会映射到需要保存安全日志的任何客户机上。这个角色与一组特权相关联。例如，LogWriter 拥有附加到它自己的日志文件的权限，但决不可以从任何日志文件上进行擦除。可能只有一个特殊的实用程序获得对 LogManager 角色的访问，它就拥有对所有日志的完全访问权。标准程序没有对这个角色的访问权。即使您破解了一个程序并在操作系统终止这个程序，您也不能胡乱修改日志文件，除非您碰巧还破解了日志管理程序。这种“可信的”操作系统并不是非常普遍，很大一部分是因为这种功能实现起来很困难。象在操作系统内部处理内存保护这样的问题给我们提出了挑战，这些挑战是有解决方案的，但得出解决的结果并不容易。
分隔的使用必须适度，许多其它原则也是如此。如果您对每一个功能都进行分隔，那么您的系统将很难管理。
下一次
在下一篇文章中，我们将讨论编写安全软件的另外两个原则 ― 简单性和隐私。简单性原则需要的不仅是编写简单代码；为了使安全性问题最小化，程序也应该易于使用。隐私原则指出您应该避免给出不必要的信息，建议有时可以撒撒谎。
参考资料
作者简介  | 
| | Gary
McGraw 是 Cigital（前身为 Reliable Software Technologies）负责企业技术的副总裁，该公司位于美国弗吉尼亚州杜勒斯（Dulles）。他从事咨询服务和研究工作，帮助决定技术研究和开发方向。McGraw 在 Cigital 从一个研究科学家做起，从事软件工程和计算机安全性方面的研究。他拥有印第安那大学认知科学和计算机科学双博士学位，弗吉尼亚大学的哲学学士学位。他为技术刊物撰写了 40 余篇经同行审查的文章，担任过主要的电子贸易供应商（包括 Visa 和 Federal Reserve）的顾问职务，并在空军研究实验室、DARPA、国家科学基金会以及 NIST 的高级技术项目赞助下担任首席调研员。可以通过
gem@cigital.com和他联系。
|
| 
| |
John
Viega 是一名高级副研究员，Software Security Group 的共同创始人，并担任 Cigital 的资深顾问。他是 DARPA 赞助的开发标准编程语言安全性扩展的首席调研员。John 已撰写了 30 余篇涉及软件安全性和测试领域的技术性文章。他负责在主要网络和电子贸易产品中查找一些众所周知的安全性弱点，包括最近对 Netscape 安全性的攻破。他还是开放源码软件社区的重要成员，编写过 Mailman、即 GNU Mailing List Manager 以及最近发布的 ITS4（一种在 C 和 C++ 代码中查找安全性弱点的工具）。Viega 拥有弗吉尼亚大学的计算机科学硕士学位。可以通过
viega@cigital.com和他联系。
|
对本文的评价
| 
