• Компоненты Windows Scripting Host, запускающие сценарии, — \Windows\System32\Cscript.exe (для сценариев командной строки), \Windows\ System32\Wscript.exe (для UI-сценариев) и \Windows\System32\Scrobj.dll (для объектов-сценариев) — применяют эти политики к сценариям. Каждый из этих компонентов определяет, действуют ли политики ограничения, по значению параметра реестра HKLM\SOFTWARE\Policies\Micro-soft\Windows\Safer\CodeIdentifiers\TransparentEnabled. Если он равен 1, то политики действуют. Далее каждый из компонентов проверяет, подпадает ли код, который он собирается выполнить, под действие одного из правил, указанных в подразделе раздела CodeIdentifiers, и, если да, следует ли разрешить выполнение. Если ни одно из правил к данному коду не относится, его выполнение зависит от политики по умолчанию, определяемой параметром DefaultLevel в разделе CodeIdentifiers.
Software Restriction Policies — мощное средство для предотвращения запуска неавторизованного кода и сценариев, но только при правильном применении. Если политика по умолчанию не запрещает выполнение, то в образ, который не разрешено запускать в данной системе, можно внести минимальные изменения, и это позволит обойти правило и запустить данный образ.
ЭКСПЕРИМЕНТ: наблюдение за применением политики ограниченного использования программ
Вы можете косвенно убедиться в применении политик ограниченного использования программ, наблюдая за обращениями к реестру при попытке выполнения образа, запуск которого запрещен.
1. Запустите secpol.msc, чтобы открыть редактор локальной политики безопасности, и перейдите в узел Software Restriction Policies (Политики ограниченного использования программ).
2. Выберите Create New Policies (Создать новые политики) из контекстного меню, если такие политики не определены.
3. Создайте правило, запрещающее путь \Windows\System32\Note-pad.exe.
4. Запустите Regmon и установите включающий фильтр для «Safer» (описание Regmon см. в главе 4).
5. Откройте окно командной строки и попробуйте запустить Notepad. Ваша попытка запуска Notepad должна закончиться появлением сообщения о том, что вам запрещен запуск указанной программы, и Regmon должна показать, как командная оболочка (cmd.exe) запрашивает политики ограничения на локальном компьютере.
Windows поддерживает большой набор функций защиты, соответствующий ключевым требованиям как правительственных организаций, так и коммерческих структур. B этой главе мы кратко рассмотрели внутренние компоненты, лежащие в основе функций защиты.
B следующей главе мы обсудим последний из основных компонентов исполнительной системы, описываемых в этой книге, — подсистему ввода-вывода.
ГЛABA 9 Подсистема ввода-вывода
Подсистема ввода-вывода в Microsoft Windows состоит из нескольких компонентов исполнительной системы, которые совместно управляют аппаратными устройствами и предоставляют интерфейсы для обращения к ним системе и приложениям. B этой главе мы сначала перечислим цели разработки подсистемы ввода-вывода, повлиявшие на ее реализацию. Затем мы рассмотрим ее компоненты, в том числе диспетчер ввода-вывода, диспетчер Plug and Play (PnP) и диспетчер электропитания. Далее исследуем структуру подсистемы ввода-вывода и различные типы драйверов устройств. Мы также обсудим основные структуры данных, описывающие устройства, драйверы устройств и запросы на ввод-вывод, а потом перейдем к этапу обработки запросов на ввод-вывод. B завершение будет рассказано о том, как распознаются устройства, как устанавливаются их драйверы и как осуществляется управление электропитанием.
Согласно целям, поставленным при разработке, подсистема ввода-вывода в Windows должна обеспечивать приложениям абстракцию устройств — как аппаратных (физических), так и программных (виртуальных или логических) — и при этом предоставлять следующую функциональность:
• стандартные средства безопасности и именования устройств для защиты разделяемых ресурсов (описание модели защиты см. в главе 8);
• высокопроизводительный асинхронный пакетный ввод-вывод для поддержки масштабируемых приложений;
• сервисы для написания драйверов устройств на высокоуровневом языке и упрощения их переноса между разными аппаратными платформами;
• поддержку многоуровневой модели и расширяемости для добавления драйверов, модифицирующих поведение других драйверов или устройств без внесения изменений в них;
• динамическую загрузку и выгрузку драйверов устройств, чтобы драйверы можно было загружать по требованию и не расходовать системные ресурсы без необходимости;
• поддержку Plug and Play, благодаря которой система находит и устанавливает драйверы для нового оборудования, а затем выделяет им нужные аппаратные ресурсы;
• управление электропитанием, чтобы система и отдельные устройства могли переходить в состояния с низким энергопотреблением;