Software Restriction Policy на Windows Home

Желание провести эксперимент появилось после успешной эксплуатации Software Restriction Policies на профессиональных редакциях. Хотелось сделать простую и легкую в плане нагрузки на систему защиту для старого ноутбука. Ноутбук, ввиду старости, имеет на борту 512 Мб ОЗУ и мобильный P-III. С такими характеристиками установка современного антивируса превращается в проблему, в то же время принцип SRP - запретить все, кроме явно разрешенного - выглядит многообещающе.

К этому моменту личный опыт использования Software Restriction Policies показал, что в плане защиты эта система действует весьма эффективно. В частности, уже дважды она блокировала пропущенные Касперским вредоносные почтовые вложения. При этом, если не использовать правила сертификатов, практически не нагружает систему. К сожалению, Microsoft не предлагает соответствующую оснастку в домашних редакциях windows.

Идею покрутить реестр подчерпнул у DenTNT.

Для работы требуется иметь в наличии компьютер с версией PRO, на которой можно настроить образцовые политики. Система не важна, в той конфигурации SRP, что использовал я, нет разницы между правилами Win XP, 7 и 10.

На образцовой системе настраиваем правила. Делаем экспорт ветки

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer

Мы хотим выяснить, можно ли будет потом отредактировать этот файл вручную под другие пути и импортировать на машину с домашней Windows.

 

Для начала рассмотрим структуру реестра, отвечающую за конфигурацию Software Restriction Policies, как ее нам описывает Microsoft.  Для упрощения я рассматривал только правила путей. Типичный раздел правила может выглядеть так:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{eb6cbc39-aed1-49df-80c6-78635174a9a7}]

Правила SRP описываются в разделе [HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer]

Ветка CodeIdentifiers содержит несколько ключей.

DefaultLevel, DWORD. Задает уровень по умолчанию: 40000 - неограниченный, 0 - запрещено

ExecutableTypes, REG_MULTI_SZ. Список расширений исполняемых типов файлов в формате Hex(7)

TransparentEnabled, DWORD. Какое использовать усиление политик: 0 - нет усиления, 1 - все файлы, кроме DLL, 2 - все файлы, включая DLL

PolicyScope, DWORD. Область применения политик: (0 - для всех, 1 - исключая администраторов)

AuthenticodeEnabled, DWORD. Применять ли правила сертификатов: 1 - применять, 0 - не применять.

LogFileName, REG_SZ. Путь к файлу логов.

 

Далее идут подразделы 0 и 262144, в которых описываются запрещающие и разрешающие правила соответственно. Структура ключей в них идентична.

Paths. Подраздел, в котором перечислены правила пути. Каждое правило представляет собой ветвь реестра и имеет имя вида {5c03dc31-e128-426e-bad6-9223ee92d0b8}. Имя этой ветки представляет собой уникальный GUID. Его можно задавть вручную, главное - обеспечить уникальность.
 
Каждый путь имеет следующие ключи.

Description, REG_SZ. Текстовое описание правила.

ItemData, REG_SZ (Path entry) или REG_EXPAND_SZ
Данные, описывающие правило. В случае правил пути - это путь к регулируемому ресурсу.
Для путей, задаваемых через реестр, правило кодируется в hex(2) (REG_EXPAND_SZ), для файловых путей - остается как есть, с экранированием обратных слэшей обратными слэшами (REG_SZ)

LastModified, QWORD. Timestamp последней модификации

SaferFlags, DWORD. Всегда 0, не используется

 

Рассмотрим внимательнее параметр ItemData.

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

"ItemData"="C:\\Windows\\WinSxS"

Т.е., с удвоением обратных слэшей.

В случае, если путь указан ключом реестра, например,

%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Printers\DefaultSpoolDirectory%

то в экспортированном файле будет запись вида:

"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,4c,00,4f,00,43,00,41,00,\
  4c,00,5f,00,4d,00,41,00,43,00,48,00,49,00,4e,00,45,00,5c,00,53,00,4f,00,46,\
  00,54,00,57,00,41,00,52,00,45,00,5c,00,4d,00,69,00,63,00,72,00,6f,00,73,00,\
  6f,00,66,00,74,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,20,00,4e,\
  00,54,00,5c,00,43,00,75,00,72,00,72,00,65,00,6e,00,74,00,56,00,65,00,72,00,\
  73,00,69,00,6f,00,6e,00,5c,00,50,00,72,00,69,00,6e,00,74,00,5c,00,50,00,72,\
  00,69,00,6e,00,74,00,65,00,72,00,73,00,5c,00,44,00,65,00,66,00,61,00,75,00,\
  6c,00,74,00,53,00,70,00,6f,00,6f,00,6c,00,44,00,69,00,72,00,65,00,63,00,74,\
  00,6f,00,72,00,79,00,25,00,00,00

Для удобного конветрирования человекопонятной формы в машинную и обратно можно использовать программу OTConvertIt. Я брал ее здесь.

Таким же образом конвертируется список запрещенных типов файлов.

 

Переходим к эксперименту. Допустим, мы настроили запрещающую политику. Импортировали ее в реестр исследуемой машины. Далее я создаю на ней папку test, в ней - файл test.js в который пишется какая-нибудь ерунда, например, alert("!"); (Напомню, по умолчанию расширение js не входит в список контролируемых). Запускаю файл, получаю ошибку обработчика, т.е, политика не сработала, как и ожидалось.

Далее, с помощью OTConverterIT добавляю в список контролируемых расширений JS. Импортирую файл. При запуске скрипт блокируется SRP, перезагрузка при этом не потребовалась.

Теперь создаю по аналогии с другими правило в разрешающей ветке для папки test. GUID генерирую с помощью этого сервиса.

Получается так:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{4422abf6-351e-4e17-ac36-3545decff8be}]
"LastModified"=hex(b):05,c8,38,38,f6,07,d1,01
"Description"=""
"SaferFlags"=dword:00000000
"ItemData"="D:\\test"

Импортирую правило. Запускаю файл, получаю ошибку интерпретатора ,т.е., разрешение действует.

Т.о., простым редактированием образцового reg-файла и последующим импортом его в реестр целевой машины можно использовать Software Restriction Policies в том числе и на домашних редакциях.

Примечания.

1. В 64-bit версиях копию ветки политик можно найти в

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\Safer

Она должна также быть отредактирована, чтобы контролировать и 32, и 64-разрядное ПО.