Как стать автором
Обновить

Комментарии 29

Не могли бы вы пояснить чем именно плохо изменить политику на Unrestricted. Если я могу выполнить скрипт на какой либо машине я могу выполнить и экзешник, подписи для которого не требуются.
Где ошибка в моём рассуждении?
Ошибок нет. Но чертова паранойя. В общем, чем меньше можно, тем больше нельзя. Ваш К.О.
У МС хватает перестраховок, ещё известная гадость — запрет на открытие сертификатов в почтовых вложениях.
Сколько не отправлял, никаких проблем не было. Ни с открытыми сертификатами, ни с закрытыми.
Наверное тем, что даже без администраторского доступа запущенный скрипт имеет очень много вариантов нагадить в системе.
Для выполнения скрипту нужны права администратора?

Для запуска на выполнение — нет. Но для успешного прохождения некоторых инструкций могут понадобиться.
Мне кажется слишком сложное решение получилось. В линуксе на скрипт ушли те же 15 минут с выставлением прав на соответсвующего юзера.

Непонятно, почему нельзя было сделать небольшую утилиту с правами запуска от администратора.
Мне непонятно, как вы измерили время написания скрипта, при условии, что я не указывал, что именно делает скрипт
Ну вы же сами написали:
> Скрипт, решающий задачу, был готов через 15 минут…
Да, конечно, мой скрипт был готов через 15 минут. У него существует определенная задача. А какую задачу решает ваш скрипт, который вы приготовили тоже за 15 минут? Не поймите меня не правильно, просто мне непонятно, какой именно скрипт вы сделали.
Вы таки хотите сказать, что ваш скрипт мог быть реализован только средствами powershell?
Нет, я хочу сказать, что не нужно мериться временем реализации решения, если неизвестно, что требовалось сделать.
И что же нужно было сделать, если не секрет?
по-моему мс перемудрили с этими сертификатами. Защита от выполнения чужого скрипта таки правами решаться должна, а если кто-то похачил систему и получил админа, его уже не остановить.
--sign.vbs--
Set oSigner = WScript.CreateObject("Scripting.Signer")
oSigner.SignFile "D:\MyScripts\MyScript.vbs", "MyCert"

--end--
Вообще, если это standalone машина, то тогда почему бы не сделать политику Unrestricted? Если же машина внутри корпорации, то наверняка в корпорации есть свой доверенный УЦ, там можно получить сертификат по шаблону «Подписывание кода».
В том и дело, взять сертификат изначально было неоткуда, пришлось генерить свой. Только не могу понять, при чем здесь подписывание VB-скриптов?
Да просто, чтоб показать, что тема с подписыванием скриптов не нова, она существует уже какое-то время.
А в вашем скрипте я бы заменил строчку:
$cert = @(Get-ChildItem cert:\CurrentUser\My -codesigning) | Where-Object {$_.Subject -eq "CN=<субъект>"}
У вас же может статься так, что в хранилище тысяча сертификатов, подписывающих код. Зачем нужно брать самый первый, не пойму? Не проще ли обратиться к сертификату по имени? Да и в параметры к скрипту вставить можно.
Да, вы совершенно правы. Первый попавшийся брал, потому что сертификат был на машине единственный, да и задачка достаточно узкая. На новизну темы не претендовал, просто поделился, так сказать, наболевшим. И ваш вариант с подписью, как и следовало ожидать, тоже работает корректно. Интересно только то, что сам текст подписи формируется другой, хоть формат и схож.
Есть еще одна бага, может пригодится, может нет, а может это и фича вовсе… Не знаю, MS мне на их форумах так внятного ответа и не дали. Короче, если групповой политикой на Logon поставить неподписанный повершелл-скрипт — раз, и два — поставить политику запуска хоть даже AllSigned, то Logon-скрипт все равно запустится, он отрабатывает в режиме Undefined. Почему так — никому не известно.
RemoteSigned — компросс между AllSigned и Unrestricted. Тогда подписанными должны быть только скрипты, скачанные из интернета.
Почитать о том, как PowerShell определяет, скачан скрипт или нет, можно в следующей статье: blogs.msdn.com/b/powershell/archive/2007/03/07/how-does-the-remotesigned-execution-policy-work.aspx
Плюсануть, к сожалению, не могу. Спасибо за ценную инфу.
Автор кое-что забыл упомянуть.
Когда я разбирался по данной теме я столкнулся с проблемой в момент подписывания, выдавалось такое:

SignerCertificate Status Path
— — — UnknownError CheckMSE.ps1

Разобравшись в данном вопросе, выяснил, что виновата кодировка скрипта. К сожалению, PowerShell ISE второй версии не позволял менять кодировки, по этому приходилось либо открывать скрипт в Notepad++ и менять кодировку на UTF8, либо с помощью небольшого скриптика:

Get-Content CheckMSE.ps1 | out-file .\CheckNew.ps1 -encoding UTF8
Set-AuthenticodeSignature .\CheckNew.ps1 $cert

И все было ок:

SignerCertificate Status Path
— — — 0990C1A9E09DCE1263DD5F7D7688FFB8E20AD25E Valid CheckNew.ps1

З.Ы. В 3-й версии эту проблему исправили.

Прошу прощения за неудачные вставки из кода
Невнимательно читаете. Не забыл.

Скрипт нужно создавать в любом текстовом редакторе, кроме PowerShell ISE. Для скриптов, созданных внутри этой среды, возникнут проблемы с подписыванием в виде Unknown Error. Решение взято здесь.
Да уж, буду внимательнее, извините.
у меня получилось почему-то так:
cd «C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin\»
.\makecert -n «CN=PowerShell Local Certificate Root» -a sha1 -eku 1.3.6.1.5.5.7.3.3 -r -sv d:\root.pvk d:\root.cer -ss Root
в Вашем случае создание файла ключа идет где-то на диске С, куда запись не оченоь приветствуется, поэтому лучше писать куда-то, к примеру в $Home.
Да, ошибку с PSH ISE подтверждаю.
оказалось просто скопипастить текст скрипта в редактор FAR после чего подпись прошла на ура
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории