Якщо в вікні cmd.exe на панелі заголовка написано "Адміністратор", що вказує на те, що він був запущений з підвищеними привілеями, чи означає це, що я виконую з цього вікна команди, також працює з підвищеними привілеями?

Зокрема, якщо я запускаю щось на кшталт:

msiexec SomeProgram.msi

чи мій інсталятор запускається з підвищеними привілеями, оскільки він виконувався з cmd.exe, який працював з підвищеними привілеями?

Більш конкретно: мені цікаво, чи програми, які представляють інтерфейс користувача та повертають підказку у вікні cmd.exe, як і msiexecвиклик вище, виконують з підвищеними привілеями.

Так, це виконується з підвищеними привілеями.

Простий тест:

Ви можете перевірити це досить легко, відкривши один підвищений та один непідвищений командний рядок. Запустіть команду notepad.exeв обох, і спробуйте зберегти в ньому порожній текстовий файл C:\Windows. Один збереже, хтось викине помилку дозволу.

Ретельний тест:

Якщо цього недостатньо, щоб підтвердити це для вас (це мене не дуже задовольнило), ви можете скористатися AccessChk від SysInternals. Вам потрібно буде запустити це з піднятого командного рядка.

Почнемо з перевірки двох запущених процесів Блокнота:

Блокнот: ( 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

Один працює під іменем мого домену, інший працює під вбудованою групою Адміністратори. Він також має високий обов'язковий рівень . Ви також можете запустити -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

chrome_installer.exe породжений MSI:

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, який цього разу працює на системному рівні. Я використовував Монітор процесів, щоб виявити, що власне вікно встановлення, яке спливе, відбувається від процесу 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. Ваш пробіг може відрізнятися, і я не здивуюсь, коли побачу багато випадків, коли ці правила здаються "порушеними".

За замовчуванням процеси Windows успадкують контекст безпеки від батьківського:

ACL в дескрипторі безпеки за замовчуванням для процесу походить з основного або лексеми іншенсонації творця.

^{MSDN про безпеку процесу та права доступу}

Однак можливо нерестувати процеси з меншими привілеями:

Хоча процеси успадковують рівень цілісності процесу, який його породжував, рівень цілісності може бути налаштований під час створення процесу. Окрім визначення межі для віконних повідомлень за технологією ізоляції привілеїв користувача, обов'язковий контроль цілісності використовується такими програмами, як Windows Explorer, Internet Explorer, Google Chrome та Adobe Reader для ізоляції документів від вразливих об’єктів у системі.

^{Вікіпедія з питань контролю за цілісністю, що стосується цієї іншої сторінки MSDN , також згаданої тут . Ще одна презентація також згадує про спадкування процесу.}

Однак я вважаю, що cmd.exe запустить дочірні процеси з максимально можливим рівнем успадкування привілеїв, як показують тестування та відповіді @ Tanner.

Існує два способи зняти привілеї виконуваної команди:

• runas /trustlevel:0x20000 "msiexec SomeProgram.msi"(запустіть, runas /showtrustlevelsщоб дізнатись, що 0x20000це стандартний користувальницький рівень за замовчуванням - це навіть працює для встановлення / запуску програм, які "вимагають" підвищених привілеїв - без фактичного надання їх при запуску адміністратором. Це проходить тест блокнота Таннера ) відповідно до цього відповіді SU
• psexec -l -d msiexec SomeProgram.msiна цю відповідь SU (можливо, потрібні і деякі "", я не перевіряв це, оскільки runasпрацює для мене досить добре)