Согласно сравнительной таблицы с этой страницы, Software Restriction Policies (SRP) не могут быть импортированы или экспортированы, в отличие от того же AppLocker.
Однако настройки SRP хранятся в реестре, поэтому странно, что нельзя было просто экспортировать нужную ветку реестра. Проверим…
1. На компе с Windows 7 настраиваем SRP.
2. После того, как все настроено и проверено на работоспособность, открываем реестр.
3. Нам нужна ветка [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer]
4. Экспортируем ее в файл SRP.reg и переписываем этот файл на компьютер с Windows 10.
5. На компьютере с Windows 10 запускаем под админом консоль и там импортируем этот файл:
reg import "C:\Users\denis\Downloads\SRP.reg" The operation completed successfully.
Настройки SRP, которые должны храниться в реестре импортированы. Но это только часть настроек. Если мы запустим gpedit.msc или secpol.msc на компьютере с Windows 10, то:
1. Политики в оснастке не будут заданы, нужно будет создать первоначальные правила. Если быть точнее, то настройки действующей политики просто не будут видны, т.к. «ключи» не совпадают.
2. Несмотря на пункт (1), политики будут работать. Например невозможно будет запустить файл из НЕРАЗРЕШЕННЫХ папок.
3. Текущий уровень SRP (согласно оснастке secpol) будет установлен в Unrestricted (по умолчанию), при этом пункт (2) будет актуален, т.е. все попытки запустить приложение из НЕРАЗЕШЕННЫХ папок будут заблокированы.
4. Если при этом через оснастку secpol.msc добавить любую из заблокированных папок в список разрешенных, то она все равно будет заблокирована.
Для примера: в пункте 1 мы внесли папку C:\Windows\System32\spool\drivers\color в список запрещенных, после чего экспортировали ветку реестра с этими настройками на другой комп. После того, как там эти политики применились и эта папка оказалась заблокирована, мы ее через оснастку secpol.msc добавляем в список разрешенных, но файлы из нее запустить не получится, т.к. действует импортированная политика у которой другое название:
Запрещающая политика для этого пути — HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\0\Paths\{60cb49c2-bc06-4f64-aaed-f7208a74b2ba}
Разрешающая политика для этого пути — HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{d2c34ab2-529a-46b2-b293-fc853fce72ea}
Ранее я читал, что включение/выключение SRP производится сменой ключа DefaultLevel.
Выключение:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"DefaultLevel"=dword:00040000
Включение так же, но значение DefaultLevel должно быть равно 0.
При проверке этого в Windows 10 данный ключ не срабатывал.
Если рассматривать пример с папкой C:\Windows\System32\spool\drivers\color, то выяснилось следующее…
1. При импортировании настроек с Windows 7 в Windows 10, в реестре для этого правила был создан раздел HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers со следующими ключами:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"authenticodeenabled"=dword:00000000
"DefaultLevel"=dword:00000000
"TransparentEnabled"=dword:00000001
"PolicyScope"=dword:00000000
"ExecutableTypes"=hex(7):57,00,53,00,43,00,00,00,56,00,42,00,00,00,55,00,52,00,\
4c,00,00,00,53,00,48,00,53,00,00,00,53,00,43,00,52,00,00,00,52,00,45,00,47,\
00,00,00,50,00,49,00,46,00,00,00,50,00,43,00,44,00,00,00,4f,00,43,00,58,00,\
00,00,4d,00,53,00,54,00,00,00,4d,00,53,00,50,00,00,00,4d,00,53,00,49,00,00,\
00,4d,00,53,00,43,00,00,00,4d,00,44,00,45,00,00,00,4d,00,44,00,42,00,00,00,\
49,00,53,00,50,00,00,00,49,00,4e,00,53,00,00,00,49,00,4e,00,46,00,00,00,48,\
00,54,00,41,00,00,00,48,00,4c,00,50,00,00,00,45,00,58,00,45,00,00,00,43,00,\
52,00,54,00,00,00,43,00,50,00,4c,00,00,00,43,00,4f,00,4d,00,00,00,43,00,4d,\
00,44,00,00,00,43,00,48,00,4d,00,00,00,42,00,41,00,54,00,00,00,42,00,41,00,\
53,00,00,00,41,00,44,00,50,00,00,00,41,00,44,00,45,00,00,00
Здесь «authenticodeenabled» = 0 означает НЕ использование сертификатов.
«TransparentEnabled» = 1 означает усиление политик (0 — нет усиления, 1 — все файлы, кроме DLL, 2 — все файлы, включая DLL)
«PolicyScope» — применение политик к пользователям (0 — ко всем пользователям, 1 — ко всем, кроме администраторов)
«ExecutableTypes» — типы файлов.
2. При импортировании настроек с Windows 7 в Windows 10, в реестре для этого правила был также создан раздел HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{60cb49c2-bc06-4f64-aaed-f7208a74b2ba} со следующими ключами:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{60cb49c2-bc06-4f64-aaed-f7208a74b2ba}]
"LastModified"=hex(b):f3,22,e0,91,e5,f5,d0,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Windows\\System32\\spool\\drivers\\color"
LastModified — время изменения ключа в миллисекундах
Description — описание правила
SaferFlags — флаги (0x0004000 или 0x0), которые вроде как и не работают, поэтому можно оставить все равным 0.
3. Если я РАЗРЕШАЛ запуск файлов из папки C:\Windows\System32\spool\drivers\color, то для этого правила создавался похожий раздел в реестре, но вместо папки 0 была папка с именем 262144:
В итоге, если вам нужно ОТКЛЮЧИТЬ именно эту политику, то нужно либо удалить ключ из пункта 2, либо перенести его из папки 0 в папку 262144:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{60cb49c2-bc06-4f64-aaed-f7208a74b2ba}]
"LastModified"=hex(b):f3,22,e0,91,e5,f5,d0,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Windows\\System32\\spool\\drivers\\color"
[-HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\0\Paths\{60cb49c2-bc06-4f64-aaed-f7208a74b2ba}]
"LastModified"=hex(b):f3,22,e0,91,e5,f5,d0,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="C:\\Windows\\System32\\spool\\drivers\\color"
После этого политики нужно применить:
C:\Windows\system32>gpupdate /force Updating policy... Computer Policy update has completed successfully. User Policy update has completed successfully.
4. Создав новое правило через secpol.msc, оно появится в списке наряду с другими правилами в разделе реестра, и будут применены его правила. Однако поскольку ключ для разделов Paths уже другой, то создавая или удаляя правило, у которого такой же путь, не получится заменить созданное ранее правило. Оно будет присутствовать в списке и обрабатываться SRP параллельно. Например, если мы создадим разрешающее правило для пути C:\Windows\System32\spool\drivers\color, которое ранее было внесено в список запрещенных, то будут действовать оба правила, но у запрещающего приоритет будет выше, поэтому попытка запустить приложение из папки C:\Windows\System32\spool\drivers\color будет пресечена. Если мы потом удалим через secpol наше правило, то удалится только недавно созданное разрешающее правило, а старое запрещающее правило останется нетронутым (и невидимым для оснастки secpol).
Поскольку импортированные подобным образом правила оснастка secpol их НЕ ВИДИТ, то нужно быть крайне осторожным, чтобы что-то случайно не перепутать, а то потом придется перелопатить весь реестр в поисках запрещающего правила…
При работе с gpedit, политики SRP сохраняются в следующей ветке реестра:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy Objects\{36 chars ID}Machine\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths
или
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SecEdit\Reg Values\MACHINE/Software/Policies/Microsoft/Windows/Safer/CodeIdentifiers/AuthenticodeEnabled
Часть информации на сайте MS.
- Не приходит СМС для авторизации на сайте Госуслуги - 01.11.2024
- VSCode: Найти и удалить элементы xml - 29.10.2024
- WordPress: Ошибка в плагине WpDiscuz - 08.10.2024