Longhorn 中的安全性:关注最低特权

 

基思·布朗
DevelopMentor

2004 年 4 月

适用于:
   2003 年专业开发人员大会 (PDC) “Longhorn”预览版

总结: Longhorn 有望成为最低特权应用程序的绝佳平台。 首先,通过编写托管代码开始。 生成桌面应用程序时,请使它们符合 LUA (,并使用 Windows 应用程序验证程序来帮助检查工作) 。 ) (11 个打印页

目录

问题
应用程序和部署清单
LUA:最低特权用户帐户
(已弃用) Power 用户组
AIM:应用程序影响管理
PA:受保护的管理员
Longhorn 上的托管应用程序
“无风险”权限集
工具
总结

长期以来,我一直主张以最少的特权运行。 许多认识我的人都听到过我的咆哮,即开发人员在开发代码时应停止使用管理权限运行,前提是为了鼓励编写更多应用程序以在最低特权环境中运行。 因此,我很高兴在 2003 年 Microsoft 专业开发人员大会 (PDC) ,下一版本的 Windows® 操作系统(代号为“Longhorn”)的main目标之一是让用户更轻松地以最低特权运行。

问题

当你在本地软件商店购买 Microsoft Windows XP® Professional 的副本并将其安装到电脑上时,安装向导会为你和将使用该计算机的任何其他人创建帐户。 Windows XP 启动后,它将显示一个漂亮的欢迎屏幕,显示每个用户的姓名并允许他们登录。 默认情况下,其中每个用户都是计算机的管理员。 为什么? 因为如果不是这样,用户体验会很差。

用户希望能够在其计算机上安装软件,但除非你是管理员,否则你无法安装当前 90% 的软件。 用户希望软件在不崩溃的情况下运行,但除非用户是管理员,否则 70% 的软件将无法正常运行,这是一个乐观的数字。 可悲的是,许多此类应用程序在非管理环境中失败,只是因为它们在保存应用程序状态的位置上做出糟糕的选择。 Program Files 目录不用作存储状态的位置。 它是用于存储程序(可执行文件)的位置。 存储应用程序状态的位置称为 用户配置文件,对于存储共享用户状态,“所有用户”配置文件就足够了。 Windows 徽标计划指南对此进行了解释,但当今绝大多数 Windows 软件的开发都未考虑 Windows 徽标指南。

但是,你可能会问,为什么用户应该以非管理员身份运行,尤其是家庭用户? 嗯,如果它实际上很容易做到,家庭用户将收获大量的好处。 恶意软件 (病毒、蠕虫或其他恶意代码,) 喜欢拥有管理权限。 如今,以管理员身份浏览 Web 或阅读电子邮件是显而易见的危险。 你的孩子呢? 让他们在你的家庭计算机上安装和玩游戏,因为他们知道他们不会意外破坏某些内容、安装间谍软件或删除你强加的内容分级限制,这难道不是很好吗? 请这样思考:以管理员身份运行会有效地关闭 Windows 提供的大多数安全保护。 家庭和企业用户都不应该关闭这些保护,尤其是在连接到互联网时,互联网已经成为一个相当危险的社区。

让用户及其运行的程序在最低特权环境中愉快地运行,将显著提高 Windows 平台的安全性。

应用程序和部署清单

Longhorn 引入的一个重要功能是应用程序和部署清单的概念。 前者允许应用程序开发人员指示其应用程序正常运行所需的权限,后者允许管理员指定他们对应用程序的信任程度。 这些清单远不止于此,但我想指出的是,它们可供托管和非托管应用程序使用,而存在这些清单的一个主要原因是帮助用户以尽可能低的权限运行应用程序。

若要了解有关这些清单的详细信息,请查看 Brent Rector 为 开发人员介绍“Longhorn”一书第 1 章。

LUA:Least-Privilege用户帐户

LUA 或 最低特权用户帐户是一个首字母缩略词,我相信从现在起,你将在 Microsoft 演示文稿中反复出现。 PDC 2003 的主持人经常将首字母缩略词发音为“looah”。这没什么花哨的, 甚至什么新鲜事都没有。 LUA 是指对交互式用户和服务使用非特权用户帐户的做法。

Longhorn 团队希望简化安全性。 他们认为,应该有两个级别的系统访问权限:最低特权和管理。 他们甚至弃用了 Power Users 组, (在 Longhorn 中称为“admin-lite”) 。

随着 Power Users 组的消失,应用程序开发人员确实需要做出选择。 他们需要决定哪两个特权级别 (LUA 或管理) 应用程序对 Longhorn 的需求。 如果应用程序不需要管理权限,则应仔细编写它以在最低特权帐户下工作。 这意味着测试 (,甚至希望使用普通用户帐户) 编写代码。 例如,LUA 应用程序应在安全的位置(如用户配置文件)而不是 Program Files 目录树中写入数据文件。 但是,未针对 Longhorn 重写的应用程序会发生什么情况? 如果即使在 Windows XP 上,这些应用程序也不能在最低特权帐户下正常运行,该怎么办? 名为“应用程序影响管理”的 Longhorn 功能 (AIM) 也许能够帮助这些应用在 LUA 下运行,稍后你将看到。

(已弃用) Power 用户组

如果你认为管理帐户具有“高”访问权限,而普通用户帐户具有“低”访问权限,则可以说 Power User 帐户具有“中等”访问权限。 允许 Power Users 组读取和写入文件系统和注册表的一些部分,这些部分通常对最低特权帐户 (即,不持有特权组中的成员身份的普通用户帐户(如管理员或 Power Users) )。 许多尝试以普通用户身份运行的人发现,许多软件都失败,以至于他们决定将其帐户添加到 Power Users 组,这几乎解决了他们遇到的所有问题。 但他们不再真正以最少的特权运行。 例如,在 Windows XP 上,将允许使用此“中等”权限级别运行的任何恶意软件入侵存储在 Program Files 目录中的其他应用程序,将受信任的 COM 组件替换为特洛伊木马等。 下次用户在此类遭到入侵的计算机上使用她的管理帐户运行时,可以确定恶意软件也会通过以前安装的特洛伊木马运行。 因此,你不会获得以 Power User 身份运行的任何实际保护。

AIM:应用程序影响管理

Longhorn 团队认为,以最少的特权跑步很重要。 他们希望这个漂亮的欢迎屏幕包含主要包含最低特权帐户的用户帐户列表。 但他们也脚踏实地的现实。 正如当今许多主要软件完全忽略 Windows 徽标计划一样,长角时间范围内的许多主要软件也可能忽略 LUA 计划。 未知情的应用程序开发人员将继续编写软件,以便从 Program Files 目录树读取和写入数据文件。 他们还将继续将注册表数据写入HKEY_LOCAL_MACHINE而不是HKEY_CURRENT_USER。 前者是普通用户的写入限制,因此,如果必须使用注册表,则后者更适合用于存储应用程序设置。

当 Windows XP 检测到应用程序需要更多特权 (这种情况很少见,但安装程序) 偶尔会发生时,它会通知非特权用户该应用程序需要管理权限才能运行,从而方便地弹出一个对话框来收集管理员帐户的用户名和密码。 然后,程序在指定的帐户下运行。 但这并不总是起作用,因为许多应用程序不是在一个帐户下安装的,而是在另一个帐户下使用。

Longhorn 采用完全不同的方法。 Longhorn 倾向于在 LUA 下运行应用程序,而不是鼓励用户提升权限以便应用程序能够正常运行。 但是,当应用程序尝试写入HKEY_LOCAL_MACHINE或 Program Files 目录树时会发生什么情况? Longhorn 使用写入时复制策略,为应用程序提供其尝试更改的资源的虚拟化视图。 当应用程序尝试写入 Program Files 目录中的文件时,Longhorn 将为应用程序提供其自己的文件专用副本,并且它可以参与。 这样,在 AIM 方案中松动的任何恶意软件都可能会尝试覆盖 Program Files 目录树下的常用可执行文件,可能WINWORD.EXE。 但它最终将覆盖只有恶意软件才能看到的私人副本。 用户看到的WINWORD.EXE版本仍将是原始的未受排斥的版本。

不要依赖 AIM 来拯救你。 编写应用程序,从第一天起在 LUA 下运行。

PA:受保护的管理员

即使每个应用程序都已在 Longhorn 时间范围内进行修复,以在 LUA 下运行,仍会存在确实需要管理权限的应用程序。 它们包括备份软件、硬盘驱动器碎片整理和重新分区软件、企业管理软件等实用工具,列表还在继续。 因此,在某个时候,用户需要使用管理帐户来完成某些工作。 让我们面对现实,很多人会忽略创建 LUA 帐户的建议,只是始终以管理员身份运行。

Longhorn 团队设计了一个整洁的方案,以帮助保护你在管理帐户下运行时。 这是一项称为 “受保护的管理员”的功能,启用此功能后,始终可以在管理帐户下运行,并且感觉相当安全,因为运行的绝大多数应用程序都将使用特殊的受限令牌运行,该令牌类似于 LUA 方案中的令牌。 只有你已“祝福”或公司已部署并指定为受信任的应用程序才能使用完整的管理令牌运行。 将应用程序指定为受信任应用程序的一种方法是对其部署清单进行签名。 为何此功能会很有用? 让我举一个例子。

通常以管理员身份运行的用户会打开她的 Longhorn 电子邮件客户端并开始浏览电子邮件。 她遇到了一封来自她认识的人的邮件,并打开了一个附件。 她几乎不知道她的朋友最近感染了电子邮件蠕虫,并且此邮件包含恶意软件。 当恶意软件运行时,它会发现它在系统上拥有很少的特权。 它不能修改 Program Files 目录树中的任何内容。 它无法在 HKEY_LOCAL_MACHINE 下更改 COM 对象注册。 这并不是说它不能做任何坏事,但情况比恶意软件发现自己以管理特权运行的情况要好得多。

但等等,我不是说用户在运行电子邮件应用程序时以管理员身份运行吗? 是的,事实就是这样。 但电子邮件应用程序未指定为“幸运的”管理员应用;事实上,它是作为 LUA 应用程序编写的。 因此,它收到了受限令牌,恶意软件也因此收到。 这是最低特权的全部点。 如果失去对系统 (的控制权可能是因为你意外运行了一些恶意软件,或者可能是你刚刚单击了错误的菜单项) ,则损害将受到限制或完全防止。

一些具有安全意识的管理员现在已实施此策略。 我是其中之一。 我有两个帐户,一个普通帐户和一个管理帐户。 我以普通用户身份登录,偶尔会在需要以某种方式管理我的系统时切换到我的管理帐户,例如在我的计算机上添加虚拟目录、在 Microsoft SQL™ Server 中创建数据库等。 (如果你想知道,我最终花费了大约 95% 的时间以普通用户的身份运行,即使开发软件。) Longhorn 团队已经正式化了此方法,这一想法通常称为“在适当时间正确特权”,在受保护的管理员 (PA 中简称) 功能。 这意味着我只能一直以管理员身份运行,但仍以最低特权运行。 不再来回切换、杂耍两个用户配置文件等。

如果这听起来很简洁,并且你希望帮助人们真正使用此功能,那么你需要认真编写以最低特权运行的应用程序。 因为如果启用此功能,即使管理员运行它,需要比实际需要更多的特权的应用程序也会不必要地中断,除非它被指定为受信任的管理员应用程序。 当然,AIM 可能会帮助你,但你不应该依赖它,因为 Microsoft 估计 20% 的应用程序可能无法通过 AIM 实现 LUA 兼容。 如果碰巧跌入此 20%,应用程序将无法运行。 如果发生这种情况,没有人会使用受保护的管理员功能,这确实是一件非常可悲的事情。

随着编写了更多以最低特权运行的应用程序,其他优势也随之而来。 例如,公司最终将能够锁定其工作站,允许员工在最低特权帐户下运行。 这将大大简化管理并降低成本。 现在,编写以最低特权运行的应用程序比以往任何时候都更加重要。 你可以在此平台上有所作为。

Longhorn 上的托管应用程序

来自 PDC 2003 的消息之一是托管应用程序是未来的。 通过编写托管代码,可以利用 Windows 平台上安全性的最新革命:通过代码标识进行安全性。 公共语言运行时提供的基于证据的安全系统 (CLR) ,通常称为 CAS,或“代码访问”安全性,允许 CLR 基于代码来自何处、签名者等对代码施加额外的限制。 这种增加的安全性维度为软件分发开辟了新的途径。 通过在安全沙盒中运行代码,客户端现在可以自信地运行从中央服务器下载的代码,这使得“无需触摸”和“单击一次”部署等功能变得可行,进一步降低了管理成本。 如果部署和安全风险相似,谁不喜欢在计算机上运行的真实 Windows 应用程序而不是基于浏览器的应用程序?

在 Longhorn 中,每个托管应用程序都可以指示它通过应用程序清单运行所需的特定权限。 代码列表 1 显示了生成默认向导生成的“Longhorn 应用程序”项目时生成的示例清单。 请注意 TrustInfo 部分以及其中表示的权限集。 这些是应用程序运行所需的权限。

代码列表 1。 应用程序清单

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 
assembly.adaptive.xsd">
  <assemblyIdentity name="MyLonghornApp" version="1.0.0.0" 
processorArchitecture="x86" asmv2:culture="en-us" 
publicKeyToken="0000000000000000" />
  <entryPoint name="main" xmlns="urn:schemas-microsoft-com:asm.v2" 
dependencyName="MyLonhornApp">
    <commandLine file="MyLonghornApp.exe" parameters="" />
  </entryPoint>
  <description asmv2:iconFile="App.ico" />
  <TrustInfo xmlns="urn:schemas-microsoft-com:asm.v2" 
xmlns:temp="temporary">
    <Security>
      <ApplicationRequestMinimum>
        <PermissionSet class="System.Security.PermissionSet" 
version="1" ID="SeeDefinition">
          <IPermission 
class="System.Security.Permissions.FileDialogPermission" version="1" 
Unrestricted="true" />
          <IPermission class="System.Security.Permissions.IsolatedStorageFilePermission" 
version="1" Allowed="DomainIsolationByUser" UserQuota="5242880" />
          <IPermission 
class="System.Security.Permissions.SecurityPermission" version="1" 
Flags="Execution" />
          <IPermission class="System.Security.Permissions.UIPermission" 
version="1" Window="SafeTopLevelWindows" Clipboard="OwnClipboard" />
          <IPermission 
class="System.Drawing.Printing.PrintingPermission, System.Drawing, 
Version=1.2.3400.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
version="1" Level="SafePrinting" />
          <IPermission class="MSAvalon.Windows.AVTempUIPermission, 
PresentationFramework, Version=6.0.4030.0, Culture=neutral, 
PublicKeyToken=a29c01bbd4e39ac5" version="1" 
NewWindow="LaunchNewWindows" FullScreen="SafeFullScreen" />
        </PermissionSet>
        <DefaultAssemblyRequest PermissionSetReference="SeeDefinition" 
/>
      </ApplicationRequestMinimum>
    </Security>
  </TrustInfo>
  <dependency asmv2:name="MyLonghornApp">
    <dependentAssembly>
      <assemblyIdentity name="MyLonghornApp" version="0.0.0.0" 
processorArchitecture="x86" />
    </dependentAssembly>
    <asmv2:installFrom codebase="MyLonghornApp.exe" 
hash="28c18a303c7fb7e9fe43a32b456f0932f52125a9" hashalg="SHA1" 
size="110592" />
  </dependency>
</assembly>

符合 LUA 的托管应用程序将始终包含这样的部分,Longhorn 中的信任管理器将使用此信息确定是否允许在计算机上安装应用程序。 如果应用程序经过仔细编码,它可能能够以如此低的特权运行,信任管理器可以为其分配“无风险”分数,并且应用程序可以立即安装并运行而无需用户干预。 但是,如果应用程序根据其请求的权限对更危险的风险评级进行评分,则会提示用户显示一个描述应用程序构成的潜在危险的对话框。 然后,用户可以选择是否允许安装和运行应用程序。

在清单中预先说明你的意图是一个好主意,因为如果你不这样做,信任经理只能假设你的应用程序最糟糕,并且向用户表示的风险评级似乎更加险恶。 因此,最好在清单中表达所需的权限。 请勿跳过此步骤。

在 PDC 2003 中提到的一项研究中,Microsoft 发现 40% 的用户在显示 ActiveX 控件下载警告等安全对话框时,始终单击“否”。 很明显,如果要通过 Internet 向用户分发软件,则希望 Longhorn 中信任管理器的风险评级为“无风险”,因此在安装和运行应用程序之前不会提示用户。 因此,你可能想知道是否有一组记录的权限,这些权限将始终被评分为“无风险”。事实证明,存在这样的定义,它被称为 SEE 权限集

“无风险”权限集

你可能听说过在 PDC 2003 中将这称为 SEE (Secure Execution Environment) ,但大多数人认为该术语相当令人困惑,因此我只需将此称为 无风险权限集。 Longhorn 将附带一个特殊权限集,该权限集将始终对 Longhorn 中的默认信任管理器进行“无风险”评分。 如果编写其权限要求完全属于无风险权限集的应用程序,则可以安装和运行该应用程序,而不会显示任何信任警告。 仅在此集中授予权限的代码至少 (,因为它最初由 Microsoft 定义,) 不应有意或意外地损害你的计算机。

因此,如果希望应用程序在安装并运行时,不会显示一个可怕的对话框提示用户,则需要将自己限制为此权限集允许的活动。 你应该知道,Longhorn 团队正在考虑让管理员配置此权限集,因此一个站点上被视为“无风险”的内容在另一个站点上可能有所不同。 但对于绝大多数 Longhorn 安装,无风险权限集将是操作系统附带的默认权限集。

它是什么样子的? 请再次查看代码清单 1 中的清单。 请注意在 TrustInfo 部分“SeeDefinition”中定义的 PermissionSet 的 ID。

以下是 PDC 2003 预览版的无风险权限集的外观:不受限制 的 FileDialogPermission 允许通过标准 OpenFileDialogSaveFileDialog 类读取或写入用户选择的文件,但不允许了解有关用户文件系统结构的任何内容,包括用户选择的文件的名称。 IsolatedStoragePermission 允许程序集在用户的硬盘驱动器上读取和写入最多 5 MB 的用户特定状态,而无需使用文件对话框提示她。 SecurityPermission 允许代码首先执行。 UIPermission 允许你在屏幕上绘图,但只能在自己的窗口中进行绘制,并授予你对剪贴板的有限访问权限, (你无法以编程方式读取其内容,但用户可以从剪贴板粘贴到控件) 。 PrintingPermission 允许打印,但前提是通过打印对话框进行打印。 在用户不知道你正在执行此操作的情况下,代码无法以无提示方式启动打印作业。 “Avalon”特定权限允许代码创建全屏窗口,前提是它们具有由操作系统 (控制的边框,因此你无法欺骗登录屏幕,例如) 。

请记住,此定义几乎肯定会随着时间的推移而变化:它甚至可能在 Longhorn beta 发布之前更改。 所以,把我的描述在这里与一粒盐。 希望本文有助于激励你开始查看.NET Framework中的一些最低特权功能,例如独立存储和常见对话,因为无风险权限集的最终定义很可能要求你使用这些功能来避免信任对话。

定义无风险权限集并不是一项轻而易事的任务。 Longhorn 团队知道,如果定义过于严格,则没有足够的应用程序能够使用它。 但是,如果它太宽松,恶意软件肯定会滥用它。 人们希望球队能找到最甜蜜的地方。 图 1 显示了 Longhorn 应用程序的权限范围的关系图,从一个有福的管理应用程序一直到设计为使用 SEE 权限集运行的应用程序。

Aa480194.leastprivlh01 (en-us,MSDN.10) .gif

图 1. 应用程序的类型

工具

构建最低特权应用程序从未如此简单。 你需要有指南和工具来提供帮助。 我们在 PDC 2003 中看到了这些工具的一些示例,其中第一个示例是 visual Studio® 2005 (PDC 2003 时间范围) 中代号为“Whidbey”。

此新开发环境提供了许多功能,有助于更轻松地面向最低特权环境。 例如,可以选择在调试应用程序时强制实施的权限集。 对于 Longhorn 应用程序,一个很好的起点是 SEE 权限集。 对于现有应用程序,最佳选择是面向 Internet 权限集,这与当前定义 SEE 的方式非常接近。

开始调试的权限降低后,肯定会遇到一些意外 的 SecurityException。 图 2 显示了一个经典示例,其中开发人员使用文件对话框提示用户输入文件名,然后尝试读取给定的文件名。 如果你被授予 FileDialogPermission (,就像你在 SEE 权限集) 中一样,这允许你提示用户输入文件,但明确禁止你查看用户选取的文件名。 相反,您必须调用 OpenFile) (方法,以打开一个流,然后可用于从文件读取。 Visual Studio 2005 提供了建议来帮助开发人员找到正确的方法,以使用 OpenFileDialog 类来避免安全异常。

Aa480194.leastprivlh02 (en-us,MSDN.10) .gif

图 2. 更好的工具支持

PDC 2003 上宣布的另一个有用工具称为 PermCalc。 这是一个命令行工具,用于评估程序集,并通过启发式确定运行所需的权限。 此功能还计划包含在 Visual Studio 2005 中。 这是面向最低特权环境的好方法。 目前存在的类似工具称为 Windows 应用程序验证程序,它是 Windows 应用程序兼容性工具包的一部分。 此工具可以帮助你检测应用程序何时违反规则(例如写入文件系统或注册表的受保护部分)。

总结

Longhorn 有望成为最低特权应用程序的绝佳平台。 首先,通过编写托管代码立即开始。 生成桌面应用程序时,请使它们符合 LUA (,并使用 Windows 应用程序验证程序来帮助检查工作) 。 如果可以,现在以 Internet 权限集为目标,并且当 Longhorn 交付时,你可能会直接进入 SEE。

有关详细信息

阅读布伦特校长的书,为开发人员介绍“Longhorn”。

 

关于作者

Keith Brown 是一位专门从事应用程序安全性的独立顾问。 他于 2000 年) (Addison-Wesley 撰写了《编程Windows 安全》一书,并正在为 .NET 程序员编写一本新的安全书籍。 在 上在线 http://www.develop.com/kbrown阅读新书。