首页 > 其他 > 详细

奇特的Local System权限(转载)

时间:2015-02-06 10:49:08      阅读:488      评论:0      收藏:0      [点我收藏+]

转载自:http://mp.weixin.qq.com/s?__biz=MzA3NTM1MzE4Nw==&mid=202597764&idx=1&sn=0cef1a40fb3c82aabd2a41e8e9ee2e67&scene=1&from=groupmessage&isappinstalled=0#rd

 

在Windows 2000/XP下,只有以Local SYSTEM运行的服务,可以选择“允许服务与桌面交互”。这实际上就是让该服务运行在WinSta0窗口站里,而不是运行在默认的Service-0x0-3e7$窗口站里。

 技术分享

但是为什么以其他帐户身份运行服务,不能选择这个选项?甚至连以当前登录帐户身份运行的服务都不行?例如当前以Admin用户帐户身份登录到系统,而系统中存在着一个服务,也以Admin身份运行

 

这里我们可以查看一下WinSta0窗口站的安全权限。可以用Process Explorer,或者调试工具(例如Windbg)进行查看。

 

1. 用Windbg查看WinSta0的ACL

这里首先介绍用Windbg查看WinSta0窗口站的安全权限(更加完整)。由于Windows默认禁用Kernel Debug,所以必须运行以下命令手动打开Kernel Debug选项:

bcdedit -debug on

盆盆评注:注意,如果安装了Demon Tools之类的工具,请不要打开Kernel Debug的选项,以免产生冲突。

下图是利用Windbg所dump出来的WinSta0安全描述符的完整记录:

技术分享

我们主要关心日志中最后三个棕色加粗显示的结果:LocalSystem帐户拥有0x000f037f权限组合;Administrators组帐户拥有0x00020166权限组合;还有一个SACL的ACE为S-1-16-4096。

 

0x000f037f和0x00020166,看上去甚是古怪,但搞开发的兄弟应该很容易理解,这实际上是安全权限的组合掩码。

 

咱IT Pro不需要理解这到底是什么意义,只需要知道0x000f037f代表拥有WinSta0的所有可能权限;而0x00020166代表拥有大多数可能的权限,但是无法读取屏幕内容

 

还有一个SACL的ACE为S-1-16-4096。这又是什么意思?

原来在Windows里,每个安全对象,包括窗口站,都有MIC等级的概念。这里可以看到WinSta0窗口站的MIC等级就是S-1-16-4096,实际上就是Low Integrity Level。

WinSta0窗口站的MIC级别为什么会是低级?这可能是为了方便IE浏览器这样的Low MIC进程也能够读写WinSta0里的内容。

 

integrity 
n. 完整;正直;诚实;廉正

 

2. 用ProcessExplorer查看WinSta0的ACL

用Windbg查看WinSta0的ACL,可以得到比较丰富的信息,但是有一点小缺点,无法查看当前登录帐户的权限(相当于查看无用户登录时的WinSta0的安全权限)。

所以这里借助Process Explorer进行查看。

随便找到一个用户进程,查看其打开的句柄,可以发现其中有\Sessions\1\Windows\WindowStations\WinSta0这样的句柄,查看其安全权限。

可以看到当前登录帐户(本例是Admin)没有访问WinSta0的权限,如附图所示。

技术分享

除了SYSTEM之外,还有一个古怪帐户S-1-5-5-0-148836具有所有可能的权限,如附图所示。

技术分享

S-1-5-5-0-148836实际上就是Admin登录会话的SID。这样的结果非常有趣,WinSta0的权限是授予Admin的一次登录实例(登录会话),而不是Admin这个安全主体本身,很有意义。

其实道理很简单,登录会话是经过LSA验证的一次登录实例,Windows可以信任。而以Admin身份运行的进程,并不一定都是由当前登录用户触发的,还有可能是以Admin身份运行的服务,

从WinSta0的ACL可以看出,这些服务无法访问WinSta0,尽管它们的身份就是登录用户的帐户本身!

 

Process Explorer虽然可以看到完整的安全描述符信息,也可以看到更详细的权限。但是有两个小缺点,一是无法显示WinSta0的MIC级别,而是只显示所谓的常规权限,

而没有显示针对窗口站的特定权限。可能Mark Russinovich还没有来得及更新,抑或这位大牛认为这太简单了,认为大家很容易理解,不想再修改了。

盆盆评注:如何理解登录会话的SID?可以用服务和服务SID的关系进行类比。

 

3. 小结

罗罗嗦嗦说了那么多,结论呢?

实际上很简单,查看WinSta0窗口站发现,只有System和登录会话SID拥有所有的可能权限

所以这就可以解释,为什么在Windows里,只有运行在System权限下的服务才可以选择“允许服务与桌面交互”,因为实在是只有System才有权限访问WinSta0窗口站啊!

 

 

7年写的博客,从权限原理了解只有SYSTEM登录会话这两个账号才有权和当前用户桌面进行交互,才能让用户看到。
而非用户账户本身。而现在的Windows由于session 0隔离,以System身份运行的服务其实已经不能和桌面进行交互。
Hyper-V虚拟机也有点类似服务,有自己的服务SID,老版本的虚拟机在迁移时,甚至需要手动修改资源权限,把该虚拟机的服务SID添加进来,而不是Hyper-V管理员。
 


还有只要不运行在session 0下,system进程还是可以和用户交互的,我们经常用psexec让进程以system身份运行
 
文章非常不错,xp下ice sword 冰刃就是到system级别调整系统配置

盆盆,system 0级的在08R2下,可以建立一个交互哦,我们在调试一些程序时,会到0级的命令行下

@NAV Yeats?是啊,只要不发window message就行。老版本windows还有一些兼容性设置,检测到发window message,会自动切换到session 0的桌面







 
 
 

奇特的Local System权限(转载)

原文:http://www.cnblogs.com/MYSQLZOUQI/p/4276421.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!