Московский физико-технический институт
Опубликован: 12.12.2007 | Доступ: свободный | Студентов: 5590 / 1909 | Оценка: 4.34 / 4.14 | Длительность: 13:57:00
ISBN: 978-5-94774-827-7
Лекция 14:

Структура системы защиты. Привилегии

< Лекция 13 || Лекция 14: 12 || Лекция 15 >
Аннотация: Описана структура менеджера безопасности ОС Windows. Система защиты данных должна удовлетворять требованиям, сформулированным в ряде нормативных документов, которые определяют политику безопасности. Далее в лекции описаны возможности настройки привилегий учетной записи. Поддержка модели ролевого доступа связана с задачами перечисления, добавления и отзыва привилегий пользователя и отключения привилегий в маркере доступа субъекта

Основные компоненты системы безопасности ОС Windows

В данной лекции будут рассмотрены вопросы структуры системы безопасности, особенности ролевого доступа и декларируемая политика безопасности системы.

Система контроля дискреционного доступа - центральная концепция защиты ОС Windows, однако перечень задач, решаемых для обеспечения безопасности, этим не исчерпывается. В данном разделе будут проанализированы структура, политика безопасности и API системы защиты.

Изучение структуры системы защиты помогает понять особенности ее функционирования. Несмотря на слабую документированность ОС Windows по косвенным источникам можно судить об особенностях ее функционирования.

Структура системы безопасности ОС Windows

Рис. 14.1. Структура системы безопасности ОС Windows

Система защиты ОС Windows состоит из следующих компонентов (см. рис. 14.1).

  • Процедура регистрации (Logon Processes), которая обрабатывает запросы пользователей на вход в систему. Она включают в себя начальную интерактивную процедуру, отображающую начальный диалог с пользователем на экране, и удаленные процедуры входа, которые позволяют удаленным пользователям получить доступ с рабочей станции сети к серверным процессам Windows NT. Процесс Winlogon реализован в файле Winlogon.exe и выполняется как процесс пользовательского режима. Стандартная библиотека аутентификации Gina реализована в файле Msgina.dll.
  • Подсистема локальной авторизации (Local Security Authority, LSA), которая гарантирует, что пользователь имеет разрешение на доступ в систему. Этот компонент - центральный для системы защиты Windows NT. Он порождает маркеры доступа, управляет локальной политикой безопасности и предоставляет интерактивным пользователям аутентификационные услуги. LSA также контролирует политику аудита и ведет журнал, в котором сохраняются сообщения, порождаемые диспетчером доступа. Основная часть функциональности реализована в Lsasrv.dll.
  • Менеджер учета (Security Account Manager, SAM), который управляет базой данных учета пользователей. Эта база данных содержит информацию обо всех пользователях и группах пользователей. Данная служба реализована в Samsrv.dll и выполняется в процессе Lsass.
  • Диспетчер доступа (Security Reference Monitor, SRM), проверяющий, имеет ли пользователь право на доступ к объекту и на выполнение тех действий, которые он пытается совершить. Этот компонент обеспечивает легализацию доступа и политику аудита, определяемые LSA. Он предоставляет услуги для программ супервизорного и пользовательского режимов, чтобы гарантировать, что пользователи и процессы, осуществляющие попытки доступа к объекту, имеют необходимые права. Данный компонент также порождает сообщения службы аудита, когда это необходимо. Это компонент исполнительной системы: Ntoskrnl.exe.

Все компоненты активно используют базу данных Lsass, содержащую параметры политики безопасности локальной системы, которая хранится в разделе HKLM\SECURITY реестра.

Как уже говорилось во введении, реализация модели дискреционного контроля доступа связана с наличием в системе одного из ее важнейших компонентов - монитора безопасности. Это особый вид субъекта, который активизируется при каждом доступе и в состоянии отличить легальный доступ от нелегального и не допустить последний. Монитор безопасности входит в состав диспетчера доступа (SRM), который, согласно описанию, обеспечивает также управление ролевым и привилегированным доступом.

Политика безопасности

При оценке степени защищенности операционных систем действует нормативный подход, в соответствии с которым совокупность задач, решаемых системой безопасности, должна удовлетворять определенным требованиям - их перечень определяется общепринятыми стандартами. Система безопасности ОС Windows отвечает требованиям класса C2 "оранжевой" книги [ DoD ] и требованиям стандарта Common Criteria, которые составляют основу политики безопасности системы. Политика безопасности подразумевает ответы на следующие вопросы: какую информацию защищать, какого рода атаки на безопасность системы могут быть предприняты, какие средства использовать для защиты каждого вида информации.

Требования, предъявляемые к системе защиты, таковы

  1. Каждый пользователь должен быть идентифицирован уникальным входным именем и паролем для входа в систему. Доступ к компьютеру предоставляется лишь после аутентификации. Должны быть предприняты меры предосторожности против попытки применения фальшивой программы регистрации (механизм безопасной регистрации).
  2. Система должна быть в состоянии использовать уникальные идентификаторы пользователей, чтобы следить за их действиями (управление избирательным или дискреционным доступом). Владелец ресурса (например, файла) должен иметь возможность контролировать доступ к этому ресурсу.
  3. Управление доверительными отношениями. Необходима поддержка наборов ролей (различных типов учетных записей). Кроме того, в системе должны быть средства для управления привилегированным доступом.
  4. ОС должна защищать объекты от повторного использования. Перед выделением новому пользователю все объекты, включая память и файлы, должны быть проинициализированы.
  5. Системный администратор должен иметь возможность учета всех событий, относящихся к безопасности (аудит безопасности).
  6. Система должна защищать себя от внешнего влияния или навязывания, такого, как модификация загруженной системы или системных файлов, хранимых на диске.

