11

如果我的cmd.exe窗口在标题栏中显示“ Administrator”（管理员），表明它是使用提升的特权启动的，那么这是否意味着我从此命令窗口执行的所有操作也都使用提升的特权运行？

具体来说，如果我运行类似的内容：

msiexec SomeProgram.msi

我的安装程序是否以提升的特权运行，因为它是从以提升的特权运行的cmd.exe中执行的？

更具体地说：我想知道是否有应用程序能够msiexec以提升的特权执行用户界面，并立即在cmd.exe窗口中返回提示，就像上面的调用一样。

— 伊恩C.
source

16

是的，它确实以提升的特权执行。

简单测试：

您可以通过打开一个提升的和一个非提升的命令提示符来非常轻松地进行测试。同时运行命令notepad.exe，然后尝试将空白文本文件保存到C:\Windows。一个将保存，一个将引发权限错误。

全面测试：

如果这还不足以为您确认（这确实让我不满意），则可以使用SysInternals的AccessChk。您需要从提升的命令提示符下运行此命令。

让我们首先检查两个正在运行的记事本进程：

记事本：（`accesschk.exe -v -p notepad`）

[11140] notepad.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[11004] notepad.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS

一个运行在我的域用户名下，另一个运行在Administrators内置组下。它也具有很高的强制性水平。您还可以使用该-f标志运行，以细分特权和令牌。

MSIExec和MSI文件

我认为跑步时事情可能会变得有些复杂msiexec。我有一个易于测试的Google Chrome独立安装程序。

msiexec.exe从提升的提示符启动Chrome安装程序：

D:\Users\tannerf>accesschk.exe -p msiexec.exe

[10540] msiexec.exe
  RW BUILTIN\Administrators
  RW NT AUTHORITY\SYSTEM

MSI产生的chrome_installer.exe：

D:\Users\tannerf>accesschk.exe -p chrome_installer.exe

[5552] chrome_installer.exe
     NT AUTHORITY\SYSTEM
     OWNER RIGHTS
  RW NT SERVICE\msiserver

不再那么切割和干燥了！看起来chrome_installer.exe进程是通过MSIServer服务运行的。

这使我想知道其他安装程序可能会有什么行为，因此我运行了一个方便的Evernote.msi：

升高msiexec.exe，启动Evernote安装程序：

[6916] msiexec.exe
  High Mandatory Level [No-Write-Up, No-Read-Up]
  RW BUILTIN\Administrators
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4652] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

有趣; 这次有一个msiexec.exe在系统级别下运行。我使用Process Monitor来发现弹出的实际安装窗口来自系统级msiexec进程。取消较高的强制级别也杀死了系统级进程。

非高架msiexec.exe启动Evernote安装程序：

[7472] msiexec.exe
  Medium Mandatory Level [No-Write-Up, No-Read-Up]
  RW DOMAIN\Tannerf
        PROCESS_ALL_ACCESS
  RW NT AUTHORITY\SYSTEM
        PROCESS_ALL_ACCESS
[4404] msiexec.exe
  System Mandatory Level [No-Write-Up, No-Read-Up]
  R  BUILTIN\Administrators
        PROCESS_QUERY_INFORMATION
        PROCESS_QUERY_LIMITED_INFORMATION

看来Evernote可以通过两种方式获得系统级访问权限。双击安装程序将得到相同的结果。

结论：

我认为这很好地证明了除非另有说明，否则进程将继承权限。这不能保证msiexec SomeProgram.msi在所有流程流程中都具有较高的强制性级别；它可以在系统级别或MSIServer下运行。您的里程可能会有所不同，并且看到这些规则似乎“被破坏”的很多情况也不会令我感到惊讶。

— 坦纳·福克纳
source

2

除了经验测试之外，Windows进程还应该继承父进程的权限。

— 鲍勃，

测试的重点。我从以提升的权限启动的cmd.exe进行了尝试，C:\Windows尽管从提升的cmd.exe启动了记事本，但我还是拒绝了尝试将文件保存到的权限。有没有办法打破“应该从父母那里继承”的规则？

— 伊恩·

@IanC。可以以较少的特权运行子进程。我应该把我以前的评论写成“应该默认继承”。我已经修改了答案，以包含该信息。但是，记事本应该具有继承的管理权限。

— 鲍勃，

@IanC。奇怪，它对我有用。您碰巧尝试过accesschk吗？不知道会有什么不同。

— Tanner Faulkner，

11

默认情况下，Windows进程将从父进程继承其安全上下文：

进程的默认安全描述符中的ACL来自创建者的主令牌或模拟令牌。

^{MSDN上的过程安全性和访问权限}

但是，可以使用较少的特权来生成进程：

虽然流程继承了产生它的流程的完整性级别，但是可以在创建流程时自定义完整性级别。除了在用户界面特权隔离技术中定义窗口消息的边界外，Windows Explorer，Internet Explorer，Google Chrome和Adobe Reader等应用程序还使用强制完整性控制来隔离系统中易受攻击对象的文档。

^{有关此其他MSDN页面的强制性完整性控制维基百科，也在此处提到。另一个演示还提到了流程继承。}

但是，我相信cmd.exe将启动具有最大特权继承级别的子进程，如@Tanner的测试和答案所示。

— 鲍勃
source

2

可以通过两种方式取消执行的命令的特权：

runas /trustlevel:0x20000 "msiexec SomeProgram.msi"（运行runas /showtrustlevels以了解这0x20000是默认的用户信任级别-这甚至适用于安装/运行“需要”提升特权的程序-无需以管理员身份运行时实际授予它们。这通过了Tanner的记事本测试），按照此SU答案
psexec -l -d msiexec SomeProgram.msi根据这个SU答案（也许还需要一些“”，我没有对此进行测试，因为runas对我来说足够好用）

— 托比亚斯·基恩泽（Tobias Kienzler）
source

如果Windows cmd.exe以提升的特权运行，那么我在其提示符下执行的任何操作是否也以提升的特权运行？