13.3.6. Реалізація дискреційного керування доступом

Ми розглянули суб'єкти та об'єкти доступу, які контролює система керування до­ступом Windows. Далі розглянемо реалізацію цієї системи [91,106-108]. Ключо­ву роль у захисті об'єктів відіграє диспетчер об'єктів. Коли деякий потік на­магається отримати доступ, він запитує визначник об'єкта. Диспетчер об'єктів та SRM, грунтуючись на ідентифікаційних даних процесу, визначають, чи можна на­дати йому визначник, що дозволяє доступ до потрібного об'єкта.

Механізм, який називають уособленням (Impersonation), дає змогу змінити контекст захисту. У випадку уособлення механізми перевірки захисту використо­вують контекст захисту потоку замість контексту захисту процесу, а без уособ­лення ~ контекст захисту процесу, до якого належить потік. Усі потоки одного процесу використовують спільну таблицю визначників> тому, коли потік відкри­ває будь-який об'єкт (навіть під час уособлення), всі потоки цього процесу отри­мують доступ до цього об'єкта.

Методи доступу

Загалом Windows підтримує 22 методи доступу суб'єктів до об'єктів, шість з яких підтримують об'єкти всіх типів:

4 видалення об'єкта;

отримання атрибутів захисту об'єкта;

• зміна атрибутів захисту об'єкта;

• зміна власника об'єкта;

• отримання та зміна параметрів аудита, що стосуються об'єкта (ACCESS_SYS-

TEM_SECURITY);

♦ синхронізація (SYNCHRONIZE).

Згадані методи є стандартними методами доступу. Об'єкти кожного з типів підтримують також специфічні методи доступу (їх може бути 16).

У табл. 13.1 наведено специфічні методи доступу для об'єктів дея­ких типів.

Таблиця 13.1 {закінчення)
Об'єкт доступу	Методи доступу
Диспетчер	Підключення
Сервісів	Отримання статусу списку сервісів Перелік сервісів
	Створення нового сервісу Блокування списку сервісів
Сервіс	Запуск 'Зупинення Призупинення-поновлення Отримання поточного стану Оновлення поточного стану Перелік залежних сервісів Отримання конфігурації Змінсння конфігурації Специфічний для цього сервісу метод доступу
Робочий стіл	Читання елементів робочого столу Змінення елементів робочого столу Створення вікна Створення меню
	Встановлення фільтра (Hook Setting)
	Записування макрокоманди (Journai Recording) Відтворення макрокоманди (Journal Playback)
	Перелік
Віконна станція	Відображення робочого столу на екрані
	Читання вмісту екрана Закриття
	Отримання атрибутів Звернення до буфера обміну (Clipboard) Звернення до таблиці атомів
	Створення нового робочого столу
	Перелік робочх столів
Секція	Перелік самої віконної станції
	Отримання інформації про поточний стан Відображення для читання
	Відображенім для записування Відображення для виконання
	Змінення розміру
Маркер доступу	Читання
	Отримання інформації про підсистему, що створила маркер доступу вмикання-вимикання груп. Вмикання-вимикання привілеїв
	Змінення атрибутів захисту за умовчанням Призначення процесу
	Призначення потоку
	Копіювання
Подія	Отримання стану Змінення стану
Семафор	Отримання стану
М'ютекс	Змінення стану
	Отримання стану Змінення стану

Деякі з методів доступу вимагають від суб'єкта доступу наявності таких спеці­альних привілеїв:

• створення нового сервісу;

• блокування стеку сервісів;

• запуск сервісу;

• зупинення сервісу;

• призупинення/поновлення сервісу;

• призначання процесу маркера доступу;-

• отримання або змінення параметрів аудита, що стосуються об'єкта.

Права доступу

Для кожного специфічного методу доступу, що підтримують об'єкти певного ти­пу, існує право на його здійснення. Такі права називають специфічними. Для кожного стандартного методу доступу, крім ACCESS_SYSTEM_SECURITY, та­кож існує право доступу. Такі права називають стандартними - вони діють для об'єктів усіх типів.

Windows, окрім згаданих, підтримує так звані загальні права доступу (Generic), або відображувані (Mappcd). До них належать:

• читання (GENERIC_READ);

• записування (GENERIC_WRITE);

• виконання (GENERIC_EXECUTE);

• усі дії (GENERIC ALL).

Відображувані права доступу введено, насамперед, для сумісності з програм­ним інтерфейсом POSIX, який підтримує лише визначені для всіх типів об'єктів права достуиу: читання, записування та виконання. Кожне з відображуваних прав доступу e левною комбінацією стандартних і специфічних прав доступу. Відтак відображуване право доступу дає змогу здійснити деякий набір методів доступу до об'єкта. Хоча відображувані права можуть надавати доступ до будь-якого об'єкта, це залежатиме від типу самого об'єкта, оскільки він може мати специфічні права. Процес перетворення відображуваного права доступу на набір стандартних і спе­цифічних прав доступу називають відображенням прав доступу. Порядок від­ображення для об'єктів конкретного типу визначається під час реєстрації цього типу об'єктів,

Як приклад розглянемо відображуване право на читання. Це право дає змогу здійснювати такий доступ до об'єкта типу «файл»: $ читання;

отримання DOS-атрибутів;

♦ отримання розширених атрибутів;

- отримання атрибутів захисту;

- синхронізація.

Водночас до об'єкта типу «ключ реєстру» це право дає змогу здійснювати та­кий доступ:

♦ читання значень;

- перелік підключів;

- вимога сповіщення під час доступу до ключа іншого потоку;

- отримання атрибутів захисту;

- синхронізація.

Ще одним класом прав доступу, які підтримує Windows, є віртуальні права доступу. Віртуальні права доступу можуть бути запитані суб'єктом, але не можуть бути йому надані. Є два віртуальних права доступу:

MAXIMUM_ALLOWED;

ACCESS_SYSTEM_SECURITY.

Якщо суб'єкт запитує віртуальне право MAXIMUM_ALLOWED, він отри­мує доступ до об'єкта за максимальною для цього суб'єкта множиною методів. Тобто, йому надаються всі методи, на які він має права.

Право ACCESS_SYSTEM_SECURITY — це право на здійснення одноймен­ного стандартного методу доступу. Право є віртуальним, тому що насправді мож­ливість доступу суб'єкта за цим методом контролюється відповідним привілеєм суб'єкта, який надає йому право доступу за цим методом до всіх без винятку об'єк­тів доступу. Заборонити чи дозволити доступ за цим методом конкретного суб'єкта до конкретного об'єкта неможливо.

Механізми перевірки прав доступу

Згідно з моделлю захисту Windows потік ще до відкривання об'єкта має вказати, які операції він виконуватиме над цим об'єктом. Система перевіряє методи досту­пу, які запитав потік, і, якщо такий доступ йому дозволено, він отримує визнач­ник, що дає змогу йому (та іншим потокам цього процесу) виконувати операції над об'єктом. Диспетчер об'єктів реєструє права доступу, надані для цього ви­значника, в таблиці визначників, що належить процесу [108].

Одна з подіЙ, що примушує диспетчер об'єктів перевіряти права доступу, — відкривання процесом наявного об'єкта за його іменем. Диспетчер об'єктів шукає його у своєму просторі імен. Якщо об'єкт знайдено, диспетчер об'єктів викликає внутрішню функцію ObpCreateHandle (для цього викликається функція вико­нуючої системи ExCreateHandle). Вона створює елемент у таблиці визначників, якій зіставляється з об'єктом, лише у тому разі, якщо функція диспетчера об'єктів obpIncrementHandleCount повідомить, що потік має право на доступ до цього об'єкта. Ще одна функція диспетчера об'єктів, ObCheckObjectAccess, здійснює перевірку прав доступу. У функцію ObCheckObjeotAcceas передаються атрибути захисту потоку» що відкриває об'єкт, а також тип доступу, що запитується, та покажчик на об'єкт, функція спочатку блокує захист об'єкта та контекст захисту потоку. Блокування захисту об'єкта запобігає Його модифікації іншим потоком під час визначення прав доступу, а блокування контексту захисту потоку не дає іншому потоку того самого або іншого процесу змінити ідентифікаційні дані захисту першого потоку під час перевірки його прав доступу. Далі ObCheckObjectAccess викликає ме­тод захисту об'єкта, щоб отримати його параметри захисту.

Щоразу, коли SRM викликає метод захисту об'єкта, він спочатку перевіряє, чи не використовує об'єкт стандартний захист. Об'єкт зі стандартним захистом зберігає інформацію про захист у своєму заголовку і пропонує метод захисту з іменем SeDefaultObjectMethod. Об'єкт, який не використовує стандартний захист, має сам надавати інформацію про захист і пропонувати власний метод за­хисту. Стандартний захист використовують об'єкти на кшталт м'ютексів, подіЙ і семафорів.

Приклад об'єкта з нестандартним захистом — об'єкттипу «файл>. У диспетчеpa введення-виведення, що визначає об'єкти типу «файл», є драйвер файлової системи, який керує захистом файлів або не реалізовує захист (наприклад, драй­вер файлової системи FAT32). Таким чином, коли система запитує інформацію про захист об'єкта «файл», що є файлом у розділі NTFS, вона отримує цю ін­формацію від драйвера файлової системи NTFS, який, у свою чергу, отримує її від методу захисту об'єкта «файл», що належить диспетчеру введення-виведення. ІІід час відкривання файлу функція ObCheckObjectAccess не виконується, оскільки об'єкти «файл» знаходяться у вторинних просторах імен. Система ви­кликає метод захисту об'єкта «файл» лише за умови, що потік явно запитує чи встановлює параметри захисту файлу (наприклад, через Wm32^ymajjio Set-FileSecurity або GetFileSecurity).

Отримавши інформацію про захист об'єкта, ObCheckObjectAccess викли­кає SRM-функцію SeAccessCheck, яка є базовою функцією моделі захисту Win­dows. Вона приймає параметри захисту об'єкта, ідентифікаційні дані захисту потоку (в тому вигляді, в якому їх було отримано від ObCheckObj ectAceess) і тип доступу, який запитує потік. Функцїя SeAccessCheck повертає значення True або False, залежно від того, чи дозволяє вона потоку доступ того типу, який він запитав.

Інша подія, що змушує диспетчер об'єктів виконати перевірку прав досту­пу, — посилання процесу на об'єкт за наявним визначником. Такі посилання здійснюються, наприклад під час маніпулювання з об'єктом через Win32 АРІ з передаванням його визначника. Нехай потік, що відкриває файл, запитує доступ для читання із файлу. Якщо потік має відповідні права, визначені його контек­стом захисту та параметрами захисту файлу, диспетчер об'єктів створює визнач­ник цього файлу в таблиці визначників, що належить процесу — власнику цього потоку. Інформація про наданий процесу тил доступу зіставляється з визначни­ком і зберігається диспетчером об'єктів. Надалі потік може спробувати записати дані в цей файл через Win32^yHKuiro WriteFile, надавши як параметр визнач­ник файлу. Системний сервіс NtWriteFile, який викличе WriteFile через Ntdil.dll, звернеться до функції диспетчера об'єктів ObReferenceObjectBy^ Handle, щоб отримати посилання на об'єкт «файл» за його визначником. Функ­ція ObReferenceObjectByHandle приймає запитаний тип доступу як параметр.

Знайшовши у таблиці визначників елемент, що відповідає потрібному визначни­ку, ObReferenceObjectByHandle порівняє запитаний тип доступу з тим, що був наданий під час відкривання файлу. В цьому випадку ObReferenceObj ectSyr-Handie повідомить, що операцію запису буде завершено невдало, оскільки потік, відкриваючи файл, не отримав право на записування в нього.

Функції захисту Windows також дають змогу прикладним програмам Win32 визначати власні закриті об'єкти і викликати SRM-сервіси для застосування до цих об'єктів засобів захисту Windows. Багато з функцій режиму ядра, які вико­ристовує диспетчер об'єктів та інші компоненти виконавчої системи для захисту своїх об'єктів, експортуються у вигляді Win32^yHKujft режиму користувача. На­приклад, еквівалентом SeAccessCheck для режиму користувача є Accea&Check. Відтак програми Win32 можуть використовувати модель захисту Windows та ін­тегруватися з інтерфейсами автентнфішіЯ та адміністрування щ&ОС.

Ідентифікатори захисту

Для ідентифікації активних об'єктів (суб'єктів) у системі Windows замість імен (які можуть і не бути унікальними) використовують ідентифікатори захисту (Security Identifiers, SID) [93, 108]. SID мають користувачі, локальні групи та групи домену, а також локальні комп'ютери, домени та члени доменів. SID — це числове значення змінної довжини, що формується з номера версії його структу­ри, 48-бітового коду агента ідентифікатора та змінної кількості 32-бітових кодів субагентів та (або) відносних ідентифікаторів (Relative IDentifiers, RID). Код агента ідентифікатора (Identifier Authority VaIue) визначає агента, що надав SID. Таким агентом зазвичай є локальна система або домен під керуванням Windows. Коди субагентів ідентифікують попечителів, яких уповноважив агент, що видав SID. A RID — не більше як засіб створення унікальних SID на основі спільного базового SID (Common Based SID). Оскільки SID має достатньо велику довжину і Windows намагається генерувати дійсно випадкові значення для кожного SID, імовірність появи двох однакових SID практично дорівнює нулю.

У текстовій формі кожен Sn) починається з префікса S, за яким розташовані групи чисел, розділені дефісами, наприклад:

S-l-5-21-746385570-2913517877-2667279727-1023

У цьому SID номер версії дорівнює 1, код агента ідентифікатора — 5 (для Windows ~ SECURnr_NT_AUTHORITY), далі йдуть коди чотирьох субагентів і один RID наприкінці (1023).

SID призначається комп'ютеру під час інсталяції Wiodows (програмою Win­dows Setup). Потім Windows призначає SID локальним обліковим записам на цьому комп'ютері. SID кожного локального облікового запису формується на ос­нові SID комп'ютера з додаванням RID. RID облікових записів користувача по-чинаеться з 1000 і збільшується на 1 для кожного нового користувача або групи. Так само Windows видає SID кожному новоствореному домену (що працює лід керуванням Windows). Hcfei облікові записи домену отримують SID, що форму­ються на основі SID домену з додаванням RID (який також починається з 1000 і збільшується на 1 для кожного нового користувача або групи) R|n •

1023 вказує aa те, що його SID є 24-м, який був виданий доменом * ^HOMtipOM

Багатьом наперед заданим обліковим записам і групам Windows в що складається із SID комп'ютера або домену та наперед заданого кю°**

Так, RID облікового запису адміністратора дорівнює 500, a RlD обліком запису гостя — 501. Таким чином, в основі SID облікового залису локальн°^ГО адміністратора лежить SID комп'ютера, до якого додано RID, _Щ0 дорівнюєЯЮ-

S-l-5-21-74 6385570-2913517877-2667279727-500

Для груи.операційка система Windows також визначає низку вбудованих ло­кальних та доменних SID. Наприклад, SID, що репрезентує будь-який обліковий загшс (Everyone чи WorId), має вигляд S-l-l-0, мережна група, тобто група, ко­ристувачі якої можуть реєструватися на комп'ютері з мережі, має SID S-l-5-2 (SECURITY_NETWORK_RID), група Local - S-l-2-0.

Маркери

Для ідентифікації контексту захисту процесу чи потоку SRM використовує об'єкт, який називають маркером доступу (Access Token) або просто маркером. До кон­тексту захисту належить інформація, що описує привілеї, облікові записи та гру­пи, зіставлені з процесом або потоком. Під час реєстрації користувача в системі процес WinLogon створює початковий маркер, що представляє користувача, який входить до системи, та зіставляє його з процесом оболонки, що застосовується для входження користувача. Можна згенерувати маркер викликом Win32^yHK-ції Logon Uaer і застосувати його для створення процесу, що буде виконуватися в контексті захисту щойно зареєстрованого користувача. 3 цією метою необхідно передати отриманий маркер ^іп32-функції createProceseAsUser.

Довжина маркера варіюється, позаяк облікові записи різних користувачі мають різні набори привілеїв і зіставленні з різними обліковими записами груп, всі маркери зберігають одну і ту саму інформацію:

• джерело маркера;

• гал уособлення;

• ідентифікатор маркера;

• ідентифікатор автентифікації;

• ідентифікатор модифікації;

• час завершення дії;

• основна група за умовчанням;

• DACL за умовчанням; ¹

• SID облікового запису користувача; f SID групи 1,SID групи п;

обмежений SID 1, обмежений SID m; ► привілей І; **привілей k.

Визначаючи набір дій, дозволених у Windows потоку чи процесу, механізми захисту використовують два елементи маркера. Перший елемент складається із SID облікового запису користувача та груп. Використовуючи SID-ідентифікатори, SRM визначає, чи можна надати доступ до захищеного об'єкта того типу, що запитується. SID груп у маркері вказує, до яких груп належить обліковий запис користувача. Обробляючи клієнтські запити, серверні застосування можуть бло­кувати певні групи для обмеження посвідчень захисту, зіставлених з маркером. Блокування групи дає майже той самий ефект, що й її вилучення з маркера. Од­нак блоковані SID використовують під час перевірки прав доступу.

Другим елементом маркера, який визначає, що може робити потік або процес, якому призначено цей маркер, є список привілеїв — прав, зіставлених з марке­ром. Приклад такого привілею — право процесу або потоку вимикати комп'ютер.

Поля основної групи маркера за умовчанням і списку дискреційного керуван­ня доступом DACL є атрибутами захисту, що Windows застосовує до об'єктів, які створюються процесом чи потоком. Долучаючи до маркера інформацію про за­хист, Windows спрощує створення об'єкта зі стандартними атрибутами захисту.

Є основні маркери (Primary Token), що ідентифікують контекст захисту проце­су, та уособлені (Impersonation Token), що застосовуються для тимчасового запо­зичення потоком іншого контексту захисту (як правило, іншого користувача). Інші поля маркера — інформаційні. Поле джерела маркера зберігає відомості текстовій формі) про творця маркера. Воно дає змогу розрізняти такі джерела, як диспетчер сеансів Windows, мережний файловий сервер або RPC-сервер.

Ідентифікатор маркера є локально унікальним ідентифікатором (Locally Uni­que IDentifier, LUID), який SRM присвоює маркеру під час його створення. Ви­конавча система підтримує свій LUID-лічильник, за допомогою якого вона при­значає кожному маркеру унікальний числовий ідентифікатор.

Ідентифікатор автентифікації (Authentication ID) — це ще один різновид LUID. Він призначається маркеру підсистемою, яка його створила. Як правило, такою підсистемою є Lsass, яка копіює ідентифікатор автентифікації для всіх маркерів - нащадків початкового маркера. За допомогою цього ідентифікатора програма визначає, чи належить певний Маркер тому самому сеансові, що й інші маркери, які вона аналізує.

Ідентифікатор модифікації оновлюють щоразу, коли змінюються характери­стики маркера. Перевіряючи ідентифікатор, програма виявляє зміни в контексті захисту з моменту останнього його використання,,

Дескриптори захисту та керування доступом

Інформацію про захист, що зіставлена з об'єктом і вказує, кому та які дії дозволе­но виконувати над об'єктом, називають дескриптором захисту (Security Descrip­tor): Дескриптор захисту має свою структуру та містить такі атрибути:

• номер версії — версія моделі захисту SRM, що використана для створення де­скриптора;

• прапорці - необов'язкові модифікатори, що визначають поведінку чи харак­теристики дескриптора (наприклад, прапорець SE_DACL_PROTECTED за­бороняє дескриптору успадковувати від іншого об'єкта параметри захисту);

• SID власника — ідентифікатор захисту власника;

• SID групи —ідентифікатор захисту основної групи цього об'єкта (викорис­товується лише POSIX);

• список дискреційного керування доступом — вказує, хто і за якими методами

може отримати доступ до об'єкта;

♦ системний список керування доступом ~ вказує, які операції доступу до цьо­го об'єкта та яких користувачів слід реєструвати в журналі аудита безпеки. Список керування доступам (Access Control List, ACL) має заголовок та може містити елементи контролю доступу (Access Control Entry, АСЕ). Розрізняють списки керування доступом двох типів; списки дискреційного керування досту­пом (DACL) і списки аудита (SACL). Кожен АСЕ має SID та маску доступу (а та­кож набір прапорці»).

АСЕ списку дискреційного керування доступом можуть мати такі значення:

• доступ дозволено (Access Allowed);

• доступ заборонено (Access Denied);

• дозволений об'єкт (Allowed Object);

• заборонений об'єкт (Denied Object).

АСЕ «доступ дозволено» надають користувачу доступ до об'єкта, а «доступ заборонено» — відмовляють у наданні прав, указаних у масці доступу.

АСЕ «дозволений об'єкт» і «заборонений об'єкт» відрізняються від АСЕ «дос­туп дозволено» і «доступ заборонено» лише тим, що їх використовують в Active Directory. Вони мають поле глобального унікального ідентифікатора (Globally Unique Identifier, GUID) - гарантовано унікального 128-бітового ідентифікато­ра. Це поле вказує, що такий АСЕ можна застосовувати лише до певних об'єктів чи підоб'єктів (з GUID-ідентифікаторами). Крім того, необов'язковий GUID вка­зує, що дочірній об'єкт успадкує АСЕ під час створення цього об'єкта в контейнері Active Directory, до якого застосовано АСЕ.

Якщо в дескрипторі захисту немає DACL (DACL - nulI), то будь-який кори­стувач отримує повний доступ до об'єкта. Якщо DACL порожній (тобто в ньому немає АСЕ), доступу до об'єкта не отримає ніхто.

АСЕ, що використовуються в DACL, також мають набір прапорців, які кон­тролюють і визначають характеристики АСЕ, пов'язані з успадкуванням. Деякі простори імен об'єктів містять об'єкти-контейнери та листкові об'єкти (LeafOb-jects). Контейнер може містити інші контейнери та лисеткові об'єкти, які є його дочірніми об'єктами. Серед прикладів контейнерів можна назвати: каталог у про­сторі імен файлової системи та розділ у просторі імен реєстру. Окремі прапорці контролюють, як АСЕ застосовується до дочірніх об'єктів контейнера, зіставле­ного з цим АСЕ.

Системний список керування доступом містить елементи керування двох ти­пів: АСЕ системного ayduma (System Audit) та АСЕ об'єкта системного аудита (System Audit Object). Щ АСЕ визначають, реєстрацію яких операцій, що вико­нуються над об'єктами конкретними користувачами чи групами, буде здійснено.

Інформація про зареєстровані події зберігається у системному журналі аудит*. Це можуть бути як успішні, так і невдалі операції. АСЕ об'єктів системного аудита зберігають GUID, що вказує тип об'єкта чи підоб'єкта, до яких застосовується цей АСЕ, та необов'язковий GUID, що контролює передавання АСЕ дочірнім об'єктам конкретних типів. Якщо SACL має значення null, аудит об'єкта не ве­деться. Прапорці успадкування, що застосовуються до АСЕ DACL, можна також застосовувати до АСЕ SACL і об'єктів системного аудита.

