Загальна архітектура безпеки

Архітектури безпеки Windows XP [14] містять такі основні компоненти.

♦ Процес реєстрації користувачів (logon process, winlogon) обробляє запити ко­ристувачів на реєстрацію у системі та приймає дані від них.

♦ Менеджер аутентифікації (Local Security Authority Subsystem, LSASS) безпо­середньо проводить аутентифікацію користувача. Цей компонент — централь­ний у підсистемі безпеки. Крім аутентифікації, він контролює політику ауди­ту, про яку йтиметься у розділі 18.6.

♦ Менеджер облікових записів (Security Accounts Manager, SAM) підтримує базу даних облікових записів (базу даних SAM), що містить імена локальних кори­стувачів і груп, а також паролі. Під час перевірки прав користувача SAM взає­модіє із менеджером аутентифікації.

♦ Довідковиймонітор захисту (Security Reference Monitor, SRM) перевіряє пра­ва користувача на доступ до об'єкта і виконує необхідну дію з об'єктом за на­явності цих прав. Це єдиний компонент, що виконується в режимі ядра, він реалізує політику контролю доступу, визначену менеджером аутентифікації. SRM гарантує, що будь-який користувач або процес, що дістав доступ до об'єкта, має всі права на нього.

Ця архітектура реалізована у системах, що не використовують мережної аутентифікації. Для неї інформація про облікові записи має зберігатися не у базі даних SAM, а у спеціальному централізованому сховищі даних - активному ка­талозі (Active Directory). Під час мережної аутентифікації менеджер аутентифі­кації звертається до служби активного каталогу віддаленого комп'ютера, на якому розташований цей каталог. База даних SAM, однак, є у будь-якій установці OC лінії Windows XP — у ній зберігають облікові записи для локальної аутентифікації.

Подальший виклад торкатиметься локальної аутентифікації.

 

Аутентифікація

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

Розглянемо послідовність кроків реєстрації користувача у системі. Процес winlogon очікує введення від користувача. Потік цього процесу виявляє спробу користувача ввійти у систему (натискання комбінації клавіш Ctrl+Alt+Del) і про­понує йому ввести ім'я облікового запису та пароль. При цьому для реалізації такого введення winlogon звертається до спеціальної DLL графічної ідентифіка­ції та аутентифікації (GINA). Стандартне вікно введення даних користувача реа­лізоване у msgina.dll, програміст може встановити свою версію цієї динамічної біб­ліотеки, що реалізує альтернативний метод аутентифікації (наприклад, на основі смарт-карт або біометричних даних).

Дані від користувача передаються процесу winlogon, і аутентифікація із вико­ристанням бази даних SAM (за яку відповідає LSASS) відбувається відповідно до протоколу «виклик-відповідь». Можна використати і протокол Керберос (цей підхід тут не розглядатиметься).

Якщо аутентифікація пройшла успішно, створюють об'єкт, що унікальним чи­ном визначає цього користувача в усіх його подальших діях. Цей об'єкт, який на­зивають маркером доступу (access token), відіграє ключову роль у підсистемі за­хисту: він визначає, до яких системних ресурсів мають доступ потоки, створені цим користувачем.

Після успішної аутентифікації користувача LSASS створює процес і приєднує до нього маркер доступу користувача. Цей процес передають підсистемі Win32, що запускає в його адресному просторі застосування, визначене у реєстрі як оболонка системи (за замовчуванням ним є стандартна оболонка explorer.exe). Застосуван­ня формує візуальне відображення параметрів робочого столу для користувача.

 

Ідентифікатори безпеки

Із кожним користувачем і групою у Windows XP пов'язують унікальний іденти­фікатор безпеки (Security Identifier, SID). Це цілочислове значення, що склада­ється із заголовка і випадкової частини. Система безпеки звертається до користу­вачів і груп тільки за їхнім SID.

Win32 API надає ряд функцій для роботи із SID [32]. Для отримання SID ко­ристувача або групи за іменем використовують функцію LookupAccountName():

BOOL LookupAccountName (LPCTSTR sname. LPCTSTR username. PSID sid.

LPDWORD sidsize. LPTSTR dname. LPDW0RD dsize. PSID_NAME_USE sidtype);

 

де: username - ім'я користувача;

sid — покажчик на буфер пам'яті, у який записується отриманий SID, відобра­жений спеціальною структурою SID (цей буфер звичайно розміщують у дина­мічній ділянці пам'яті);

