Перевірка прав доступу
Модель захисту Windows вимагає, щоб потік заздалегідь - ще до відкриття об'єкта - вказував, які операції він збирається виконувати над цим об'єктом. Система перевіряє тип доступу, запитаний потоком, і, якщо такий доступ йому дозволено, він отримує описатель, що дозволяє йому (і іншим потокам того ж процесу) виконувати операції над об'єктом. Як вже говорилося в главі 3, диспетчер об'єктів реєструє права доступу, надані для даного описателя, в таблиці описателей, що належить процесу.
Одне з подій, що змушує диспетчер об'єктів перевіряти права доступу, - відкриття процесом існуючого об'єкта на ім'я. При відкритті об'єкту на ім'я диспетчер об'єктів шукає його в своєму просторі імен. Якщо цього об'єкта немає у вторинному просторі імен (наприклад, в просторі імен реєстру, що належить диспетчеру конфігурації, або в просторі імен файлової системи, що належить драйверу файлової системи), диспетчер об'єктів викликає внутрішню функцію ObpCreateHandle. Як і підказує її ім'я, вона створює елемент в таблиці описателей, який зіставляється з об'єктом. Однак ObpCreateHandle викликає функцію виконавчої системи ExCreateHandle і створює описувач, тільки якщо інша функція диспетчера об'єктів, ObpIncrementHandleCount, повідомляє, що потік має право на доступ до даного об'єкта. Правда, реальну перевірку прав доступу здійснює інша функція диспетчера об'єктів, ObCheckObjectAccess, яка повертає результати перевірки функції ObpIncrementHandleCount.
ObpIncrementHandleCount передає ObCheckObjectAccess посвідчення захисту потоку, що відкриває об'єкт, типи запитаного їм доступу (читання, запис, видалення і т. Д.), А також покажчик на об'єкт. ObCheckObjectAccess спочатку блокує захист об'єкта і контекст захисту потоку. Блокування захисту об'єкта запобігає її зміна іншим потоком в процесі перевірки прав доступу, а блокування контексту захисту потоку не дає іншому потоку того ж або іншого процесу змінити ідентифікаційні дані захисту першого потоку при перевірці його прав доступу. Далі ObCheckObjectAccess викликає метод захисту об'єкта, щоб отримати параметри захисту об'єкта (опис методів об'єктів див. У розділі 3). Виклик методу захисту може привести до виклику функції з іншого компонента виконавчої системи, але багато об'єктів виконавчої системи покладаються на стандартну підтримку управління захистом, пропоновану системою.
Якщо компонент виконавчої системи, визначаючи об'єкт, не збирається замінювати стандартну політику безпеки, він позначає тип цих об'єктів як використовує стандартну захист. Всякий раз, коли SRM викликає метод захисту об'єкта, він спочатку перевіряє, чи використовує об'єкт стандартну захист. Об'єкт зі стандартною захистом зберігає інформацію про захист у своєму заголовку і надає метод захисту з ім'ям SeDefaultObjectMethod. Об'єкт, який не використовує стандартну захист, повинен сам підтримувати інформацію про захист і надавати власний метод захисту. Стандартну захист використовують такі об'єкти, як м'ютекси, події і семафори. Приклад об'єкта з нестандартною захистом - файл. У диспетчера введення-виведення, що визначає об'єкти типу «файл», є драйвер файлової системи, який керує захистом своїх файлів (або вирішує не реалізувати її). Таким чином, коли система запитує інформацію про захист об'єкта «файл», що представляє файл на томі NTFS, вона отримує цю інформацію від драйвера файлової системи NTFS, який в свою чергу отримує її від методу захисту об'єкта «файл», що належить диспетчеру введення-виведення. Зауважте, що при відкритті файлу ObCheckObjectAccess не виконується, так як об'єкти «файл» знаходяться у вторинних просторах імен; система викликає метод захисту об'єкта «файл», тільки якщо потокявно запитує або встановлює параметри захисту файлу (наприклад, через Windows-функції SetFileSecurity або GetFileSecurity).
Отримавши інформацію про захист об'єкта, ObCheckObjectAccess викликає SRM-функцію SeAccessCheck, на яку спирається вся модель захисту Windows. Вона приймає параметри захисту об'єкта, ідентифікаційні дані захисту потоку (в тому вигляді, в якому вони отримані ObCheckObjectAccess) і тип доступу, запитуваний потоком. SeAccessCheck повертає True або False залежно від того, чи надає вона потоку запитаний тип доступу до об'єкта.
Згодом потік може спробувати щось записати в цей файл через Windows-функцію WriteFile, передавши як параметр описатель файлу. Системний сервіс NtWriteFile, який WriteFile викличе через Ntdll.dll, звернеться до функції диспетчера об'єктів ObReferenceObjectByHandle, щоб отримати покажчик на об'єкт «файл» за його описателю. ObReferenceObjectByHandle приймає запитаний тип доступу як параметр. Знайшовши в таблиці описателей елемент, відповідний потрібного описателю, ObReferenceObjectByHandle порівняє запитаний тип доступу з тим, який був наданий при відкритті файлу. B даному випадку ObReferenceObjectByHandle вкаже, що операція запису повинна завершитися невдало, так як викликає потік, відкриваючи файл, не отримав право на його запис.
Функції захисту Windows також дозволяють Windows-додатків визначати власні закриті об'єкти і викликати SRM-сервіси для застосування до цих об'єктів засобів захисту Windows. Багато функцій режиму ядра, використовувані диспетчером об'єктів і іншими компонентами виконавчої системи для захисту своїх об'єктів, експортуються у вигляді Windows-функцій для користувача режиму. Наприклад, еквівалентом SeAccessCheck для призначеного для користувача режиму є AccessCheck. Таким чином, Windows-додатки можуть застосовувати модель захисту Windows і інтегруватися з інтерфейсами аутентифікації і адміністрування цієї операційної системи.
Сутність моделі захисту SRM відображає математичний вираз з трьома вхідними параметрами: ідентифікаційними даними захисту потоку, запитаним типом доступу та інформацією про захист об'єкта. Його результат - значення «так» або «ні», які визначають, чи надасть модель захисту запитаний тип доступу. B наступних розділах ми поговоримо про ці вхідних параметрах і алгоритмі перевірки прав доступу в моделі захисту.