Алгоритми з'ясовування прав доступу

Для визначення прав доступу до об'єкта застосовують два алгоритми [91,107J:

♦ алгоритм порівняння прав, які суб'єкт намагається отримати, з максимально можливими для цього об'єкта правами (алгоритм експортовано в режим ко­ристувача у вигляді ^Уіп32-функції GetEffectiveRightsFromAcl);

+ алгоритм, що перевіряє наявність конкретних прав доступу та активізується через Win32 -функцію АссеззСЬеск або AccessCheckByType. Права доступу кодуються за допомогою бітової маски, кожен біт якої від­повідає певному праву доступу. В описі алгоритмів ми будемо використовувати такі позначення:

♦ m — маска достуяу.що описує права доступу, які суб'єкт намагається отрима­ти, але ще не отримав; спочатку маска ш містить усі права, які суб'єкт запитав;

♦ g — маска доступу, що описує права доступу, вже наданісуб'єкту (Granted); на початку роботи алгоритму g-0;

♦ d — маска доступу, що описус права доступу, заборонені суб'єкту (Denied); ла початку роботи алгоритму d~0;

♦ a(r) — маска доступу і-го АСЕ;

♦ n — кількість АСЕ у дескрипторі захисту об'єкта;

♦ x* — k-й біт маски доступу x;

♦ — операція побітової інверсії;

♦ & - операція побітової кон'юнкції (побітове логічне I);

♦ | - операція побітової диз'юнкції (побітове логічне АБО).

На початку перевірки створюються маски g-0 і d-0, а в масках доступу m, a(l),.... a(w) відображаються всі можливі права доступу. Таким чином, надалі всі маски доступу a(i) містять лише специфічні та стандартні права доступу, а маски m, g і d можуть містити ще й віртуальні права доступу (причому g і d — лише віртуальне право Access System Security).

Алгоритм визначення максимальних прав доступу

Перший алгоритм визначає права доступу таким чином. 1. За відсутності DACL (DACL ~ null) об'єкт є незахипденим і система захисту надає до нього повний доступ.

12. Якщо потік, який здійснює виклик, має привілей на привласнення об'єкта (Take Ownership Privilege), то система захисТу надає правб &йнення власника (Write Owner Access): gwRrrE_owNER~l-

3. Якщо потік, який здійснює виклик, є власникомоб'єкта, йому надаються права керування читанням (Read Control) та доступу до DACL для записування (Write DACL Access): g_REAO_coNTR0L"l і gwNTEjMc"l-

4. Виконується цикл по і від 1 до n. У циклі здійснюються такі дії:

а) якщо г-й АСЕ має SID, який збігається із SID маркера доступу потоку, який здійснює виклик, і тип «доступ заборонено», то права доступу з a(i), які не містить g, додаються до d; тобто ті права, якіще не було надано в явному вигляді, позначаються як заборонені: d~d|(a(i) & -g);

б) якщо г-й АСЕ має SID, який збігається із SID маркера доступу потоку, який здійснює виклик, і тип «доступ дозволено>, то права доступу з a(0, які не містить d, додаються до g; тобто надаються права, які ще не було заборонено у явному вигляді: g-g|(a(t) & -d).

Після аналізу всіх елементів DACL обчислена маска наданих прав доступу g повертається потоку як максимальні права доступу. Вона відображає повний на­бір методів доступу, які потік може вдало запитувати, відкриваючи цей об'єкт.

Усе, що було сказано, стосується лише алгоритму, який працює в режимі ядра. В його Win32-Bepcu, що реалізується функцією GetEffectiveRightsFromAcl, відсутній крок 2 і замість маркера доступу використовується SID єдиного кори­стувача або групи.