Update 04.09.2009: относительно пункта 3 данного поста обязательно прочтите обновление информации по нему: Секреты Software Restriction Policies (часть 3) (так же прочитать пункт 3). Т.е. вы должны исключить LNK файлы из проверки политикой и, следовательно, исключения для них создавать не надо.

Так же прочтите обновление по этой же ссылки относительно использования переменных окружения в правилах SRP.

Наблюдая за сообщениями на форумах (а так же по комментариям в моём блоге) пришёл к выводу, что очень немногие понимают всю значимость Software Restriction Policies и далеко не каждый обладает навыками эффективного управления данной политикой. Я уже освещал некоторые вопросы по данной теме, но тем не менее пробелы до сих пор есть, а так же есть новые трюки для обхода политики.

Итак, для тех, кто ещё не в курсе, о чём идёт речь предлагается прочитать:

• На страже безопасности – Software Restriction Policies
• Секреты Software Restriction Policies

В данном посте я планирую раскрыть секреты расширения SCF, трюки с hh.exe, рассмотреть вопросы унификации правил и два важных момента в управлении политикой.

1) Расширение SCF – это командный файл, который обрабатывается стандартным шеллом (он же explorer.exe). Данные файлы достаточно хитры, поскольку проводник (explorer) даже в режиме показа известных расширений никогда не показывает его. Это ещё пол беды. Основная угроза, которая может от них исходить – встраиваемость в файлы. В двух словах это выглядит как прописывание своего кода в любой файл (будь то текстовый, графический, медиафайл и т.д.), подмена расширения и иконки. Синтаксис SCF файлов очень похож на синтаксис INI и INF файлов. Т.е. он состоит из секций, заключённых в квадратные скобки и элементы секций:

[section]
parameter=value
[section2]
parameter2=value2
parameter3=value3

Самый знакомый нам файл такого типа – Show Desktop в панели quick launch. Это самый настоящий SCF файл, который имеет следующее содержание:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=ToggleDesktop

как видно отсюда, мы можем изменять иконку файла на любую. Очень полезно для маскировки файла под другой тип файла. И в секции TaskBar мы видим вызов внутренней команды explorer.exe – ToggleDesktop. Напомню, что эти файлы обрабатываются только оболочкой explorer.exe. Если сохранить эту часть в текстовом файле и указать расширение SCF, то вы получите сворачивалку окон. Если, к примеру, в секции Command указать другую команду, например, Explorer, то при двойном клике на него запустится сам explorer.exe:

[shell]
Command=2
IconFile=explorer.exe,3
[TaskBar]
Command=Explorer

А теперь как встраивать код в другие файлы. Берём любой произвольный файл, например картинку в формате JPEG, открываем его в текстовом редакторе, но лушче будет в FAR и в самое начало или самый конец файла пишем:

[shell]
Command=2
IconFile=imageres.dll,66
[TaskBar]
Command=Explorer

сохраняем изменения и переименовываем файл в image.jpeg.scf.В Windows Vista/Windows Server 2008 мы получим файл размером с картинку, подходящее расширение и значок JPEG файла (хвост .scf будет скрыт от нас в любом случае). Если по нему нажать 2 раза, то запустится explorer. Причём никаких ошибок вы не получите, потому что остальное содержимое файла будет проигнорировано и будет выполнена только та часть кода, которую мы добавили. Искать иконки можно различными редакторами ресурсов, как Restorator или ResHacker. Просто в категории Icon или IconGroup выбираете нужный номер иконки и вставляете этот номер в параметр значка. При этом скорее всего потребуется уменьшить это число на единицу, поскольку Explorer будет считать значки с нуля, в то время как редакторы ресурсов считают с единицы. Но это уже детали.

К сожалению я в данный момент не обладаю сведениями о полном функционале файлов SCF, но доподлинно известно, что ими можно манипулировать как оболочкой explorer.exe, так и браузером Internet Explorer. Поэтому я пока не могу сказать на сколько это может быть опасно. Но неадекватное поведение файла при его запуске может доставить массу хлопот как самим пользователям, так и администраторам.

