Capability能力令牌是Windows权限体系中一个容易被忽视但非常重要的概念。传统NTFS权限和ACL授权面向的是用户与用户组，而Capability机制面向的是应用本身：一个进程可以在不提升用户权限的前提下，凭借能力声明获得访问特定资源的资格。这种设计在UWP应用、AppContainer沙箱以及部分系统服务中被广泛使用，理解它对排查权限异常、开发低权限应用都有直接帮助。
Capability机制的基本原理与SID结构
Capability的本质是一组特殊的SID（安全标识符），它们以固定的前缀S-1-15-3-开头。Windows安全子系统规定，凡是以该前缀开头的SID都属于Capability SID，会被放进访问令牌的一个单独分组中，称为Capability组。当资源（例如某个文件、注册表项或者设备接口）的DACL中显式授予了某个Capability SID访问权限时，持有该Capability的进程就能通过权限检查，即便它运行在一个几乎没有任何用户权限的沙箱账户下。
这个设计的关键在于“权限跟随应用而非用户”。举个例子：同一台机器上两个用户账号，一个属于管理员组，一个是普通标准用户，只要某个UWP应用声明了网络摄像头能力，并且摄像头设备的DACL里授予了对应Capability SID权限，那么无论哪个用户启动这个应用，都能使用摄像头；反过来，一个没有声明该能力的桌面程序，即使用户是管理员，也可能因为运行在AppContainer中而没有摄像头访问权。
系统内置了大量Capability SID，每个都对应一类资源或服务。可以通过注册表或官方文档查询常见值，例如S-1-15-3-1024-1065315931-516985451-2573627015-1230826417-2816170541-2660673037-938099342对应Internet客户端能力，声明了它的应用才被允许发起出站网络连接。这种粒度远比“用户能否上网”精细得多。
如何查看和分析进程的Capability令牌
排查能力令牌问题最直接的工具是Process Explorer和PowerShell。Process Explorer在进程属性的Security页签中会列出完整的令牌内容，其中Capabilities一栏直接展示该进程持有的能力。如果用命令行，可以借助whoami /user /groups查看当前令牌，或者用脚本调用GetTokenInformation这类API读取其他进程的令牌信息。
下面用一个PowerShell片段演示如何枚举当前进程令牌中的Capability SID：
# 读取当前进程令牌中的Capability分组
# 需要借助P/Invoke或第三方模块，这里用简单方式展示思路
Add-Type @'
using System;
using System.Runtime.InteropServices;
public class TokenHelper {
[DllImport("advapi32.dll", SetLastError=true)]
public static extern bool GetTokenInformation(
IntPtr TokenHandle, int TokenInformationClass,
IntPtr TokenInformation, int TokenInformationLength,
out int ReturnLength);
}
'@
# TokenInformationClass = 30 对应 TokenCapabilityInformation
$length = 0
[TokenHelper]::GetTokenInformation([System.Security.Principal.WindowsIdentity]::GetCurrent().Token, 30, [IntPtr]::Zero, 0, [ref]$length) | Out-Null
Write-Host "Capability信息长度: $length 字节"拿到SID之后，下一步是做反向解析，弄清每个SID对应什么能力。可以在PowerShell中执行$sid = New-Object System.Security.Principal.SecurityIdentifier('S-1-15-3-1024-...')，再调用Translate方法尝试翻译为友好名称。部分Capability SID能翻译出类似APPLICATION PACKAGE AUTHORITY\YourApp这样的名称，翻译失败通常意味着该SID是系统内部能力，需要查文档对照。
另一个实用技巧是用icacls检查资源的DACL。执行icacls "C:\Program Files\WindowsApps\某应用" /t时，输出中出现的S-1-15-3开头的授权项就是Capability授权。如果某个沙箱应用报“拒绝访问”，而它的令牌里根本没有对应的Capability SID，那么问题多半出在应用清单的声明环节，而不是DACL配置。
在实际开发中正确使用Capability声明
对UWP或打包成MSIX的桌面应用来说，能力声明写在应用清单文件的Capabilities节点里。声明什么能力，安装时系统就会在应用的AppContainer SID基础上组合出相应的Capability SID写入令牌。常见的声明包括internetClient、webcam、microphone、picturesLibrary等，每个声明都会在运行时转换为一个具体的SID。
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10">
<Capabilities>
<Capability Name="internetClient"/>
<DeviceCapability Name="webcam"/>
<DeviceCapability Name="microphone"/>
<uap:Capability Name="picturesLibrary"/>
</Capabilities>
</Package>这里有几个容易踩坑的地方。第一，Capability、DeviceCapability和uap:Capability三类节点不能混用，网络能力属于第一类，摄像头等设备能力属于第二类，图片库这类用户资源库能力属于第三类，写错节点清单校验会直接失败。第二，部分受限能力（restricted capability）需要额外审批或企业证书才能使用，例如runFullTrust，普通开发者账号提交商店时会被拒绝。第三，能力声明是“申请”而不是“保证”，最终能否访问还取决于资源的DACL是否授予了对应的Capability SID，系统资源通常已经配好，但自定义资源需要开发者自行设置。
对于运行在完整信任环境下的传统Win32程序，Capability机制同样有用武之地。比如某些服务进程希望以极低权限运行，只保留访问某个特定目录的权利，就可以创建一个AppContainer账户，把该目录的DACL只授予这个容器SID加特定Capability SID，实现比传统低特权账户更窄的攻击面。Windows自带的渲染进程、浏览器沙箱大量采用了这种思路，甚至自定义进程也可以通过CreateAppContainerProfileAPI手动创建容器并附加能力。
Capability模型与传统ACL模型的核心差异
两者的本质区别在于授权的锚点不同。传统ACL回答的问题是“这个用户或组能不能访问”，Capability回答的是“这个应用具备不具备这项能力”。在多用户环境下，传统模型存在天然的矛盾：给普通用户开了权限，所有该用户运行的程序都获得了权限，恶意软件可以搭便车；而Capability模型把权限精确到应用粒度，即便同一个用户，没声明能力的程序也拿不到资源。
从工程角度看，Capability机制还带来了可审计性提升。管理员审计一个应用的能力清单，就能大致判断它的行为边界，商店审核也依赖这份清单做自动化风险评分。反过来，传统桌面程序的行为边界只能靠用户权限推断，粒度粗得多。
当然Capability模型也不是万能的。它的授权体系依赖系统资源预先配置好的Capability ACE，第三方资源、网络共享、老旧设备驱动往往不认识Capability SID，这也是不少UWP应用访问NAS或老打印机失败的根本原因。实际项目中，合理的做法是核心功能走Capability声明，边缘兼容场景考虑FullTrust声明加传统权限控制，两种模型配合使用才能兼顾安全与兼容。
常见故障排查思路汇总
遇到与能力令牌相关的访问拒绝问题时，建议按固定顺序排查：先用Process Explorer确认进程令牌中是否真的包含期望的Capability SID；再用icacls核对目标资源DACL中是否授予了该SID相应权限；最后检查应用清单声明与实际运行包是否一致，尤其是侧载部署时清单被改动的情况。绝大多数“沙箱内拒绝访问”的疑难杂症，都能在这三步中定位到原因。
另外要注意，Capability SID在不同Windows版本间保持稳定，但新增能力的注册表位置和翻译行为可能变化。脚本中不要硬编码SID翻译结果，应动态读取并做好异常处理，这样脚本在升级系统后仍然可靠。掌握这套排查流程后，无论是开发低权限应用还是诊断权限故障，都会事半功倍。
Capability SIDWindows访问令牌UAC虚拟化修改时间：2026-09-11 03:56:38