При разработке PowerShell особое внимание было уделено безопасности. Одной из мер безопасности является наличие политики выполнения (Execution Policy), которая определяет, могут ли скрипты PowerShell выполняться в системе, и если могут, то какие именно.
Для примера возьмем чистую Windows 10, откроем консоль PowerShell и попробуем выполнить простой скрипт. Попытка завершится ошибкой, поскольку, как видно из сообщения, выполнение скриптов в системе запрещено.
Это сработала политика выполнения, и если мы все же хотим выполнить скрипт, то ее необходимо изменить. Выбрать можно одно из следующих значений:
• Restricted — в системе запрещено выполнение любых скриптов, допускается только выполнение отдельных команд. Это политика по умолчанию для клиентских ОС Windows;
• AllSigned — разрешено выполнение только скриптов, имеющих цифровую подпись от доверенного издателя;
• RemoteSigned — для удаленных скриптов требуется наличие цифровой подписи, локальные скрипты выполняются без ограничений. Удаленными считаются скрипты, полученные из удаленных источников (загруженные из интернета, полученные по электронной почте и т.п.), локальными — скрипты, созданные на локальном компьютере. Это политика по умолчанию для серверных ОС Windows;
• Unrestricted — разрешено выполнение любых скриптов, как локальных так и удаленных. При выполнении удаленного скрипта без цифровой подписи будет выдано предупреждение. Это дефолтная и единственно возможная политика для всех ОС, отличных от Windows;
• Bypass — разрешено выполнение любых скриптов, никакие предупреждения и запросы не выводятся;
• Default — сбрасывает политику на значение по умолчанию. Для серверов это RemoteSigned, для клиентов Restricted;
• Undefined — не определено. В случае, если значение политики не определено, то применяется политика Restricted.
Теоретически все понятно, проверим на практике. Для просмотра параметров политики используется командлет Get-ExecutionPolicy, а для изменения Set-ExecutionPolicy.
Для начала выведем действующую политику выполнения командой:
Get-ExecutionPolicy
Как и ожидалось, текущая политика Restricted. Разрешим выполнение скриптов, установив для политики значение Unrestricted:
Set-ExecutionPolicy Unrestricted -Force
И еще попробуем запустить скрипт. На сей раз он выполнился без ошибок.
Политика Unrestricted разрешает выполнение любых скриптов, но у нее все же есть ограничения. Для проверки я подготовил два скрипта, локальный localscript.ps1 и удаленный remotescript.ps1. Сначала запустим локальный, он выполнится без проблем. А вот при запуске удаленного скрипта PowerShell выдаст предупреждение и потребует подтвердить его запуск. При ручном выполнении это не является большой проблемой, а вот в случае автоматического запуска (напр. из планировщика) скрипт может не отработать.
Теперь изменим политику на Bypass и еще раз запустим удаленный скрипт. На сей раз он просто выполнился, безо всяких сообщений и подтверждений. Bypass удобно использовать в ситуациях, когда скрипт должен гарантированно отработать, причем автоматически, без вмешательства пользователя.
Следующим пунктом нашего меню идет политика RemoteSigned. Она является наиболее сбалансированной как с точки зрения безопасности, так и удобства использования, поэтому на серверах включена по умолчанию. Установим для политики значение RemoteSigned и проверим ее действие. Локальный скрипт снова выполняется без проблем, а удаленный выдает ошибку, поскольку у него нет подписи.
У вас может возникнуть вопрос, как именно PowerShell различает локальные и удаленные скрипты. Тут все просто. При загрузке файла приложение (напр. браузер) добавляет файл идентификатор зоны (ZoneId), который и определяет, откуда был взят файл. Идентификатор хранится в альтернативном потоке и имеет значение от 0 до 4:
• Локальный компьютер (0)
• Местная сеть (1)
• Надежные сайты (2)
• Интернет (3)
• Опасные сайты (4)
Если файл имеет ZoneId 3 или 4, то PowerShell считает его удаленным. А если на компьютере включена конфигурация усиленной безопасности Internet Explorer, то файлы, взятые из локальной сети, тоже могут считаться удаленными.
Как выполнить удаленный скрипт? Во первых его можно разблокировать (превратить в локальный), для этого есть специальный командлет Unblock-File. Хотя если просто открыть скрипт на локальном компьютере и внести в него изменения, то он тоже станет локальным.
Ну и во вторых удаленный скрипт можно подписать. Подписывание скриптов — это тема отдельной статьи, поэтому вдаваться в подробности не будем. Просто подпишем его уже имеющимся сертификатом, проверим подпись и выполним. На сей раз успешно.
Переходим к политике AllSigned. Это наиболее жесткая политика, требующая подписывания всех без исключения скриптов, как удаленных так и локальных. И даже с подписанными скриптами она работает не так, как RemoteSigned. Для примера сменим политику на AllSigned и снова запустим подписанный скрипт. В этот раз для его выполнения потребуется подтверждение, т.к. PowerShell посчитал подпись недоверенной.
Области применения
Политика выполнения имеет свою область действия (scope). Всего есть 5 областей:
• LocalMachine — политика действует на всех пользователей данного компьютера. Значение хранится в реестре, в разделе HKEY_LOCAL_MACHINE;
• CurrentUser — политика действует только на текущего пользователя. Хранится в разделе реестра HKEY_CURRENT_USER;
• Process — действие политики распространяется только на текущий сеанс PowerShell. Значение хранится в переменной окружения $PSExecutionPolicyPreference и при закрытии сеанса удаляется;
• Userpolicy — политика действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе пользователя, соответственно политика применяется при входе пользователя в систему;
• MachinePolicy — действует на всех пользователей данного компьютера. Распространяется с помощью групповых политик. Значение хранится в разделе компьютера, политика применяется при загрузке системы;
Вывести значение политики для всех областей можно командой:
Get-ExecutionPolicy -List
Получается, что при установке политики без указания области изменяется значение LocalMachine. Если же требуется указать конкретную область действия, то сделать это можно с помощью параметра Scope командлета Set-ExecutionPolicy. Для примера установим для области СurrentUser политику Bypass:
Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Bypass -Force
Затем проверим значение политики в текущем сеансе и убедимся в том, что оно изменилось на Bypass.
Теперь установим политику Unrestricted для области Process:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force
Еще раз проверим текущую политику, теперь она имеет значение Unrestricted. Т.е. более ″конкретная″ политика всегда имеет больший приоритет.
Для областей UserPolicy и MachinePolicy значение политики задаются через GPO. За настройку отвечает параметр Turn on Script Execution (Включить выполнение сценариев), находящийся в разделе Administrative Templates\Windows Components\Windows PowerShell. Для UserPolicy он находится в конфигурации пользователя (User Configuration), для MachinePolicy — в конфигурации компьютера (Computer Configuration). Политика, применяемая к компьютеру, имеет приоритет перед политикой пользователя.
Для установки политики надо включить параметр и выбрать одно из трех значений:
• Allow only signed scripts (Разрешать только подписанные сценарии) — политика AllSigned;
• Allow local scripts and remote signed scripts (разрешать локальные и удаленные подписанные сценарии) — политика RemoteSigned;
• Allow all scripts (Разрешать все сценарии) — политика Unrestricted.
Политика Bypass считается небезопасной и ее нельзя установить через групповые политики.
Для примера установим для MachinePolicy политику RemoteSigned и проверим результат. Как видите, политика, назначенная через GPO, имеет больший приоритет и переопределяет все остальные политики.
Более того, при использовании GPO становится невозможным переназначить политики вручную. При попытке изменения выдается предупреждение, а текущая политика остается без изменений.
А что будет, если ни для одной области политика не определена, т.е. везде стоит значение Undefined? В этом случае все просто, выполнение всех скриптов запрещается, а текущая политика принимает значение Restricted.
Обход политики
Можно ли как то запустить скрип в обход политики выполнения, не изменяя ее значение? В принципе можно, есть несколько способов.
К примеру для того, чтобы выполнить скрипт, достаточно открыть его в проводнике, кликнуть правой клавишей мыши и выбрать пункт Выполнить с помощью PowewrShell (Run with PowerShell). Это запускает оболочку PowerShell c политикой Bypass. При этом политика применяется только для выполнения конкретного скрипта, значение политики в реестре не изменяется.
Этот способ называется ″Run with PowerShell″ и у него есть некоторые ограничения. Скрипты, запущенные таким образом, не могут взаимодействовать с пользователем (выводить сообщения на экран, требовать ввода данных и т.п.). Скрипт просто запускается, выполняется и немедленно закрывается.
Собственно говоря, предыдущий способ использует запуск PowerShell с указанием требуемой политики. Сделать это можно из командной строки, например для запуска скрипта можно попробовать такую команду:
powershell.exe -file .\script.ps1 -Executionpolicy Bypass
Теоретически эта команда должна выполнить скрипт, не смотря на текущую политику. Так написано в официальной документации Microsoft. На практике же этот способ работает не всегда, например на одном из проверенных мной компьютеров я получил ошибку. При этом из проводника скрипт успешно выполнился.
Еще один вариант — это попробовать изменить политику выполнения для области Process. Эта операция не вносит изменений в реестр и не требует прав администратора. Но в том случае, если для назначения политики выполнения используются групповые политики, этот способ не сработает.
Ну и наконец можно просто считать содержимое скрипта и выполнить его в виде команды. Например так:
$script = Get-Content ./script.ps1
Invoke-Expression -Command ″$script″
Спасибо за статью.
Особое спасибо за «как именно PowerShell различает локальные и удаленные скрипты».
Раньше не попадалось на глаза 🙂