Следовательно имеет смысл при развёртывании политики SRP включить данное расширение в список блокируемых, а значок Show Desktop.scf разрешить по хэшу! Это важно, поскольку разрешение пути позволит пользователю модифицировать файл и исполнить его.

Примечание: в новых версиях Windows начиная от Windows Vista значок ShowDesktop.scf был сменён с SCF файла на Show Desktop.lnk, следовательно для этих версий ОС достаточно будет просто включить данное расширение в список и всё. Хотя SCF файл в Windows Vista будет работать :)

2)hh.exe – исполняемый файл, который обрабатывает фалы справки CHM. CHM – это скомпилированный HTML файл, следовательно может содержать потенциально уязвимый код. Но тут, казалось бы, бояться нечего, поскольку расширение CHM по умолчанию мониторится политикой SRP и его запуск из пользовательского окружения недоступен. Но это не совсем так. В действительности пользователь может обойти ограничение SRP и спокойно запускать любые CHM файлы. Обходится данное ограничение очень просто:

Start –> Run… –> hh.exe path\helpfile.chm

и всё. К сожалению, я не нашёл метода, как гибко бороться с этим, только явно запрещать политикой SRP запуск программы hh.exe. Ещё к бОльшему сожалению блокировать CHM файлы в системах до Windows Vista тяжело, поскольку почти вся справка Windows там написана в CHM. Однако, в Windows Vista и выше встроенная справка уже не базируется на CHM файлах, поэтому в них мы можем со значительно меньшими последствиями просто блокировать hh.exe. Но тут можно упереться в вопрос совместимости сторонних приложений, которые зачастую содержат справку в CHM файлах. Поэтому, я не призываю блокировать hh.exe, но просто исследовать данный вопрос в каждом индивидуальном случае отдельно.

Примечание: на данный момент мне неизвестно о других расширениях, которые подвержены данной проблемы. Я тестировал набор расширений, но добиться подобного результата не удалось. Хочется надеяться, что это единственное такое хитрое расширение :)

3) унификация и стандартизация создания исключений в политику SRP. Прочитав топик на форуме TechNet – сслыка, я в очередной раз пришёл к мнению, что человек первый раз столкнувшись с SRP не обладает навыками эффективного создания исключений. Это и не удивительно вобщем, поэтому я в темах про SRP ставлю перед собой задачу – рассказать про Best Practices для эффективной реализации этой политики.

За время практики я (и не только) смог выработать для себя общий концепт создания исключений, который звучит примерно так: следует предельно максимально использовать переменные окружения и ключи реестра вместо абсолютных путей.

Политика SRP даёт нам широкие возможности для этого, это и использование системных переменных окружений %variable%, но и чтение этих переменных из реестра. Повторюсь, что данная концепция решает несколько задач, как унификация правил для различных платформ и обход локализованных барьеров. В качестве примеров можно привести различия некоторых стандартных путей в ОС Windows XP и Windows Vista.

• Например, профили пользователей раньше хранились в C:\Documents and Settings, а в Vista – C:\Users. Уже здесь мы видим эффект от использования системных переменных окружения как %userprofile%.
• Но если в сети используются и локализованные системы (смешанные), то системные переменные доставят нам хлопот, поскольку придётся часто дублировать исключения пути: %userprofile%\Desktop\*.lnk и %userprofile\Рабочий стол\*.lnk. Это так же существенный барьер, который обойти стандартными переменными окружения практически нерентабельным. И вот здесь мы видим эффект от чтения нужных путей из реестра.

Чтобы администраторам дать хорошую отправную точку, я решил поделиться стандартным набором разрешений, который будет отвечать следующим требованиям:

• пользователи могут запускать исполняемые файлы из системной папки Windows и Program Files
• пользователи могут запускать ярлыки из своего пользовательского Start Menu
• пользователи могут запускать ярлыки из Start Menu общего профиля, который известен как AllUsersProfile
• пользователи могут запускать ярлыки со своего и AllUsers рабочего стола
• пользователи могут запускать ярлыки из своего меню быстрого запуска (Quick Launch)
• пользователи не могут запускать исполняемые файлы из папки спулера и системного Temp.

