Windows NT使用两种导致访问尝试失败返回错误5的机制：确认权限和确认特权。权限属于对象上的行为，比如挂起线程权限或读文件权限。权限总是与特定对象和已知用户相关联。例如，读文件权限必须与文件（权限应用在此文件上）和有或没有权限的用户相关联。同样，挂起线程权限除非与特定的线程和用户关联否则没有用。

　　特权是预先定义好的属于系统上操作的权限。例如，特权有调试程序、备份和恢复存储设备以及装入驱动程序。特权以用户为中心，而不是对象。

　　为了使两者之间区分得更清楚，可以看一下实现权限和特权的数据结构：权限在叫作访问控制表（ACL）的数据结构中指定。ACL通常与对象相关。用户用访问令牌表示。当用户试图访问受保护的对象时，其访问令牌与对象的ACL检查。访问令牌包含代表用户的唯一标识符（安全性ID，或SID）。ACL中的每个权限与一个SID相关；这样，安全性子系统就知道了与每个用户相关的权限。

　　另一方面，特权在访问令牌中编码，所以没有相关联的对象。要确定用户是否允许做某个与特权有关的操作，安全性子系统检查访问令牌。

　　此外，权限需要行为的说明（干什么的权限？例如，读文件或者挂起线程），而特权不需要（用户或者有特权，或者没有）。与特权相随的操作隐含在特权本身中。

　　特权在访问令牌中编码的原因是大多数特权不考虑安全性需求。例如，允许备份存储设备的用户必须能够绕过文件安全性。为了允许用户访问而给硬盘上每个单独的文件都加入一个新的ACE是不可行的。这样，备份存储设备的代码首先检查试图备份的用户是否拥有备份特权；如果有，单个文件的安全性就被忽略。

　　能够与访问令牌相关的特权集被牢固加密，不能被应用程序展开。服务器程序能够使用特殊的权限和普通的映射实现自定的安全性规则。

　　有两种类型的ACL：自由决定的(DACL)和系统的(SACL)。DACL管制对象访问，SACL管制审核。

　　控制访问

　　在大多数情况下，错误5是由Windows NT特有的叫作AccessCheck的Win32函数内部产生的。此函数的输入有用户的访问令牌、需要的特权和ACL。ACL主要是小数据结构（叫作访问控制元素，或ACE）的列表，每个数据结构定义一个用户或一组用户、一个权限集合以及允许或拒绝的信息。例如，ACL中可能有一个ACE写着“从纸盒中拿走鸡蛋的权限明确地拒绝给与用户Elephant和Bozo”，后面一个ACE写着“从纸盒中拿走鸡蛋的权限明确地准予给与用户Betty Crocker以及CHEFS组中所有用户”。

　　ACL与对象相关，可以在服务器程序中动态创建。例如，如果一个文件对象与一个ACL相关，不管何时有应用程序试图打开该文件对象，ACL就会被查询以决定是否允许运行应用程序的用户打开文件。

　　AccessCheck函数被许多系统函数内部调用，例如，CreateFile（用户试图在NTFS分区或命名管道上打开文件时）和OpenFileMapping。然而，Win32服务器程序能够直接调用AccessCheck，保护想保护的任何对象。

　　注意安全性API函数只被服务器程序调用；客户不需要或直接使用安全性。客户曾经看到的Windows NT安全性就是错误5。这使得Windows NT安全性可以不必考虑客户运行的软件。需要的是服务器在域的安全性数据库中确认客户以及将从客户收到的请求翻译成服务器端函数调用的能力。此函数或者隐含调用AccessCheck，或者根据服务器端AccessCheck的输出发送或不发送其结果。

　　Windows NT security中容易混淆的部分是对AccessCheck的调用可能是非常模糊的。例如，Windows NT监控设备驱动程序安装的功能是一个非常模糊的概念。当试图添加设备驱动程序时用户要访问哪个“对象”？系统在哪里调用AccessCheck以及必要时在哪里将错误信息显示给用户？

　　在设备驱动程序的例子中，答案还不是太困难：因为设备驱动程序和系统通过注册表（Windows NT通过浏览注册表子树，解释每个条目，尝试执行在单独注册表项中指定的驱动程序二进制文件而装入设备驱动程序）交互，Windows NT保护的对象是注册表项，它在Windows NT中是可以得到的对象。在Win32 API层，任何操作注册表的尝试将会翻译成注册表工作的函数，例如RegOpenKey内部调用AccessCheck。

　　除了注册表保护外，驱动程序二进制文件也有安全性问题。一个因访问注册表被拒绝而落空的黑客仍然能够用添加了额外功能的驱动程序副本取代原有的驱动程序执行文件。这一过程不需要访问注册表，所以Windows NT如何防止这类问题呢？相当简单，通过要求驱动程序二进制文件存放在NTFS

Windows NT安全性API简介(1) 服务器安全配置精华技巧(1)

评论 (0) All