Windows UAC 技术详解

UAC 的核心组件

应用程序适配策略

作用

UAC 虚拟化的主要作用是解决标准用户运行旧应用的兼容性问题。当系统管理员不想让用户以管理员身份运行所有程序（出于安全考虑），但许多旧软件默认需要管理员权限时，会产生矛盾。虚拟化技术就是在不修改旧应用的情况下，让它们在标准用户模式下也能运行，大幅减少因为权限不足导致的程序错误。它通过拦截应用对某些受限路径的访问，将操作重定向到用户私有的位置来实现这一目的。

应用场景

典型的适用情形包括：

• 应用尝试在程序安装目录下创建或修改文件。例如早期很多软件会在 C:\Program Files\应用目录\ 下生成日志、INI 配置文件或临时文件。在标准用户环境中，Program Files 目录默认是只读的（普通用户无写权限），直接写入会失败。有了虚拟化，这种写操作会被重定向。
• 应用尝试写入全局注册表（HKEY_LOCAL_MACHINE \Software 等）。标准用户对 HKLM 大部分项也没有写权限，会被拒绝。虚拟化可以将这些写入定向到当前用户的等效位置。
• 应用执行文件操作时假定自己可以修改系统目录（如 Windows 目录）。这在 UAC 下通常不允许，但虚拟化能提供一个替代路径供其写入。

重定向写入路径

当一个启用了虚拟化的进程（32位，无管理员权限，无manifest）尝试创建/修改以下目录的文件时，会被重定向：

• %ProgramFiles% 及其子目录（包括 Program Files (x86)）。
• %ProgramData%（公共应用数据目录）下某些子路径也可能类似处理。
• %SystemRoot%\System32 等Windows系统目录的非关键文件。

重定向的目的地是当前用户的VirtualStore 目录对应位置。例如：

• 写入 C:\Program Files\MyApp\log.txt → 实际写入 C:\Users\<用户>\AppData\Local\VirtualStore\Program Files\MyApp\log.txt
• 写入 C:\Windows\config\settings.dat → 实际写入 C:\Users\<用户>\AppData\Local\VirtualStore\Windows\config\settings.dat

这个 VirtualStore 是每个用户专有的存储空间。第一次重定向发生时，如果目标文件在真实路径存在，系统会将原文件复制一份到 VirtualStore 作为初始内容，然后让应用修改副本。此后应用读该文件就读到副本。若原路径没有文件，则VirtualStore中新建一个，对应用来说就像在真实位置创建了新文件一样。

重定向读取路径

当虚拟化启用的进程读取文件时，系统会优先检查 VirtualStore 中是否有相应的重定向副本。如果存在，就返回该用户副本的内容；如果没有，则再去真实的系统路径读取。这样确保应用在修改文件后后续读到的是自己的修改，而不是原始的全局版本。

虚拟化的限制

限制与注意事项

• 并非HKLM所有键都虚拟化。主要针对软件常用的路径，例如 HKLM\Software\<Vendor>\<App> 这类。某些敏感的系统配置项不会虚拟化（比如HKLM\System等），那些直接就拒绝标准用户访问。
• 注册表虚拟化的限制条件与文件相同：仅32位进程、未提升、无manifest的情况下发生。同时，如果HKLM某键用户连读取权限都没有，也无法虚拟化。
• 和文件一样，manifest存在则关闭，策略中也可整体关闭注册表虚拟化。

示例场景

注册表虚拟化的效果举例：假设某旧应用在启动时写入HKLM\Software\MyApp\Counter 来记录运行次数。在XP上这没问题，但在标准用户环境会被拒绝。有了虚拟化，这个写入就转到用户自己的注册表下。每个用户都有独立的Counter计数，不会碰到访问被拒问题。当然，全局HKLM\Software\MyApp\Counter 实际并未增加，所以管理员查看全局计数还是原来的值。

用户选择

这时标准用户有两个选择：

执行机制

当凭据验证通过后，系统会以提供的管理员账户的身份来执行该操作。例如，标准用户U账号运行一个需要管理员的程序P，提供了管理员账户A的密码，则系统将以A账户权限启动P。这个过程类似"使用另一个身份运行" (Run as different user)，但由UAC界面完成。执行完毕后，程序P就以管理员A身份在用户U的会话中运行，拥有管理员权限。

安全桌面

管理员的同意提示同样默认在安全桌面显示。安全桌面的作用是为了阻隔其他进程的干扰和模拟输入。只有系统进程（如Consent UI）在这个桌面上，所以恶意程序无法发消息给同意对话框点"是"。管理员必须亲自点击。这防止了大部分试图自动提升的攻击（如"Shatter攻击"）。

颜色编码与信任信息

在同意提示窗口中，Windows会根据待提升应用程序的签名和来源，显示不同颜色的边框或标题，以提示安全风险。例如：

自动提升的系统组件

在Windows 7开始，微软为了减少UAC提示次数，对某些系统自带的操作实现了"自动提升"（auto-elevation）。例如，当管理员从控制面板执行某些操作时，如果那个过程被Windows认为安全且必要，可能不会弹出UAC确认而直接执行。

值得注意的是，Windows 7 引入的两个新的UAC模式实际上就是通过改变何时触发提示来实现：

组策略控制

企业环境可以通过组策略精细控制管理员审批模式的行为，包括：

完整性级别分类

当一个进程创建时，系统会为它分配完整性级别。规则基本是：

• 进程完整性 = min(父进程完整性, 可执行文件本身的完整性标记)。举例：如果一个普通中完整性进程启动了一个标记低完整性的可执行，那么新进程会以低完整性运行。反之，如果父进程是低完整性，即使可执行没特别要求，也只能低完整性启动（不会自动高于父）。
• 用户以标准账户登录，其初始shell（如Explorer.exe）为中等完整性。管理员登录，则Explorer运行在中等完整性，但有另一个高完整性的token可用于需要时。高完整性进程只能由UAC确认后显式启动，不会平白出现。
• 系统服务（由Service Control Manager启动，使用系统账号）通常运行在系统完整性。

完整性SID和标签

完整性级别在系统内部通过安全标识符SID来表示，如：

访问控制：No Write Up

完整性级别对安全的影响可以用一句话概括：低完整性主体不能修改高完整性对象。Windows通过在对象的Mandatory Label上设置策略实现这一点。默认情况下，所有对象都应用 SYSTEM_MANDATORY_LABEL_NO_WRITE_UP 策略。

Integrity级别与进程交互

完整性级别和前述的 UIPI 息息相关。实际上，UIPI正是利用完整性级别实现：系统禁止低IL进程向高IL进程发送大多数窗口消息。GUI对象（窗口、消息队列等）也被赋予完整性级别，当低IL试图发送如 WM_SETTEXT 之类会引起代码执行的消息到高IL窗口时，MIC的NoWriteUp同样生效，阻止了该操作。只有少数被允许的消息（如绘制类消息）可以发送，以保证基本兼容性，但这些不威胁安全。

典型的 UAC 绕过案例

防护建议

对于管理员用户来说，一个降低风险的建议是将UAC调到"总是通知"级别。这样关闭了Windows部分autoElevate行为，即使系统自带程序也不绕过UAC。缺点是自己改系统设置也每次弹窗。但安全模式下，这减少了无需用户确认的提权渠道，攻击者不得不面对提示框，增大了被用户察觉的可能性。