Надо отметить, что, в отличие от большинства операционных систем, ОС Windows была изначально спроектирована с учетом требований безопасности, и это является ее несомненным достоинством. Посмотрим теперь, как в рамках данной архитектуры обеспечивается выполнение требований политики безопасности.

Ролевой доступ. Привилегии

Понятие привилегии

С целью гибкого управления системной безопасностью в ОС Windows реализовано управление доверительными отношениями (trusted facility management), которое требует поддержки набора ролей (различных типов учетных записей) для разных уровней работы в системе. Надо сказать, что эта особенность системы отвечает требованиям защиты уровня B "оранжевой" книги, то есть более жестким требованиям, нежели перечисленные в разделе "Политика безопасности". В системе имеется управление привилегированным доступом, то есть функции администрирования доступны только одной группе учетных записей - Administrators (Администраторы.).

В соответствии со своей ролью каждый пользователь обладает определенными привилегиями и правами на выполнение различных операций в отношении системы в целом, например, право на изменение системного времени или право на создание страничного файла. Аналогичные права в отношении конкретных объектов называются разрешениями. И права, и привилегии назначаются администраторами отдельным пользователям или группам как часть настроек безопасности. Многие системные функции (например, LogonUser и InitiateSystemShutdown ) требуют, чтобы вызывающее приложение обладало соответствующими привилегиями.

Каждая привилегия имеет два текстовых представления: дружественное имя, отображаемое в пользовательском интерфейсе Windows, и программное имя, используемое приложениями, а также Luid - внутренний номер привилегии в конкретной системе. Помимо привилегий в Windows имеются близкие к ним права учетных записей. Привилегии перечислены в файле WinNT.h, а права - в файле NTSecAPI.h из MS Platform SDK. Чаще всего работа с назначением привилегий и прав происходит одинаково, хотя и не всегда. Например, функция LookupPrivelegeDisplayName, преобразующая программное имя в дружественное, работает только с привилегиями.

Ниже приведен перечень программных и отображаемых имен привилегий (права в отношении системы в данном списке отсутствуют) учетной записи группы с административными правами в ОС Windows 2000.

  1. SeBackupPrivilege (Архивирование файлов и каталогов)
  2. SeChangeNotifyPrivilege (Обход перекрестной проверки)
  3. SeCreatePagefilePrivilege (Создание страничного файла)
  4. SeDebugPrivilege (Отладка программ)
  5. SeIncreaseBasePriorityPrivilege (Увеличение приоритета диспетчирования)
  6. SeIncreaseQuotaPrivilege (Увеличение квот)
  7. SeLoadDriverPrivilege (Загрузка и выгрузка драйверов устройств)
  8. SeProfileSingleProcessPrivilege (Профилирование одного процесса)
  9. SeRemoteShutdownPrivilege (Принудительное удаленное завершение)
  10. SeRestorePrivilege (Восстановление файлов и каталогов)
  11. SeSecurityPrivilege (Управление аудитом и журналом безопасности)
  12. SeShutdownPrivilege (Завершение работы системы)
  13. SeSystemEnvironmentPrivilege (Изменение параметров среды оборудования)
  14. SeSystemProfilePrivilege (Профилирование загруженности системы)
  15. SeSystemtimePrivilege (Изменение системного времени)
  16. SeTakeOwnershipPrivilege (Овладение файлами или иными объектами)
  17. SeUndockPrivilege (Извлечение компьютера из стыковочного узла)

Важно, что даже администратор системы по умолчанию обладает далеко не всеми привилегиями. Это связано с принципом предоставления минимума привилегий (см. "Отдельные аспекты безопасности Windows" ). В каждой новой версии ОС Windows, в соответствии с этим принципом, производится ревизия перечня предоставляемых каждой группе пользователей привилегий, и общая тенденция состоит в уменьшении их количества. С другой стороны общее количество привилегий в системе растет, что позволяет проектировать все более гибкие сценарии доступа.

Внутренний номер привилегии используется для специфицирования привилегий, назначаемых субъекту, и однозначно связан с именами привилегии. Например, в файле WinNT.h это выглядит так:

#define SE_SHUTDOWN_NAME            TEXT("SeShutdownPrivilege")
< Лекция 13 || Лекция 14: 12 || Лекция 15 >
Ирина Оленина
Ирина Оленина
Николай Сергеев
Николай Сергеев

Здравствуйте! Интересует следующий момент. Как осуществляется контроль доступа по тому или иному адресу с точки зрения обработки процессом кода процесса. Насколько я понял, есть два способа: задание через атрибуты сегмента (чтение, запись, исполнение), либо через атрибуты PDE/PTE (чтение, запись). Но как следует из многочисленных источников, эти механизмы в ОС Windows почти не задействованы. Там ключевую роль играет менеджер памяти, задающий регионы, назначающий им атрибуты (PAGE_READWRITE, PAGE_READONLY, PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, PAGE_NOACCESS, PAGE_GUARD: их гораздо больше, чем можно было бы задать для сегмента памяти) и контролирующий доступ к этим регионам. Непонятно, на каком этапе может включаться в работу этот менеджер памяти? Поскольку процессор может встретить инструкцию: записать такие данные по такому адресу (даже, если этот адрес относится к региону, выделенному менеджером памяти с атрибутом, например, PAGE_READONLY) и ничего не мешает ему это выполнить. Таким образом, менеджер памяти остается в стороне не участвует в процессе...