sidsize — розмір буфера (якщо його недостатньо для розміщення SID₁ у дану змінну записується необхідний розмір, а буфер sid не заповнюється); dname — покажчик на буфер пам'яті, у який записується ім'я домена, де зареєст­рований користувач (для локального користувача — ім'я комп'ютера), dsize -розмір цього буфера;

sidtype — покажчик на змінну, що задає тип SID (вона може набувати значень SidTypeUser - SID користувача, SidTypeGroup — SID групи).

Наведемо приклад отримання SID користувача за його ім'ям:

 

DWORD sidsize = 1024. domsize = 1024:

char username[] - "ivanov". domname[1024];

SID_NAME_USE sidtype = SidTypeUser:

PSID sid = (PSID)HeapAlloc (GetProcessHeap(). 0. sidsize);

LookupAccountName (NULL. username, sid, &sidsize. domname,

&domsize. &sidtype): //... робота з sid FreeSid (sid);

 

Для перетворення структури SID у рядковий формат, придатний для відобра­ження, використовують функцію ConvertSidToStringSid():

 

#include <sddl.h> char *ssid = NULL:

// PSIDsid: LookupAccountName(... sid....):

ConvertSidToStringSid( sіd. &ssi d);

// пам'ять для ssid буде виділено автоматично

printf("*sW. ssid): // S-1 -5-21 -1844237615-1682526488-1202660629-1002 LocalFree (ssid);

 

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

Маркер доступу користувача пов'язують з усіма процесами, які він створює. Мар­кер є «посвідченням особи» процесу, коли той намагається використати який-не-будь системний ресурс, і містить таку інформацію:

♦ SID користувача, із правами якого виконується процес;

♦ список груп, до яких належить цей користувач;

♦ список привілеїв, якими володіє користувач;

♦ список контролю доступу за замовчуванням, який визначає первісні права доступу для об'єктів, створюваних процесами цього користувача (про струк­туру такого списку йтиметься у пункті 18.5.3).

У разі спроби процесу відкрити дескриптор об'єкта диспетчер об'єктів зверта­ється до SRM. SRM отримує маркер доступу, пов'язаний із процесом, та викори­стовує його SID і список груп, щоб визначити, чи має процес право доступу до об'єкта. Фактично маркер доступу відповідає ідентифікатору eui d для UNIX.

Для отримання маркера доступу процесу використовують функцію Open-ProcessToken():

 

BOOL OpenProcessToken (HANDLE ph. DWORD access. PHANDLE ptoken):

де: ph — дескриптор процесу;

access — тип доступу до маркера (T0KEN_QUERY — читання інформації); ptoken - покажчик на змінну, в яку записується дескриптор маркера доступу. Ось приклад отримання маркера доступу поточного процесу:

 

HANDLE mytoken;

OpenProcessToken(GetCurrentProcessO. TOKENQUERY. &mytoken);

 

Інформація, що зберігається у маркері доступу, може бути отримана за допо­могою функції

GetTokenInformation():

 

BO0L GetTokenInformation (HANDLE token. T0KEN_INF0RMATI0N_CLASS tclass, LPV0ID tibuf. DWORD tisize. PDW0RD realsize);

 

де: token - дескриптор маркера доступу;

tclass — значення, що визначає тип отримуваної інформації (TokenUser — інформація про обліковий запис користувача, TokenGroups - список груп); ti buf — буфер для розміщення інформації (якщо tcl ass дорівнює TokenUser, цей буфер містить структуру типу T0KEN_USER із полем User, що відображає структу­ру із полем Sid, яке містить SID цього користувача); tisize - розмір буфера;

realsize - покажчик на змінну, що містить розмір буфера, необхідного для розміщення інформації (якщо tisize недостатньо, функція поверне FALSE і за­пише в цю змінну потрібний розмір).

Наведемо приклад отримання SID з маркера доступу:

 

GetTokenInformation (mytoken. TokenUser. buf. sizeof(buf). &size);

ConvertSi dToStri ngSid((( PT0KEN_USER)buf)->User.Si d. &s s і d):

printf("ls\n". ssid);

 

Запозичення прав

Окремі потоки процесу можуть виконуватися із правами користувачів, які відріз­няються від прав творця цього процесу. Такий підхід називають запозиченням прав (impersonation), за своїм призначенням він відповідає системному виклику setuid() в UNIX-системах. Як і setuid(), запозичення прав найчастіше використо­вують у серверах, які виконує користувач із адміністративними привілеями. У цьому разі потоки, що обслуговують запити користувачів, можуть виконувати­ся із меншими правами.

Потік, для якого задано запозичення прав, отримує окремий маркер доступу, який називають маркером режиму запозичення прав (impersonation token). По­дальшу перевірку прав доступу виконують із використанням цього маркера.

Для отримання маркера доступу довільного користувача необхідно здійснити програмний вхід у систему для цього користувача. Такий вхід реалізує функція LogonUser():

 

B00L LogonUser (LPTSTR username. LPTSTR domain. LPTSTR passwd. DWORD logon_type. DWORD logon_provider. PHANDLE ptoken);

 

де: username — ім'я користувача, domain — домен або комп'ютер, у якому зареєстро­ваний користувач (для локальної системи задають "."), passwd — пароль кори­стувача;

logon_type — тип входу у систему (для звичайного користувача потрібно зада­вати L0G0N32_L0G0N_INTERACTIVE);

logon_provider — алгоритм аутентифікації, який використовують для входу (L0G0N32_PR0VI0ER_DEFAULT - стандартний алгоритм); '

ptoken - покажчик на змінну, у яку поміщається маркер доступу цього кори­стувача.

Наведемо приклад коду, що здійснює програмний вхід у систему: HANDLE itoken;

LogonUser ("ivanov". "ivanov_pwd", L0G0N32_L060N_INTERACTIVE. L0G0N32_PR0VIDER_DEFAULT, &itoken):

 

Реалізацію запозичення прав у користувача, що присутній у системі, здійсню­ють задопомогою функції ImpersonateLoggedOnUser():

 

ImpersonateLoggedOnUser( і token);

//... потік виконується з правами користувача, що володіє itoken

 

Маркер доступу потоку може бути отриманий за допомогою функції Open-ThreadToken(), аналогічної до OpenProcessToken():

 

OpenThreadToken(GetCurrentThread(). TOKENQUERY. TRUE, &ttoken);

//... GetTokenInformation (ttoken,...) і т. д.

 

Для повернення до виконання із колишніми правами використовують функ­цію RevertToSelf():

 

RevertToSelf():

Керування доступом

Під час створення будь-якого об'єкта Windows XP₁ який може бути використаний більш як одним процесом (включаючи файли, поіменовані канали, синхроніза­ційні об'єкти тощо), йому присвоюють дескриптор захисту (security descriptor). До найважливіших елементів дескриптора захисту належать:

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

♦ список контролю доступу (ACL), що визначає права доступу до об'єкта. Кожний елемент списку контролю доступу (ACE) містить такі елементи:

♦ тип ACE (виділяють, зокрема, дозволяючі і забороняючі АСЕ);

♦ ідентифікатор безпеки (SID);

♦ набір прав доступу (читання, записування, повний контроль тощо).

Сума прав доступу, наданих окремими АСЕ, формує загальний набір прав доступу, наданих ACL.

Розглянемо спрощений приклад ACL для файлового об'єкта (рис. 18.2).

Якщо файловий об'єкт володіє таким ACL, користувач може чигати з відпо­відного файла, коли:

♦ під час пошуку в ACL файлового об'єкта знайдено АСЕ, що містить SID цього користувача або однієї із груп, куди він входить;

♦ цей ACE дозволяє доступ;

♦ у ньому є право на читання даних.

 

 

Щоб визначити, який ACL має призначатися новому об’єкту, система захисту застосовує три правила в такому порядку.

новому об'єкту, система захисту застосовує три правила в такому порядку.

1. Якщо ACL явно задано під час створення об'єкта, то система захисту присвоює його об'єкту.

2. Якщо ACL не задано, і в об'єкта є ім'я, система захисту шукає ACL каталогу об'єктів, де збережеться ім'я цього об'єкта (для файла таким каталогом буде каталог файлової системи). Деякі ACE каталогу можуть бути позначені як «успадковувані». Це означає, що вони присвоюються новим об'єктам, створе­ним у цьому каталозі. Якщо такі успадковувані ACE є, із них складають ACL, що призначають новому об'єкту.

3. Якщо жоден із перших двох випадків не стався, об'єкту присвоюють ACL за за­мовчуванням із маркера доступу процесу, що робив виклик.