И вот такой список исключений нам потребуется:

Unrestricted - %systemroot%
Unrestricted - %programfiles%
Unrestricted - %userprofile%\Application Data\Microsoft\Internet Explorer\Quick Launch\*.lnk – (Windows XP/2003 only)
Unrestricted - %HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\AppData%/Microsoft/Internet Explorer/Quick Launch/*.lnk – (Windows Vista/2008 или выше)
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Desktop%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*.lnk
Unrestricted - %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*/*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Administrative Tools%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*.lnk
Unrestricted - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*/*/*.lnk
Dissalowed - %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers%
Dissalowed - %systemroot%\Temp

Здесь хочу сделать несколько комментариев:

• Мы явно запрещаем запуск недозволенных приложений из системных папок, куда пользователи по умолчанию имеют право записи и исполнения. Это C:\Windows\Temp и папка спулера, поскольку они явно разрешаются первым правилом. Следовательно, чтобы предотвратить запуск файлов из этих папок мы явно их запрещаем отдельными правилами.
• я указал 2 пути для QuickLaunch для систем Windows XP и Windows Vista. Это обусловленно тем, что в Windows XP/Windows Server 2003 максимальная длина исключения для пути ограничена 133 знаками и вот такой “финт ушами”, который я привёл для Windows Vista, не проходит. В новых ОС этот недостаток устранён.
• здесь я не привёл явного запрещения для hh.exe, т.к. это стартовый набор правил, которое обеспечивает достаточную совместимость с другими приложениями.
• Мы разрешаем несколько уровней вложения для Start Menu, поскольку всё это меню как правило состоит из 3-х уровней вложения.

Примечание: для бизнес-приложений, которые как правило инсталлируются на отличный от системного том (обычно D:\) и для них рекомендуется делать исключения по хешу, нежели по пути. Это полезно по двум причинам:

• зачастую бизнес-приложения пишутся “быдлокодерами” (простите уж за такую лексику, но это суровая правда), которые требуют разрешения записи пользователям в папку с исполняемым модулем. Спастись от заражения этого модуля пользователями можно только хешем. Это, к сожалению, актуальная проблема, которую нужно решать примерно так: “разработчиков софта, требующего админских привилегий, нужно силой пересаживать на OpenBSD, и не кормить дошираком до тех пор, пока их г***ософт не начнет там работать в ANSi-режиме на библиотеке ncurses” © Amin
• в случае, если случится факт заражения (в данном случае только от лица неосторожного администратора), то высока вероятность, что вирус постарается инфицировать все .exe файлы в системе и по изменившемуся хешу это можно быстро вычислить (приложение больше не запустится) и в кратчайшие сроки вывести поражённую систему из сети для дальнейшего расследования инцидента.

4) обновление ярлыков временного отключения и включения SRP. Я считаю удобным держать на рабочем столе администратора ярлыки, которые запускают REG файлы, которые в свою очередь временно отключают и возвращают политику в исходную позицию. Если для одной рабочей станции – это менее критично, то в условиях домена отключать политику для установки/обновления ПО на уровне GPO – крайне нецелесообразно. Я уже публиковал в своём предыдущем блоге тексты REG файлов, но без учёта папки Temp.

Т.к. мы явно запретили запуск недозволенных расширений из папки C:\Windows\Temp, то даже временная деактивация политики ярлыками не позволит нам сделать некоторые действия, например, установка драйвера или приложения, если установщик сперва распаковывает INF файлы в эту папку, поскольку перевод глобального режима политики в Unrestricted не отменит этот явный запрет. Следовательно мы помимо перевода политики в Unrestricted должны вывести администраторов из под действия политики. Вот REG файлы для временного отключения и включения политики:

SRP_Disable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000
"PolicyScope"=dword:00000001

SRP_Enable.reg

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00000000
"PolicyScope"=dword:00000000

5) обновление политики. В процессе работы с ярлыками обнаружился один неприятный факт: если отключить политику реестром и не включить обратно, то после перезагрузки машины кроме включения политики реестром обратно потребуется выполнить ещё 2 перезагрузки. Как вы, наверное, поняли, эти ключи реестра не изменяют саму политику, а только её поведение. Следовательно пришлось решать вопрос возвращения политики в исходное состояние при перезагрузках при помощи групповых политик. По умолчанию, политики перезаписывают соответствующие ключи реестра только при изменение состояния политики (чего мы ярылками не делаем). Т.к. SRP у нас основывается на реестре (все её правила и настройки хранятся именно в реестре), то нужно задать принудительное переприменение политики при перезагрузках (или периодических обновлений политики в домене). Делается это в Group Policy:

Computer Configuration\Administrative Templates\System\Group Policy\Registry policy processing

и этот элемент необходимо выставить в Enabled внутри поставить галочку в Process even if the Group Policy objects have not changed. В таком случае даже если администратор забудет реестром обратно включить политику SRP, то политика процессинга сама вернёт её в исходное состояние – Disallowed.

-------------------

Сегодня мы рассмотрели очередную партию насущных вопросов по настройке и управлению политикой Software Restriction Policies. Я недеюсь, что этот материал будет полезен как начинающим (тех, кто только начинает работать с политикой SRP) и опытным администраторам, которые уже используют политики SRP в своих сетях.

Как моим читателям известно я недавно репортил баг на connect (подробности здесь - Первые впечатления от PowerShell V2 CTP3) и сегодня получил ответ следующего содержания (если кто-то не может туда попасть):

Software restriction policies intentionally apply to PowerShell scripts now in V2
Posted by Microsoft on 2009.01.05. at 10:49

следовательно это теперь не баг, а фича. Фича by design. Ещё раз ссылка на connect:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=389878&SiteID=99

И в моём предыдущем посте по этой проблеме временный workaround следует считать постоянным. Я сильно надеюсь, что к релизу подготовят документацию по этому вопросу. И мне до сих пор не ясно, будут ли сделаны какие-то изменения в самой политике SRP (ведь блокируемого расширения .ps1 в списке политики SRP нету). Я считаю, что они должны произведены, чтобы не было никаких неизвестностей при настройке политики. Как это будет реализовано - время покажет. Но для тех, кто планирует использовать PowerShell V2 и Software Restriction Policies будет полезно это знать. Неприятно, конечно же, но что поделать.

Как и ожидалось - негативные. Я не знаю почему, но я настолько привык к версии 1.0, что V2 уже стал отвергать на подсознательном уровне, отрицая все потенциальные преимущества V2. Да, в 1.0 много чего не было сделано, приходилось конструировать собственные костыли, чтобы получить нужный результат, но 1.0 казался как-то роднее и приятней. Я тянул до последнего и вчера совершил героическое обновление PowerShell 1.0 до V2 CTP3. При этом следовал чётким инструкциям ReleaseNotes - корректно деинсталлировал версию 1.0 и потом установил V2 CTP3. Баг был обнаружен мною уже при втором запуске консоли или через 1 минуту после установки.

Суть проблемы: на своём ноутбуке с Windows Vista SP1 я использую Software Restriction Policies и действие по умолчанию Disallowed. Для необходимых путей добавлены исключения с действием Unrestricted и из стандартного набора удалёно расширение .chm и всё. А к чему я это всё? Вот мой второй запуск консоли PowerShell V2 CTP3 (после возвращения политики SRP в исходное состояние):

Windows PowerShell V2 (Community Technology Preview - Features Subject to Change)
Copyright (C) 2008 Microsoft Corporation. All rights reserved.

File D:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 cannot be loaded because its executi
on is blocked by software restriction policies. For more information, contact your system administrator.
At line:1 char:2
+ . <<<<  'D:\Users\vpodans\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1'
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\Users\vPodans> Get-ExecutionPolicy
RemoteSigned
PS C:\Users\vPodans>

С dot sourced скриптами дела обстояли так же:

PS C:\Users\vPodans> "Get-Date" | Set-Content -Path .\date.ps1
PS C:\Users\vPodans> Get-Content .\date.ps1
Get-Date
PS C:\Users\vPodans> . .\date.ps1
File C:\Users\vPodans\date.ps1 cannot be loaded because its execution is blocked by software restriction policies. For
more information, contact your system administrator.
At line:1 char:2
+ . <<<<  .\date.ps1
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

PS C:\Users\vPodans>

Любые попытки исполнения файлов скриптов завершились ничем. Первым делом я проверил настройки политик SRP и убедился, что расширения PS1 нету. Причём все файлы скриптов замечательно открываются по двойному клику в PowerGUI и в системном журнале Application никаких записей об этом не зарегистрировано. Далее я попробовал включить расширенное логирование работы Software Restriction Policies:

reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers" /v LogFileName /d saferlog.txt

и попробовал снова запустить консоль PowerShell. В итоге я получил файл примерно такого содержания:

svchost.exe (PID = 1152) identified C:\Windows\system32\consent.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 856) identified C:\Windows\system32\DllHost.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 856) identified C:\Windows\system32\DllHost.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
svchost.exe (PID = 1152) identified C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe as Unrestricted using path rule, Guid = {191cd7fa-f240-4a17-8986-94d480a6c8ca}
powershell.exe (PID = 2688) identified D:\Users\Administrator\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}

Первой строчкой отображена попытка запуска запуска приложения с повышенными привилегиями. Далее (самая последняя строчка) видно, что файл профиля (Microsoft.PowerShell_profile.ps1) был действительно блокирован политикой. Но на каком основании блокирован и почему нету соответствующей записи в журнале Application мне до сих пор неизвестно. Я так же произвёл аудит доступа к файлу профиля, но там ничего подозрительного не увидел. Вобщем вот такие дела, господа.

Решение: в качестве временного решения в политику SRP было добавлено 2 исключения:

• %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal%WindowsPowerShell/*.ps1
• %HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal%WindowsPowerShell/PowerTab/*.ps1

Для этих двух правил уровень нужно выставить Unrestricted. Ради интереса я попробовал выставить уровень Basic User и что интересно - PS1 файлы так же блокируются, как и при отсутствии этих дополнительных исключений!

Я не знаю, что такого там натворили разработчики PowerShell в CTP3 (я не знаю, была ли такая проблема в более ранних CTP версиях или нет), но мне кажется тут попахивает не просто какой-то ошибкой в коде, а нечто более глобальным, что загрузка PS1 файлов каким-то образом ловится и отшивается политиками Software Restriction Policies. Заодно можно посетовать на практически отсутствующие инструменты отслеживания работы политик SRP :( (расширенное логирование не сильно помогает в этом деле). Если у кого-то есть возможность повторить ситуацию (работа PowerShell V2 CTP3 с работающей политикой SRP), то отпишитесь в комментах о результатах. Если данный баг подтвердится, то не забудьте подтвердить его здесь:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=389878&SiteID=99

SRP или Sotware Restriction Policies - мощный инструмент управления безопасности и контроля запуска приложений в ОС Windows. Политики ограниченного использования программ достаточно просты и состоят из менее, чем 2-х десятков настроек. Но в то же время политика SRP требует очень серьёзного понимания предмета. Я в своё время сделал 2 попытки популяризировать SRP среди администраторов постсоветского пространства как в своём предыдущем блоге, так и в журнале "Системный администратор", где я старался более подробно рассказать про технологию:

• Windows Vista и Software Restriction Policies - обзор нововведений в политики SRP для новых ОС Windows
• На страже безопасности – Software Restriction Policies - вводная статья по описанию политик SRP в журнале Системный Администратор

Однако, к великому сожалению, в журнальной статье был упущен один момент, который обнаружили сегодня на форуме: http://forum.sysfaq.ru/index.php?showtopic=14462

В статье говорится:

Для унификации работы с папками профилей пользователей политика SRP предлагает возможность чтения значений из реестра. Ветка реестра: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\ содержит пути для большинства пользовательских папок профиля. Для указания пути к Start Menu рекомендуется использовать значения реестра для каждой локальной машины. Чтобы использовать значения реестра, его ключ нужно заключить в знаки процента «%», как это показано на примерах:

%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Programs%*.lnk

%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Start Menu%*\*.lnk

Тут всё почти верно, кроме последнего примера. Дело в том, что данный пример не будет работать по одной простой причине:

http://technet.microsoft.com/en-us/library/cc786941.aspx

A registry path rule suffix must not contain a backslash (\) character immediately after the last percent sign (%) in the rule

Тут, конечно же, неточность есть и в статье TechNet'а, поскольку обратный слеш ( \ ) нельзя использовать не только сразу после завершающего ключ реестра знака процента ( % ), но и далее, когда используется дополнительный суффикс. Дополнительный суффикс используется для продолжения пути извлечённого из реестра (об этом прочитаете в статье журнала). К сожалению, нигде в интернете (а так же и в документации TechNet) я не смог найти решения данной проблемы, когда суффикс состоит из 2 и более уровня папок (вида %regkey%folder\subfolder1\subfolder2\etc). Ещё в момент написания статьи для журнала я быстро нашёл решение - если нельзя использовать обратный слеш ( \ ), то почему бы не попробовать использовать прямой слеш ( / )? И попал пальцем в небо. Особого криминала здесь нету, просто при составлении правил политик SRP учтите, что при использовании относительных путей в виде ключей реестра и продолжении пути суффиксами для вложенных папок используйте только прямой слеш - ( / ), тогда всё будет работать прекрасно. Напоминаю, что вы так же можете использовать подстановочные знаки как, например ( * ) Данный момент не был учтён в статье по моей невнимательности.

А теперь поговорим о том, чего я тогда ещё не знал. И, уважаемые администраторы, убедитесь, что ваши пользователи не прочитали материал ниже раньше вас ;)

По умолчанию в Windows XP/Windows Server 2003 установлено 4 исключения для действия по умолчанию:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%*.exe
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%System32\*.exe
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Это исключения для папок Windows и Program Files. Эти правила вполне обоснованы, поскольку обычные пользователи не имеют права записи ни в папку Windows, ни в Program Files. При этом видно, что третье правило использует обратный слеш! По всей видимости разработчики Microsoft сами себя ввели в заблуждение? Вполне возможно. Далее мы видим, что первое правило перекрывает второе и третье! Можно сказать, что эти правила лишние и достаточно первого. Действительно, если взять систему с Windows Vista или Windows Server 2008, то мы увидим только 2 исключения по умолчанию:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

Но на самом деле всё не так и просто. Я бы в жизни не догадался об этом, если бы не Александр Станкевич (MVP Enterprise Security)! Я так и не смог найти внятного объяснения этому факту:

Полагаю, что комментировать тут нечего, на картинке всё и так видно, к чему я клоню ;) Вам мало? Получите ещё:

Вобщем, подумайте, господа администраторы - а вы точно хорошо разобрались в вопросе Software Restriction Policies? У вас ещё есть время подумать, пока ваши пользователи читают эту статью :-D

Примечание: данный пост перепечатан в связи с закрытием бложиков на spaces.live.com, как имеющий какую-то ценность для автора и/или читателей.

Очень часто люди задают вопросы по поводу безопасности своих локальных машин, терминальных серверов и постоянно ищут средство защиты систем от поражения вирусами, троянами и просто контроля запуска узкого числа инсталлированных приложени. И каждый раз снова и снова приходится отвечать тремя словами на этот вопрос, а именно - Software Restriction Policies. Данная политика совмещает себе как простоту реализации, так и эффективность её работы. В критических случаях пользователю разрешено запускать только те приложения, которые явно разрешил запускать администратор. Данная технология не нова, поэтому подробно расписывать её здесь не буду, а лишь обозначу ключевые отличия реализации данной политики в Windows Vista/Windows Server 2008 от реализации в WindowsXP/Windows Server 2003.

Политика включается как обычно: