Маркери доступу

Кожен суб'єкт, яким в Windows може бути потік або процес, має маркер доступу, який ідентифікує суб'єкта при спробі його доступу до об'єкту. Тому також говорять, що маркер доступу описує контекст безпеки суб'єкта, тобто обмежує доступ суб'єкта до об'єктів.

У маркері доступу зберігається інформація, що ідентифікує користувача, від імені якого виконується потік або процес, і привілеї, якими володіє суб'єкт.

Взагалі привілеєм називається право користувача виконати деяку дію по відношенню до деяких об'єктів або суб'єктів системи. Головна відзнака привілеїв від прав доступу полягає в тому, що, по-перше, привілеї стосуються суб'єктів, а не об'єктів системи, що охороняються; а по-друге, привілеї призначаються суб'єктам адміністратором системи, а правами доступу до об'єкту управляє власник цього об'єкту.

У таблиці. 5 перераховані привілеї і вбудовані облікові записи, яким ці привілеї призначаються за умовчанням в операційних системах Windows.

Таблиця 5. Привілеї, що призначаються обліковим записам за умовчанням

У маркері доступу зберігається наступна інформація:

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

2) список SID облікових записів груп, яким належить користувач;

3) ідентифікатор безпеки поточної сесії (logon session);

4) список привілеїв, якими володіє користувач і групи, в які він входить, на локальному комп'ютері;

5) ідентифікатор безпеки користувача або групи, який використовується за умовчанням для задання власника новостворюваного або існуючого об'єкту, що охороняється;

6) ідентифікатор безпеки первинної групи користувача;

7) список DACL, який система використовує за умовчанням при створенні об'єкту, що охороняється;

8) ідентифікатор процесу, який викликав створення маркера доступу;

9) значення, що визначає типа маркера доступу: первинний маркер або маркер, що заміщає первинний маркер маркером іншого користувача (impersonation token);

10) список SID, які обмежують доступ потоку до об'єктів, що охороняються, так звані обмежуючі SID (restricting SID);

11) значення, яке відзначає рівні заміщення сервером маркера доступу клієнта (impersonation levels);

12) статистична інформація про маркер доступу.

Пояснимо два поняття, які зустрічаються в описі маркера доступу, а саме, робота одного потоку в контексті безпеки іншого потоку і обмеження контексту безпеки процесу.

Кожен потік має свій маркер доступу, який, як вже було сказано, визначає контекст безпеки цього потоку або, іншими словами, об'єкти, що охороняються, до яких потік має доступ. Тепер уявимо собі, що потік-клієнт посилає по мережі потоку-серверу запит на виконання деякої операції. Для того, щоб сервер не вийшов за межі контексту безпеки потоку-клієнта, він повинен працювати від імені клієнта, а не від свого імені. Така заміна контексту безпеці потоку називається підміною контексту безпеки. Підміна контексту безпеки потоку може виконуватися тільки за допомогою підміни маркера доступу потоку-сервера на маркер доступу потоку-клієнта. Тому маркер доступу і містить інформацію про те, чи є він первинним або заміщається маркером іншого користувача. Підміні маркера доступу потоку-сервера на маркер доступу потоку-клієнта будемо також назвати заміщенням маркера доступу (impersonation) Виходячи з цих міркувань, можна також сказати, що заміщення маркера доступу це здатність одного процесу використовувати атрибути захисту іншого процесу.

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

Security Anonymous level - анонімний рівень, тобто сервер не може ідентифікувати клієнта, який залишається анонімним;

Security Identification level - ідентифікуючий рівень, на цьому рівні сервер може ідентифікувати клієнта, тобто може отримати будь-яку інформацію з ідентифікатора безпеки (SID) клієнта, але не може виконувати від імені клієнта ніяких дій;

Security Impersonation level - рівень підміни контексту безпеки, в цьому випадку потік-сервер може працювати від імені потоку-клієнта. Якщо потік-сервер працює на видаленому комп'ютері, то він має доступ тільки до локальних ресурсів на цьому комп'ютері. Інакше потік-сервер має доступ як до локальних, так і до мережевих ресурсів, що входять в контекст безпеки потоку-клієнта;

Security Delegation level - рівень делегування, на цьому рівні потік-клієнт повністю делегує свої повноваження потоку-серверу, який може розпоряджатися ними як на локальному, так і на віддаленому комп'ютері. Цей рівень передачі повноважень реалізований тільки в операційних системах Windows 2000/XP.

Тепер розглянемо обмежуючі SID (restricting SID), сама назва яких говорить про те, що вони використовуються для обмеження доступу суб'єкта до об'єктів. Це обмеження виконується таким чином.

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

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

2. Визначення прав доступу при створенні нових об'єктів

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

Атрибути безпеки об'єкту задаються структурою security_attributes, яка має наступний формат:

typedef struct _SECURITY_ATTRIBUTES {

DWORD nLength; // довжина структури в байтах

LPVOID IpSecurityDescriptor; // покажчик на дескриптор безпеки

BOOL blnheritHandle; // ознака спадкоємства

} SECURITY_ATTRIBUTES; *PSECURITY_ATTRIBUTES/ *LPSECURITY_ATTRIBUTES;

Адреса цієї структури передається як параметр функції створення нового об'єкту, що охороняється. Як видно з визначення, структура security_attributes містить тільки адресу дескриптора безпеки об'єкту і прапор спадкоємства цього об'єкту дочірніми процесами.

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

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

Інакше власником об'єкту стає обліковий запис, від імені якого працює потік, що створює об'єкт.

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

3. Контроль доступу до об'єкту, що охороняється

Опишемо спільну схему контролю доступу суб'єктів до об'єктів. Для цього нагадаємо, що в операційних системах Windows як суб'єкт виступає процес або потік, який виконується від імені деякого користувача. З кожним процесом асоціюється маркер доступу, який ідентифікує обліковий запис користувача, від імені якого виконується цей процес. Маркер доступу зв'язується з потоком під час його запуску при вході користувача в систему. Але фактично доступ до об'єктів здійснює потік, який виконується в контексті цього процесу.

Кожен потік також має свій маркер доступу, який може бути первинним, тобто збігатися з маркером доступу процесу, в контексті якого виконується цей потік, або запозиченим біля іншого процесу, у випадку якщо сталася підміна контексту безпеки (impersonation). Доступ до об'єкту, що охороняється, виконується з потоку. Тому під суб'єктом часто і розуміється виконуваний потік, який при контролі доступу представляється маркером доступу цього потоку. Об'єкт, що у свою чергу охороняється, доступ до якого контролюється системою управління безпекою, представляється при контролі доступу дескриптором безпеки цього об'єкту.

Тепер можна перейти до спільної схеми контролю доступу суб'єктів до об'єктів. Контроль доступу суб'єкта до об'єкту, що охороняється, виконується таким чином. При відкритті суб'єктом доступу до об'єкту, що охороняється, що зазвичай виконується за допомогою функцій типа create або open, система управління безпекою проглядає список DACL цього об'єкту, що охороняється, для пошуку елементу, в якому зберігається ідентифікатор безпеки суб'єкта. Якщо такий елемент в списку DACL не знайдений, то потік отримує відмова в доступі до об'єкту. Якщо ж такий елемент знайдений, то система перевіряє типа цього елементу. Якщо знайдений елемент має типа access_allowed_ace, то система безпеки перевіряє, чи встановлені в цьому елементі прапори прав доступу суб'єкта, які відповідають запрошуваному потоком доступу. Якщо такі прапори встановлені, то потік отримує доступ до об'єкту, що охороняється, інакше потік отримує відмова в доступі до об'єкту, що охороняється. Якщо ж знайдений елемент має типа access_denied_ace, то система безпеки перевіряє, чи встановлені прапори прав доступу суб'єкта, які відповідають запрошуваному потоком доступу. Якщо хоч би один з таких прапорів встановлений, то потік отримує відмова в доступі до об'єкту, що охороняється, інакше система продовжує проглядання списку управління доступом DACL.

Як видно, доступ потоку до об'єкту, що охороняється, залежить від порядку розташування елементів в списку управління доступом DACL цього об'єкту. Система управління безпекою включає елементи типу access_denied_ace в початок списку, якщо це включення виконується за допомогою функції setEntriesinAcl. Проте низькорівневі функції для роботи з списками доступу, такі як AddAccessAllowedAce, AddAccessDeniedAce і AddAce, не забезпечують таку послідовність елементів в списках. При роботі з такими функціями програма сама повинна контролювати лад елементів в списках управління доступом.

Крім того, доступ до об'єкту, що охороняється, також залежить від того, в якому ладі в цей список DACL включаються успадковані елементи з батьківських об'єктів. У операційній системі Windows 2000 прийнятий наступний лад включення елементів в список DACL при автоматичному спадкоємстві елементів. Успадковані елементи типа access_allowed_ace включаються в самий кінець списку DACL, після неуспадкованих елементів такого ж типа. Успадковані елементи типа access_denied_ace включаються після всіх неуспадкованих елементів такого типа, але перед всіма елементами типа access_allowed_ace.

Відмітимо, що при визначенні права доступу потоку до об'єкту, що охороняється, слід розрізняти дві ситуації:

відсутність списку DACL біля об'єкту (Null DACL) - в цьому випадку доступ до об'єкту не обмежений і дозволений для будь-якого потоку;

порожній список DACL біля об'єкту (Empty DACL) - в цьому випадку доступ до об'єкту заборонений для всіх потоків.

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

4. Аудит доступу до об'єкту, що охороняється

Тепер перейдемо до аудиту доступу суб'єктів до об'єктів, що охороняються. Аудит доступу суб'єкта до об'єкту, що охороняється, виконується таким чином. При відкритті суб'єктом доступу до об'єкту, що охороняється, що зазвичай виконується за допомогою функцій типу create, система управління безпекою проглядає список управління доступом SACL цього об'єкту.

Якщо в списку SACL знайдений елемент, який містить ідентифікатор безпеки, співпадаючий з ідентифікатором безпеки суб'єкта, і в цьому елементі встановлені прапори successful_access_ace_flag або failed_access_ace_flag (або обидва прапори разом), то система перевіряє прапори управління доступом, встановлені в цьому елементі. Якщо запрошуваний суб'єктом доступ відповідає правам користувача, тобто суб'єкт дістає доступ до об'єкту, що охороняється, і в елементі списку SACL для тих, що зажадалися суб'єктом прав доступу встановлений прапор successful_access_ace_flag, то система генерує аудиторське повідомлення про успішний доступ суб'єкта до об'єкту. Або якщо суб'єктові відмовлено в доступі до об'єкту, що охороняється, і в елементі списку SACL для тих, що зажадалися суб'єктом прав доступу встановлений прапор failed_access_ace_flag, то система генерує аудиторське повідомлення про невдалий доступ суб'єкта до об'єкту. У інших випадках аудиторські повідомлення не генеруються. При доступі суб'єкта до об'єктів, що охороняються, можливі наступні аудиторські повідомлення:

Object Open - об'єкт відкритий;

Object Open for Delete - об'єкт відкритий для видалення;

Object Deleted - об'єкт видалений.

Кожне повідомлення також містить інформацію про суб'єкта, який виконав дію, відмічену цим повідомленням. Аудиторські повідомлення записуються в журнал повідомлень (Event log). Доступ до цього журналу мають адміністратори системи за допомогою переглядання відповідних ключів реєстру.

Контрольні запитання

1. Опишіть структуру маркера доступу.

2. Опишіть реалізацію механізмів контролю доступу до ресурсів.

Завдання на самостійну роботу: повторити матеріал лекції; вивчити основні поняття.

К.т.н., доцент О. Є. Коваленко

Дата добавления: 2015-10-30