Желание провести эксперимент появилось после успешной эксплуатации 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-разрядное ПО.