五、系统是如何配置ACL的?——默认ACL分析 出于对安全性和易用性平衡的追求,系统分区默认即具备一整套严密的ACL配置。对部分典型默认ACL的分析,既可为我们解决权限相关问题打下基础,又可为我们实现基于权限控制的特殊应用需求提供范例。
C盘根目录 | 所有者:TrustedInstaller | 权限分配 | Administrators组 | 完全控制 | SYSTEM组 | 完全控制 | Users组 | 读取和执行 | Authenticated Users组 | 特殊(应用于“仅子文件夹和文件”的遍历文件夹/执行文件+列出文件夹/读取数据+读取属性+读取扩展属性+创建文件/写入数据+创建文件夹/附加数据+写入属性+写入扩展属性+删除+更改权限 AND 应用于“只有该文件夹”的创建文件夹/附加数据) | | | |
C盘根目录的权限设置典型特征是,未提权的情况下,普通管理员仅可以创建文件夹或删除这些之后被创建的文件夹。提权后,普通管理员可以向C盘根目录写入、更改、删除文件。 在之前的文章中我们已经提到,启用UAC的情景下,非经提权,仅有Administrators组的拒绝权限会应用到普通管理员。这意味着C盘根目录中Administrators的完全控制权限对未经提权的普通管理员的权限分配没有作用。此时一个普通管理员的所拥有的权限实际上是Authenticated Users组与Users组权限的集合。当然,普通管理员可以通过提权而获得Administrators组的完全控制权限。但非经提权的程序将被拒绝向C盘根目录写入文件。
Program Files | 所有者:TrustedInstaller | 权限分配 | SYSTEM组 | 特殊(应用于“只有该文件夹”的遍历文件夹/执行文件+列出文件夹/读取数据+读取属性+读取扩展属性+创建文件/写入数据+创建文件夹/附加数据+写入属性+写入扩展属性+删除+读取权限 AND 应用于“仅子文件夹和文件”的完全控制) | Administrators组 | 特殊(同SYSTEM) | Users组 | 读取和执行 | Creator Owner组 | 特殊(应用于“仅子文件夹和文件”的完全控制) | TrustedInstaller用户 | 特殊(同Creator Owner) | | | |
Program Files是系统默认的程序安装文件夹,它单独设置了ACL而没有继承来自C盘根目录的权限。Program Files的权限设置典型特征与C盘根目录较为相似,但普通管理员除“读取和执行”外的操作都需要提权。
Windows\WinSxS | 所有者:TrustedInstaller | 权限分配 | SYSTEM组 | 读取和执行 | Administrators组 | 读取和执行 | Users组 | 读取和执行 | TrustedInstaller用户 | 完全控制 | | | |
Windows目录作为系统文件夹,重要性不言而喻,其ACL配置也更为复杂,大量使用非继承的权限配置设定对象权限。其中,WinSxS目录是一种典型的高强度权限设置状态。普通管理员不能对当中的文件、文件夹作任何添加、更改、删除,即便提权后也是如此(因为Administrators组也仅拥有“读取和执行”的权限)。
用户\Contoso | 所有者:SYSTEM | 权限分配 | SYSTEM组 | 完全控制 | Administrators组 | 完全控制 | Contoso用户 | 完全控制 | | | |
相对而言,用户文件夹的权限设置要宽松很多。比如在我们这里举例的名为Contoso的用户文件夹中,SYSTEM组、Administrators组与Contoso用户本身都享有对文件夹的完全控制权限。仅有其他用户试图访问此用户文件夹时才会收到权限不足的警告,不过对身为管理员的他们来说,为自己的帐户分配权限并不是什么难事。
从对默认ACL的分析不难看出,我们可以利用启用UAC时非经提权仅有Administrators组的拒绝权限会应用到普通管理员的特性来构建特殊的受保护文件夹。这类文件夹的特征是未经管理员批准(即提权),任何用户、程序不能对该文件夹的内容进行更改。具体的权限配置方法上,即是在用户所普遍隶属的Users组上设置普通权限(如读取和访问),而在Administrators组上设置高权限(如完全控制)。
六、自己动手,解决权限问题 针对NTFS权限相关问题,网络上往往流传着一些“一键取得管理员权限”的基于注册表的简易解决方案。诚然,这类解决方案在一定程度上简化了对NTFS权限相关问题的解决,但其副作用也很明显,如用户无法恢复原文件夹的ACL设置。当用户将这种解决方案应用到系统受保护的区域时,将可能引发安全性问题。事实上手动解决权限问题并不复杂,在解决的过程中,用户也可以更好的理解与应用NTFS权限。
例一:如何暂时性的获取对对象的相应操作权限? 一些时候(如美化),用户可能因为特殊需求而需要更改受保护的系统文件;另一些时候,用户可能需要移除卸载应用程序后的残留文件(如卸载Adobe Reader后其程序目录中所剩下的一些文件)。但当用户遇到权限不足的警告时,应当如何去临时性的获取对对象的相应操作权限呢? 首先,如果并非是要删除对象,那么请记录好原对象的ACL设置情况,如所有者、权限、继承等; 第二,将对象的所有者更改为当前用户,可以根据具体情况考虑是否替换子容器和对象的所有者; 第三,将当前用户添加到ACL中,为其分配适当的权限,可以根据具体情况考虑是否使用可从此对象继承的权限替换所有子对象权限; 第四,进行需要的操作; 第五,如果并非是要删除对象,那么请比照原对象的ACL设置情况恢复对象权限设置,如删除之后添加到ACL中的用户帐户、重新更改对象所有者等。 概而言之,强行设置所有者+为当前用户分配权限后,当前用户即可享有对对象的相应操作权限。
例二:如何去除对象上的小锁? 严格的说这并不是什么大问题,但鉴于经常有朋友提出需要修正这一问题,故而顺带谈一谈。对象上带有小锁图标,代表该对象设定了指定(而非继承)的权限,该权限表明对象在非提权的情况下专属于一个用户帐户。如在简单的通过快捷菜单将对象设置为“不共享”后,系统将为对象分配这样指定的权限。解决方案也很简单,既可以将对象设置为继承父对象权限(包括可从该对象的父项继承的权限),也可以比照同级对象配置对象权限。当然,并非所有具备小锁的对象都需要去修正,如用户文件夹的权限设置就具有指定的用户专属权限,这是由对象的定位决定的。
七、结语 这篇文章,算是我迄今为止构思最久、撰写最久也最为冗长的文章了。想将灵活多变的NTFS权限正确而有意义的表达并不是很容易的事,而我几乎可以肯定文章中存在着某些我暂时无法发现的谬误。我亦不能确定是否每位读者都会将冗长的全文通读(毕竟对用户最有意义的部分仅仅是章节六)。然而写作的过程也是一个自我提高的过程,我亦乐意与读者分享这提高的乐趣。 以上,5000字了吧。 |