Дескриптори захисту та керування доступом - це пристрій Windows (гл
Маркери, які ідентифікують посвідчення користувача, є лише частиною висловлювання, що описує захист об'єктів. Інша його частина - інформація про захист, зіставлена з об'єктом і вказує, кому і які дії можна виконувати над об'єктом. Структура даних, що зберігає інформацію, називається дескриптором захисту (security descriptor). Дескриптор захисту включає такі атрибути.
• Номер версії Версія моделі захисту SRM, яка використовується для створення дескриптора.
• Прапори Необов'язкові модифікатори, що визначають поведінку чи характеристики дескриптора. Приклад – прапор SE_DACL_PROTECTED, який забороняє успадкування дескриптором параметрів захисту від іншого об'єкта.
• SID власника Ідентифікатор захисту власника.
• SID групи Ідентифікатор захисту основної групи для цього об'єкта (використовується лише POSIX).
• Список виборчого доступу (DACL) Вказує, хто може отримувати доступ до об'єкта та які види доступу.
• Системний список керування доступом (SACL) Вказує, які операції та яких користувачів повинні реєструватися в журналі аудиту безпеки.
Список керування доступом (access-control list, ACL) складається із заголовка і може містити елементи (access-control entries, АСЕ). Існує два типи ACL: DACL та SACL. B DACL кожен ACE містить SID і маску доступу (а також набір прапорів), причому ACE можуть бути чотирьох типів: доступ дозволений (access allowed), доступ відхилений (access denied), дозволений об'єкт (allowed-object) та «заборонений об'єкт» (denied-object). Як ви, напевно, і подумали, перший тип ACE дозволяє користувачеві доступ до об'єкта, а другий відмовляє у наданні прав, зазначениху масці доступу.
Різниця між ACE типу «дозволений об'єкт» та «доступ дозволено», а також між ACE типу «заборонений об'єкт» та «доступ відхилений» полягає в тому, що ці типи використовуються лише в Active Directory. ACE цих типів мають поле глобально унікального ідентифікатора (globally unique identifier, GUID), яке повідомляє, що даний ACE застосовується лише до певних об'єктів або під об'єктів (з GUID-ідентифікаторами). Крім того, необов'язковий GUID вказує, що тип дочірнього об'єкта успадковує ACE при його (об'єкті) створенні в контейнері Active Directory, до якого застосовано АСЕ. (GUID – це гарантовано унікальний 128-бітний ідентифікатор.)
За рахунок акумуляції прав доступу, зіставлених з індивідуальними АСЕ, формується набір прав, що надаються ACL-списком. Якщо дескриптор захисту не має DACL (DACL = null), будь-який користувач отримує повний доступ до об'єкта. Якщо DACL порожній (тобто в ньому немає АСІ), доступу до об'єкта не отримує ніхто.
АСЕ, що використовуються в DACL, також мають набір прапорів, що контролюють та визначають характеристики АСЕ, пов'язані з успадкуванням. Деякі місця імен об'єктів містять об'єкти-контейнери та об'єкти-листи (leaf objects). Контейнер може включати інші контейнери та листи, які є його дочірніми об'єктами. Приклади контейнерів — каталоги у просторі імен файлової системи та розділи у просторі імен реєстру. Окремі прапори контролюють, як ACE застосовується до дочірніх об'єктів контейнера, зіставленого з цією АСЕ. Частина правил успадкування ACE представлена у таблиці 8–3 (повний список див. у Platform SDK).
SACL складається з ACE двох типів: системного аудиту (system audit ACE) та об'єкта системного аудиту (system audit-object АСЕ). Ці ACE визначають, якіоперації, які виконуються над об'єктами конкретними користувачами чи групами, підлягають аудиту. Інформація аудиту зберігається у системному журналі аудиту. Аудиту можуть підлягати як успішні, і невдалі операції. Як і специфічні для об'єктів ACE з DACL, ACE об'єктів системного аудиту містять GUID, що вказує типи об'єктів або підоб'єктів, до яких застосовується даний АСЕ, і необов'язковий GUID, що контролює передачу ACE дочірнім об'єктам конкретних типів. При SACL, що дорівнює null, аудит об'єкта не ведеться. (Про аудит безпеки ми розповімо пізніше.) Прапори успадкування, застосовні до DACL АСЕ, застосовні до ACE системного аудиту та об'єктів системного аудиту.
Спрощена схема об'єкта "файл" та його DACL представлена на рис. 8–4.
1. Запустіть наладчик ядра.
Дескриптор захисту містить два ACE типу «доступ дозволено», причому один з них вказує обліковий запис адміністратора (її можна розпізнати за RID, що дорівнює 500), а інший - обліковий запис System (яка завжди виглядає як S-l-5-18). Без декодування бітів, встановлених у масках доступу в ACE і визначення того, яким типам доступу до процесів вони відповідають, дуже важко сказати, які права доступу до об'єкта «процес» для Winlogon має кожен з цих облікових записів. Проте, якщо ви зробите це, використовуючи заголовні файли з SDK, виявите, що обидва облікові записи мають повні права доступу.