Захист інформації в операційних системах, базах даних і мережах

1. Захист інформації в операційних системах, базах даних і мережах Лекції 7-8 Windows

2. Вертикальна декомпозиція архітектури ОС Windows

3. Компоненти КЗЗ Windows (1/5) • Довідковий монітор безпеки (англ. – Security Reference Monitor, SRM) • Компонент системи (\WINNT\System32\Ntoskrnl.exe), що виконується в режимі ядра і відповідає за перевірку прав доступу до об’єктів, операції над привілеями (правами користувачів) й генерацію повідомлень аудиту безпеки • Підсистема локальної автентифікації (англ. – Local Security Authentication Subsystem Service, Lsass) • Процес режиму користувача (\WINNT\System32\Lsass.exe), що відповідає за політику безпеки в локальній системі (наприклад, визначає коло користувачів, що мають право на вхід в систему, правила, пов’язані з паролями, привілеї, що видані користувачам та їх групам, параметри аудиту безпеки системи), а також за автентифікацію користувачів і передачу повідомлень аудиту безпеки в Event Log. • Основну частину цієї функціональності реалізує сервіс локальної автентифікації Lsasrv (\WINNT\System32\Lsasrv.dll) – DLL-модуль, що його завантажує Lsass.

4. Компоненти КЗЗ Windows (2/5) • База даних політики Lsass • База даних, що зберігає параметри політики безпеки локальної системи • Розташована в розділі реєстру HKLM\SECURITY й включає таку інформацію: • яким доменам довірено автентифікацію спроб входу до системи • хто має права на доступ до системи й яким чином • кому надані ті або інші привілеї • які види аудиту потрібно виконувати • База даних політики Lsass також зберігає «таємниці», які включають в себе реєстраційні дані, що застосовуються для входу до домену та під час виклику Win32-сервісів. • Диспетчер облікових записів безпеки (англ. – Security Account Manager, SAM) • Набір процедур, що відповідають за підтримку бази даних, яка зберігає імена користувачів і груп, визначених на локальній машині • Служба SAM, реалізована у модулі \WINNT\System32\Samsrv.dll, виконується в процесі Lsass

5. Компоненти КЗЗ Windows (3/5) • База даних SAM • База даних, що зберігає інформацію про локальних користувачів та групи, разом з їхніми паролями та іншими атрибутами • Ця база даних розташована в розділі реєстру HKLM\SAM • Active Directory • Служба каталогів, що зберігає базу даних із відомостями про об’єкти в домені (домен – це сукупність комп’ютерів і зіставлених з ними груп безпеки, керування якими здійснюється як єдиним цілим) • Active Directory зберігає інформацію про об’єкт домену, у тому числі про користувачів, групи й комп’ютери. Відомості про паролі й привілеї користувачів домену та їхні групи зберігаються в Active Directory та реплікуються на комп’ютери, що виконують роль контролерів домену. • Сервер Active Directory реалізований у модулі \WINNT\System32\Ntdsa.dll, виконується в процесі Lsass

6. Компоненти КЗЗ Windows (4/5) • Пакети автентифікації • DLL-модулі, що виконуються у контексті процесу Lsass і реалізують політику автентифікації у Windows. • DLL-автентифікація відповідає за перевірку пароля й імені користувача, а також повернення Lsass (у разі вдалої перевірки) докладної інформації про права користувача. • Процес Logon (Winlogon) • Процес режиму користувача (\WINNT\System32\Winlogon.exe), що відповідає за підтримку SAS (Secure Attention Sequence) і керування сеансами інтерактивного входу в систему • В процесі реєстрації користувача Winlogon створює оболонку – інтерфейс користувача. • GINA (Graphical Identification and Authentication) • DLL режиму користувача, що виконується в процесі Winlogon і застосовується для отримання паролю й імені користувача або PIN-коду смарт-карти • Стандартна бібліотека GINA знаходиться у \WINNT\System32\Msgina.dll

7. Компоненти КЗЗ Windows (5/5) • Служба мережного входу до системи (Net Logon, Netlogon) • Win32сервіс (\WINNT\System32\Netlogon.dll), виконується в Lsass і реагує на запити мережного входу від Microsoft LAN Manager 2 під керуванням Windows NT (будь-яких версій до Windows 2000). В цьому випадку автентифікація відпрацьовується як при локальній реєстрації – дані передаються Lsass для перевірки. У Netlogon також вбудовано службу локатора, що потрібна для пошуку контролерів домену. • Kernel Security Device Driver (KSecDD) • Бібліотека функцій режиму ядра, що реалізує інтерфейси локального виклику процедур (англ. –local procedure call, LPC), які використовуються іншими компонентами захисту режиму ядра – у тому числі файловою системою, що шифрує (англ. – Encrypting File System, EFS) – для взаємодії з Lsass у режимі користувача • KSecDD знаходиться у \WINNT\System32\Drivers\Ksecdd.sys

8. Взаємодія компонентів й БД системи безпеки

9. Основні принципи реалізації системи розмежування доступу • Windows реалізує дискреційну модель розмежування доступу • Підтримує 4 типи суб’єктів та 13 типів об’єктів доступу • Керування доступом здійснюється за допомогою модулю SRM • реалізується викликом функції SeAccessCheck ядра ОС при будь-якій спробі суб’єкта отримати доступ • Використовуються дві структури даних: • маркер доступу суб’єкта, що є носієм його повноважень • дескриптор захисту об’єкта, що містить • ідентифікатори власника об’єкта та його первинної групи • список дискреційного контролю доступу (Discretionary Access-Control List, DACL) • список аудиту (Security Access-Control List, SACL) • Матриця доступу зберігається у вигляді множини списків контролю доступу об’єктів, які мають нефіксовану довжину і можуть містити довільну кількість елементів контролю доступу ( Access Control Entry, ACE), які можуть дозволяти або забороняти доступ • АСЕ, що забороняють доступ, мають більший пріоритет • У випадку відсутності АСЕ, що визначає потрібні права, у доступі буде відмовлено (реалізується принцип мінімуму повноважень) • Задавати права доступу до файлових та принтерних об’єктів можна за допомогою Windows Explorer, а також за допомогою консольної команди cacls

10. Суб’єкти доступу Windows • Користувачі • звичайні користувачі • псевдокористувачі: • SYSTEM – ОС локального комп’ютера • <ім’я_комп’ютера>$, де ім’я_комп’ютера – мережеве ім’я комп’ютера; представляють ОС інших комп’ютерів в мережі і використовуються під час автентифікації робочої станції на контролері домену • Групи користувачів • Спеціальні (тимчасові) групи • Належність користувача до спеціальних груп визначається ОС в залежності від його дій: • INTERACTIVE • NETWORK • DIAL_UP • Спеціальна група не може бути первинною групою користувача • Відносні суб’єкти • мають сенс лише стосовно об’єкта, для якого визначаються права доступу • CREATOR_OWNER – власник об’єкта • CREATOR_GROUP – первинна група власника об’єкта

11. Стандартні суб’єкти доступу (1/2) • В усіх екземплярах ОС Windows присутні такі суб’єкти доступу, що мають наперед задані ідентифікатори: • SYSTEM • INTERACTIVE • NETWORK • DIAL_UP • CREATOR_OWNER • CREATOR_GROUP • Everyone • Під час інсталяції Windows автоматично створює таких визначених наперед суб’єктів доступу: • Administrator – адміністратор ОС • Guest – гість, користувач з мінімальними правами, який входить до системи анонімно • Administrators – група адміністраторів ОС • Users – група користувачів ОС, за умовчанням члени цієї групи мають дуже обмежені права

12. Стандартні суб’єкти доступу (2/2) • Backup Operators – група операторів резервного копіювання • Replicator – суб’єкт доступу, що використовується для автоматичної реплікації файлів і ключів реєстру між комп’ютерами домену • Power Users (створюється лише на робочих станціях) – група користувачів, які мають більші права, ніж звичайні користувачі • Account Operators (створюється лише на серверах) – група користувачів, які можуть працювати з обліковими записами непривілейованих суб’єктів доступу • Print Operators (створюється лише на серверах) – група адміністраторів друкування • Server Operators (створюється лише на серверах) – група операторів сервера, що за умовчанням має дещо більші повноваження, ніж звичайні користувачі • В доменах Windows існують також наперед визначені глобальні групи, спільні для усіх комп’ютерів домену: • Domain Admins – адміністратори домену • Domain Users – користувачі домену • Domain Guests – гості домену

13. Стандартні типи об’єктів доступу Windows (1/3) • Файлові об’єкти • файли • дискові директорії (каталоги) • пристрої – об’єкти, що використовуються для взаємодії застосувань з драйверами фізичних і логічних пристроїв • канали (pipes) – об’єкти, що використовуються для організації взаємодії процесів • поштові скриньки (mailslots) – об’єкти, що використовуються для асинхронної передачі повідомлень між процесами • Об’єктові директорії (англ. – object directories) – об’єкти, що містять в собі інші об’єкти. На відміну від дискових директорій, об’єктові директорії можуть містити в собі будь-які об’єкти. • Ключі реєстру (англ. – registry keys) • Процеси – екземпляри програм, що виконуються в поточний момент на цьому комп’ютері • Потоки або нитки (англ. – threads) – ланцюги машинних команд, що послідовно виконуються в цей момент на цьому комп’ютері

14. Стандартні типи об’єктів доступу Windows (2/3) • Диспетчер сервісів (англ. – Service Control Manager) – об’єкт Windows, що використовується для керування сервісами • Сервіси (англ. – services) – програмні модулі ОС Windows NT, керування якими здійснюється диспетчером сервісів • Сервіси Windows NT дуже подібні до драйверів, і керування ними здійснюється аналогічно, але на відміну від драйверів сервіси виконуються в режимі користувача, а не ядра • Об’єкти керування вікнами (англ. – window-management objects): • робочі столи (англ. – desktops) – сукупності вікон, що взаємодіють між собою; вікна різних робочих столів не можуть бути видимими на екрані комп’ютера одночасно; • віконні станції (англ. – window stations) – сукупності робочих столів, на різних віконних станціях можуть одночасно працювати різні користувачі. • Порти (англ. – ports) – об’єкти, що використовуються під час передачі повідомлень між процесами • Секції розділюваної пам’яті (англ. – shared memory sections) – області пам’яті, що розділяються між кількома процесами

15. Стандартні типи об’єктів доступу Windows (3/3) • Символічні зв’язки (англ. – symbolic links) – об’єкти, що дозволяють створювати синоніми для імені об’єкта • Маркери доступу (англ. – access tokens) – об’єкти, що містять інформацію про користувачів і псевдокористувачів, які працюють в системі • Об’єкти синхронізації: • події (англ. – events) – об’єкти, що використовуються при асинхронних зверненнях до файлових систем і пристроїв • пари подій (англ. – event pairs) – об’єкти, що використовуються при передаванні повідомлень від одного процесу до іншого • семафори (англ. – semaphores) – об’єкти, що використовуються для обмеження кількості одночасних звернень різних потоків до одного об’єкта • м’ютекси (англ. – mutexes) – об’єкти, що використовуються для виключення одночасного доступу кількох потоків до одного об’єкта ОС • Файли, дискові директорії та ключі реєстру є постійними об’єктами і можуть зберігатись на дисках комп’ютера. Всі решта об’єктів є тимчасовими і зберігаються лише в оперативній пам’яті.

16. Методи доступу • Загалом ОС Windows підтримує 22 методи доступу суб’єктів до об’єктів • 6 з них підтримуються для об’єктів усіх типів, а саме: • видалення об’єкта, • отримання атрибутів захисту об’єкта, • зміна атрибутів захисту об’єкта, • зміна власника об’єкта, • отримання та зміна параметрів аудиту по відношенню до об’єкта (ACCESS_SYSTEM_SECURITY), • синхронізація (SYNCHRONIZE). • Названі методи є стандартними методами доступу • Для кожного типу об’єктів також підтримуються до 16 типів специфічних методів доступу

17. Специфічні методи доступу для деяких об’єктів (1/3)

18. Специфічні методи доступу для деяких об’єктів (2/3)

19. Специфічні методи доступу для деяких об’єктів (3/3)

20. Спеціальні привілеї • Частина методів доступу вимагають від суб’єкта доступу спеціальних привілеїв. До таких методів належать: • створення нового сервісу; • блокування списку сервісів; • запуск сервісу; • зупинка сервісу; • призупинення / поновлення сервісу; • призначення процесу маркера доступу; • отримання або зміна параметрів аудиту по відношенню до об’єкта.

21. Права доступу • Специфічні • Кожному специфічному методу доступу, що підтримується для певного типу об’єктів, відповідає право на його здійснення • Стандартні • Кожному стандартному методу доступу, за виключенням ACCESS_SYSTEM_SECURITY, також відповідає право доступу • Загальні (generic) або відображувані (mapped) • Відображувані права доступу введені, головним чином, для сумісності з програмним інтерфейсом POSIX, який підтримує лише три права доступу, що визначені для усіх типів об’єктів, – зчитування, записування і виконання. • Віртуальні • Віртуальні права доступу можуть бути запитані суб’єктом, але не можуть бути йому наданими

22. Відображувані права доступу • До них відносяться: • зчитування (GENERIC_READ) • записування (GENERIC_WRITE) • виконання (GENERIC_EXECUTE) • усі дії (GENERIC_ALL) • Кожне з відображуваних прав доступу є певною комбінацією стандартних і специфічних прав доступу • Відображуване право доступу надає можливість здійснити деякий набір методів доступу до об’єкта • Відображувані права можуть бути наданими для доступу до об’єкта будь-якого типу • Конкретний зміст таких прав залежить від типу об’єкта, оскільки включає певні специфічні права. • Процес перетворення відображуваного права доступу в набір стандартних і специфічних прав доступу називається відображенням прав доступу • Порядок відображення для об’єктів конкретного типу визначається при реєстрації цього типу об’єктів

23. Відображення права “зчитування” • Для об’єкта типу “файл” це право дозволяє здійснювати доступ до об’єкта за методами: • зчитування файла, • отримання DOS-атрибутів файла, • отримання розширених атрибутів файла, • отримання атрибутів захисту файла, • синхронізація. • В той самий час для об’єкта типу “ключ реєстру” це право дозволяє здійснювати доступ до об’єкта за методами: • зчитування значень ключа, • перелік підключів ключа, • вимога сповіщення при доступі до ключу іншого потоку, • отримання атрибутів захисту ключа, • синхронізація.

24. Віртуальні права доступу • Віртуальні права доступу можуть бути запитані суб’єктом, але не можуть бути йому наданими. • Існують два віртуальних права доступу: • MAXIMUM_ALLOWED, • ACCESS_SYSTEM_SECURITY. • Якщо суб’єкт запитує віртуальне право MAXIMUM_ALLOWED, він в результаті отримує доступ до об’єкта за максимальною для цього суб’єкта множиною методів • Тобто, йому будуть надані всі методи, на які він має права • Право ACCESS_SYSTEM_SECURITY – це право на здійснення однойменного стандартного методу доступу • Право є віртуальним, тому що насправді можливість доступу суб’єкта за цим методом контролюється відповідним привілеєм суб’єкта, який надає суб’єкту право доступу за цим методом до всіх без виключення об’єктів доступу • Заборонити чи дозволити доступ за цим методом конкретного суб’єкта до конкретного об’єкта неможливо.

25. Реалізація дискреційного керування доступом • Ключову роль у захисті відіграє диспетчер об’єктів. • Коли якийсь потікнамагається здійснити доступ, він запитує визначник об’єкта • Модель захисту Windows потребує, щоб потік ще до відкривання об’єкта вказав, які операції він збирається виконувати над цим об’єктом • Диспетчер об’єктів та SRM, ґрунтуючись на ідентифікаційних даних процесу, якому належить цей потік, визначають, чи можна надати йому визначник, що дозволяє доступ до потрібного об’єкта • Диспетчер об’єктів реєструє права доступу, надані для даного визначника, в таблиці визначників, що належить процесу. • Контекст захисту потоку може відрізнятися від контексту захисту його процесу. Цей механізм називається уособленням (impersonation) • У випадку уособлення механізми перевірки захисту використовують контекст захисту потоку замість контексту захисту процесу, а без уособлення – контекст захисту процесу, до якого належить потік • Всі потоки одного процесу використовують спільну таблицю визначників, тому, коли потік відкриває будь-який об’єкт (навіть при уособленні), всі потоки цього процесу отримують доступ до цього об’єкту.

26. Відкривання процесом об’єкта, що існує, за іменем • Це – одна з подій, яка примушує диспетчер об’єктів перевіряти права доступу • При відкриванні об’єкта за іменем, диспетчер об’єктів шукає його в своєму просторі імен • Ім’я об’єкта може належати вторинному простору імен • наприклад, простору імен реєстру, що належить диспетчеру конфігурації • або простору імен файлової системи, що належить драйверу файлової системи • Якщо ім’я об’єкта не належить вторинному простору імен, диспетчер об’єктів викликає внутрішню функцію ObpCreateHandle – ця функція створює елемент в таблиці визначників, який зіставляється з об’єктом • Для створення елементу в таблиці визначників викликається функція виконуючої системи ExCreateHandle • ObpCreateHandle створює визначник лише тоді, коли інша функція диспетчера об’єктів, ObpIncrementHandleCount повідомляє, що потік має право на доступ до даного об’єкту • Остання функція для перевірки прав доступу викликає ще одну функцію диспетчера об’єктів, ObCheckObjectAccess, яка повертає результат перевірки

27. Робота функції ObCheckObjectAccess • У функцію ObCheckObjectAccess передаються посвідчення (credentials) захисту потоку, що відкриває об’єкт, тип доступу, що запитується, а також покажчик на об’єкт • ObCheckObjectAccess спочатку блокує захист об’єкта та контекст захисту потоку • Блокування захисту об’єкта запобігає його зміні іншим потоком в процесі визначення прав доступу • Блокування контексту захисту потоку не дає іншому потокові того самого або іншого процесу змінити ідентифікаційні дані захисту першого потоку під час перевірки його прав доступу • Далі ObCheckObjectAccess викликає метод захисту об’єкта, щоб отримати параметри захисту об’єкта • Виклик методу захисту може привести до виклику функції з іншого компоненту виконавчої системи (якщо об’єкт використовує нестандартний захист), але багато об’єктів покладаються на стандартну підтримку керування захистом, що пропонується системою. • Отримавши інформацію про захист об’єкта, ObCheckObjectAccess викликає SRM-функцію SeAccessCheck, на яку спирається вся модель захисту Windows • Вона приймає параметри захисту об’єкта, ідентифікаційні дані захисту потоку (у тому вигляді, в якому вони отримані від ObCheckObjectAccess) і тип доступу, який запитує потік. SeAccessCheck вертає True або False залежно від того, чи дозволяє вона потоку тип доступу що він запросив

28. Об’єкти із стандартним та нестандартним захистом • Кожного разу, коли здійснюється виклик методу захисту об’єкта, спочатку перевіряється, чи не використовує об’єкт стандартний захист • Об’єкт зі стандартним захистом зберігає інформацію про захист у своєму заголовку і пропонує метод захисту з іменем SeDefaultObjectMethod • Стандартний захист використовують такі об’єкти як м’ютекси, події та семафори • Об’єкт, що не використовує стандартний захист, має сам підтримувати інформацію про захист, і пропонувати власний метод захисту • Приклад об’єкта з нестандартним захистом – файл • У диспетчера введення-виведення, що визначає об’єкти типу “файл”, є драйвер файлової системи, який керує захистом своїх файлів (або не реалізовує захисту) • При відкриванні файлу ObCheckObjectAccess не виконується, оскільки об’єкти “файл” знаходяться у вторинних просторах імен • Система викликає метод захисту об’єкту файл, тільки якщо потік явно запитує або встановлює параметри захисту файлу (наприклад, через Win32-функції SetFileSecurity або GetFileSecurity)

29. Посилання процесу на об’єкт по існуючому визначнику • Це – інша подія, що вимушує диспетчер об’єктів виконати перевірку прав доступу • Подібні посилання часто робляться опосередковано, наприклад при маніпуляціях з об’єктом через Win32 API з передаванням його визначника • Наприклад, нехай потік, що відкриває файл, запитує доступ для читання з файлу • Якщо потік має відповідні права, що визначаються його контекстом захисту та параметрами захисту файлу, диспетчер об’єктів створює визначник даного файлу в таблиці визначників, що належить процесові – власникові цього потоку • Інформація про наданий процесу тип доступу зіставляється з визначником і зберігається диспетчером об’єктів • В подальшому потік може спробувати щось записати в цей файл через Win32-функцію WriteFile, надавши в якості параметру визначник файлу • Системний сервіс NtWriteFile, котрий WriteFile викличе через Ntdll.dll, звернеться до функції диспетчера об’єктів ObReferenceObjectByHandle, щоб отримати посилання на об’єкт «файл» по його визначнику • ObReferenceObjectByHandle приймає запитаний тип доступу як параметр • Знайшовши у таблиці визначників елемент, що відповідає потрібному визначнику, ObReferenceObjectByHandle порівняє запитаний тип доступу з тим, що був наданий при відкриванні файлу • В даному випадку ObReferenceObjectByHandle вкаже, що операція запису має завершитись невдало, оскільки потік, що викликає, відкриваючи файл, не отримав право на записування в нього.

30. Модель захисту Windows для Win32 • Функції захисту Windows дозволяють застосуванням Win32 визначати власні закриті об’єкти і викликати SRM-сервіси для застосування до цих об’єктів засобів захисту Windows • Сутність моделі захисту SRM відображає математичний вираз з трьома вхідними параметрами: • ідентифікаційними даними захисту потоку, • типом доступу, що запитується, • інформацією про захист об’єкту. • Його результат – значення «так» або «ні», які визначають, чи надасть модель захисту доступ, що запитується • Багато з функцій режиму ядра, які використовує диспетчер об’єктів та інші компоненти виконавчої системи для захисту своїх об’єктів, експортуються у вигляді Win32-функцій режиму користувача • Наприклад, еквівалентом SeAccessCheck для режиму користувача є AccessCheck • Таким чином, застосування Win32 можуть застосовувати модель захисту Windows й інтегруватися з інтерфейсами автентифікації й адміністрування цієї операційної системи

31. Ідентифікатори захисту SID(1/2) • Для ідентифікації активних об’єктів (суб’єктів) в системі, Windows використовує ідентифікатори захисту (Security Identifiers, SID) • SID є у користувачів, локальних груп та груп домену, локальних комп’ютерів, доменів та членів доменів • SID являє собою числове значення змінної довжини, що формується з • номера версії структури SID • 48-бітного коду агента ідентифікатора (Identifier Authority Value) • Код агента ідентифікатора визначає агента, що видав SID • Таким агентом зазвичай є локальна система або домен під керуванням Windows • змінної кількості 32-бітних кодів субагентів та/або відносних ідентифікаторів (Relative Identifiers, RID) • Коди субагентів ідентифікують попечителів, яких уповноважив агент, що видав SID • RID – засіб створення унікальних SID на основі спільного базового SID (common-based SID) • Оскільки довжина SID достатньо велика і Windows намагається генерувати дійсно випадкові значення для кожного SID, ймовірність появи двох однакових SID практично дорівнює нулю. • В текстовій формі кожен SID починається з префікса S, за яким слідують групи чисел, розділених дефісами, наприклад S-1-5-21-746385570-2913517877-2667279727-1023 • В цьому SID номер версії дорівнює 1, код агента ідентифікатора – 5 (Windows, SECURITY_NT_AUTHORITY), далі йдуть коди чотирьох субагентів та один RID на кінці (1023).

32. Ідентифікатори захисту SID(2/2) • SID призначається комп’ютеру під час інсталяції Windows програмою Windows Setup • Далі Windows призначає SID локальним обліковим записам на цьому комп’ютері • SID кожного локального облікового запису формується на основі SID комп’ютеру з додаванням RID • RID облікових записів користувача починається з 1000 і збільшується на 1 для кожного нового користувача або групи • Аналогічно Windows видає SID кожному новоствореному доменові Windows • Нові облікові записи домену отримують SID, що формуються на основі SID домену з додаванням RID (який також починається з 1000 й збільшується на 1 для кожного нового користувача або групи) • RID з номером 1023 вказує на те, що його SID є 24-м, що був виданий доменом • Багатьом наперед заданим обліковим записам й групам Windows видає SID, що складається з SID комп’ютера або домену та наперед заданого RID • RID облікового запису адміністратора дорівнює 500 • RID облікового запису гостя – 501 • В основі SID облікового запису локального адміністратора лежить SID комп’ютера, до якого додано RID, що дорівнює 500: S-1-5-21-746385570-2913517877-2667279727-500 • Для груп Windows також визначає ряд вбудованих локальних та доменних SID • SID, що репрезентує будь-який обліковий запис (має назву Everyone або World), має вигляд S-1-1-0 • SID мережної групи має вигляд S-1-5-2 (SECURITY_NETWORK_RID)

33. Маркери (1/3) • Інформація, що описує привілеї, облікові записи та групи, зіставлені з процесом або потоком, складає контекст захисту • Для ідентифікації контексту захисту SRM використовує об’єкт, що зветься маркером (token), або маркером доступу (access token) • Довжина маркеру варіюється через те, що облікові записи різних користувачів мають неоднакові набори привілеїв й зіставленні з різними обліковими записами груп • Усі маркери зберігають одну й ту ж саму інформацію: • джерело маркера; • тип уособлення; • ідентифікатор маркера; • ідентифікатор автентифікації; • ідентифікатор модифікації; • час закінчення дії; • основна група по умовчанню; • DACL по умовчанню; • SID облікового запису користувача; • SID групи 1 … SID групи n; • обмежений SID 1 … обмежений SID m; • привілей 1 … привілей k.

34. Маркери (2/3) • Під час визначення набору методів доступу, що дозволені потоку чи процесу, механізми захисту в Windows використовують два елемента маркера • Перший елемент складається з SID облікового запису користувача та полів SID груп. SID груп в маркері вказує, до яких груп належить обліковий запис користувача. • При обробці клієнтських запитів, серверні застосування можуть блокувати визначені групи для обмеження посвідчень захисту, зіставлених з маркером • Блокування групи дає майже той самий ефект, що її виключення з маркера • Однак, блоковані SID використовуються при перевірці прав доступу. • Другим елементом маркера, що визначає, що може робити потік або процес, є список привілеїв – прав, зіставлених з маркером • Прикладом привілею може буди право процесу або потоку, зіставленого з маркером, виключати комп’ютер

35. Маркери (3/3) • Поля основної групи маркера по умовчанню і списку дискреційного керування доступом (DACL), являють собою атрибути захисту, що застосовуються Windows до об’єктів, які створюються процесом чи потоком з використанням маркера • Маркер може бути • основним (Primary Token) • ідентифікує контекст захисту процесу • уособленим (Impersonation Token) • застосовується для тимчасового запозичення потоком іншого контексту захисту – зазвичай іншого користувача • Поле джерела маркера зберігає відомості (в текстовій формі) про творця маркера • Дозволяє розрізняти такі джерела, як диспетчер сеансів Windows, мережевий файл-сервер або RPC-сервер

36. Ідентифікатори маркера • Ідентифікатор маркера являє собою локально унікальний ідентифікатор (Locally Unique Identifier, LUID), який SRM присвоює маркеру при його створенні • Виконавча система підтримує свій LUID-лічильник, за допомогою якого вона призначає кожному маркеру унікальний числовий ідентифікатор. • Ідентифікатор автентифікації (Authentication ID) – це також LUID. Він призначається маркерові творцем • Як правило, Lsass є єдиним творцем маркерів у системі й формує LUID з LUID виконавчої системи • Lsass копіює ідентифікатор автентифікації для всіх маркерів – нащадків початкового маркеру • Використовуючи цей ідентифікатор, програма може визначити, чи належить якийсь маркер тому самому сеансові, що й інші маркери, які аналізуються цією програмою • Ідентифікатор модифікації оновлюється виконавчою системою при кожній зміні характеристик маркера. • Перевіряючи ідентифікатор модифікацій, програма може виявляти зміни в контексті захисту з моменту останнього використання • Маркери мають поле терміну закінчення дії, яке існує в них, починаючи з Windows NT 3.1, але досі не використовується і не описане в MSDN • Якщо термін дії облікового запису закінчується в той момент, коли користувач все ще знаходиться в системі, він все ще може звертатися до системних ресурсів, доступ до яких було дозволено по простроченому обліковому запису • Якби Windows підтримувала маркери з обмеженим часом дії, система могла б заборонити користувачу доступ до ресурсів одразу після завершення терміну дії маркера.

37. Дескриптори захисту • Дескриптор захисту (Security Descriptor) – це структура даних, що зберігає інформацію про захист, що зіставлена з об’єктом і вказує кому й які дії дозволено виконувати над об’єктом • Дескриптор захисту включає такі атрибути: • Номер версії. Версія моделі захисту SRM, що використана для створення дескриптора • Прапори. Необов’язкові модифікатори, що визначають поведінку чи характеристики дескриптора • Приклад – прапор SE_DACL_PROTECTED, який забороняє успадкування дескриптором параметрів захисту від іншого об’єкта • SID власника. Ідентифікатор захисту власника • SID групи. Ідентифікатор захисту основної групи даного об’єкта • використовується тільки POSIX • Список дискреційного керування доступом (DACL) • Вказує, хто і за якими методами доступу може отримати доступ до об’єкта • Системний список керування доступом(SACL) • Вказує, які операції доступу до цього об’єкта й яких користувачів мають реєструватися в журналі аудиту безпеки

38. Списки керування доступом • Список керування доступом складається із заголовку й може містити елементи (ACE) • Існує два типи ACL: DACL та SACL • У DACL кожен ACE має SID та маску доступу (а також набір прапорців) • ACE можуть бути чотирьох типів: • “доступ дозволено” (access allowed) • “доступ заборонено” (access denied) • “дозволений об’єкт” (allowed-object) • “заборонений об’єкт” (denied-object) • ACE типів “дозволений об’єкт” та “заборонений об’єкт” використовуються лише в Active Directory • Якщо в дескрипторі захисту немає DACL (DACL = null), то будь-який користувач отримає повний доступ до об’єкту. Якщо DACL пустий (тобто в ньому немає ACE), доступ до об’єкта не отримає ніхто. • ACE, що використовуються в DACL, також мають набір прапорів, які контролюють і визначають характеристики ACE, що пов’язані з успадкуванням • SACL складається з ACE двох типів: • “системного аудиту” (System Audit ACE) • “об’єкта системного аудиту” (System Audit-Object ACE). • Ці ACE визначають, аудит яких операцій, що виконуються над об’єктами конкретними користувачами або групами, має бути виконаний

39. Алгоритми з’ясування прав доступу • Для визначення прав доступу до об’єкта використовуються два алгоритми: • алгоритм, що порівнює запитані права з максимально можливими для даного об’єкта та експортується в режим користувача у вигляді Win32 функції GetEffectiveRightsFromAcl • алгоритм, що перевіряє наявність конкретних прав доступу та активується через Win32-функцію AccessCheckабоAccessCheckByType • Права доступу кодуються за допомогою бітової маски, кожний біт якої відповідає певному праву доступу • На початку перевірки створюються маски g=0і d=0, а в масках доступу m, a(1), …, a(n) відображаються всі відображувані права доступу • Таким чином, в подальшому всі маски доступу a(i) містять лише специфічні і стандартні права доступу, а маски m, gі dможуть містити ще й віртуальні права доступу (причому gі d – лише віртуальне право Access System Security)

40. Позначення в описі алгоритмів m– маска доступу, що описує права доступу, які суб’єкт намагається отримати, але ще не отримав; на початку алгоритму маска m містить всі права, які суб’єкт запитав; g– маска доступу, що описує права доступу, вже надані суб’єкту (“granted”); на початку роботи алгоритму g=0; d– маска доступу, що описує права доступу, заборонені суб’єкту (“denied”); на початку роботи алгоритму d=0; a(i) – маска доступу і-гоACE; n – кількість ACE у дескрипторі захисту об’єкта; xi –i-й біт маски доступуx; ~ – операція побітової інверсії; & – операція побітової кон’юнкції (побітове логічне І); | – операція побітової диз’юнкції (побітове логічне АБО).

41. Алгоритм з’ясування максимальних прав доступу • За відсутності DACL (DACL = null) об’єкт є незахищеним і система захисту надає до нього повний доступ • Якщо потік, що викликає, має привілей заволодіння об’єктом у власність (Take-Ownership Privilege), система захисту надає право доступу для заміни власника (Write-Owner Access) до аналізу DACL: gWRITE_OWNER=1 • Якщо потік, що викликає, є власником об’єкта, йому надаються права керування читанням (Read-Control) й доступу до DACL для записування (Write-DACL Access): gREAD_CONTROL=1 і gWRITE_DAC=1. • Виконується цикл по i від 1 до n. В циклі виконуються такі дії: • Якщо i-й АСЕ має SID, що співпадає з SID маркера доступу потоку, що викликає, і має тип “доступ заборонено”, то права доступу з a(i), які не містяться в g, додаються до d, тобто ті права, які ще не були у явному вигляді надані, помічаються як заборонені: d=d|(a(i) & ~g) • Якщо i-й АСЕ має SID, що співпадає з SID маркера доступу потоку, що викликає, і має тип «доступ дозволено», то права доступу з a(i), які не містяться в d, додаються до g, тобто надаються ті права, які ще не були у явному вигляді заборонені: g=g|(a(i) & ~d) • Після аналізу всіх елементів DACL розрахована маска наданих прав доступу g повертається потоку як максимальні права доступу • Ця маска відображає повний набір методів доступу, які потік може вдало запитувати при відкриванні даного об’єкта • Все вищезгадане відноситься лише до того різновиду алгоритму, що працює в режимі ядра. Його Win32-версія, реалізована функцією GetEffectiveRightsFromAcl, відрізняється відсутністю кроку 2, а також тим, що замість маркеру доступу вона розглядає SID єдиного користувача або групи

42. Алгоритм з’ясування можливості доступу з заданими правами (1/3) • Цей алгоритм перевіряє чи можливо задовольнити конкретний запит на доступ, виходячи з маркера доступу потоку, що викликає • У кожної Win32-функції відкривання захищених об’єктів є параметр, що вказує бажану маску доступу m – останній елемент виразу, що описує захист об’єкта • За відсутності DACL (DACL = null) об’єкт є незахищеним і система захисту надає до нього тип доступу, що запитується • Якщо у потоку, що викликає, є привілей захоплення у володіння, і mWRITE_OWNER=1 то система захисту надає право на запис власника: gWRITE_OWNER=1, mWRITE_OWNER=0 • Якщо після цього виявляється, що m=0, тобто потік запитав лише доступ на запис власника, система надає йому цей тип доступу і на цьому завершує перевірку • Якщо потік, що зробив виклик, є власником об’єкта, то: • Якщо mREAD_CONTROL=1, то йому надається право керування читанням: gREAD_CONTROL=1, mREAD_CONTROL=0 • Якщо mWRITE_DAC=1, то йому надається право на запис до DACL: gWRITE_DAC=1, mWRITE_DAC=0 • Якщо потік, що викликає, запитав лише ці права (тобто, на цьому кроці m=0), то система захисту надає їх без перегляду DACL • Якщо потік має привілей аудитора і цей привілей не заблокований і mACCESS_SYSTEM_SECURITY=1, то йому надається право на зчитування і записування параметрів аудиту об’єкта: gACCESS_SYSTEM_SECURITY=1, mACCESS_SYSTEM_SECURITY=0 • Якщо m=0, то подальша перевірка не виконується, доступ надається

43. Алгоритм з’ясування можливості доступу з заданими правами (2/3) • У циклі по i від 1 до n переглядаються всі ACE у DACL – від першого до останнього. Обробка ACE виконується у випадку однієї з наступних умов: • SID в ACE збігається з неблокованим SID (SID можуть бути блоковані та неблоковані) у маркері доступу потоку, що викликає, незалежно від того, який це SID – основний чи групи; • SID в ACE типу “доступ дозволено” збігається з SID у маркері доступу потоку, що викликає, і цей SID не має атрибуту перевірки тільки на заборону; • Йде вже другий прохід пошуку в дескрипторі обмежених SID, та SID в ACE збігається з обмеженим SID у маркері доступу потоку, що викликає. • Якщо i-й АСЕ має тип “доступ заборонено”, то права доступу з a(i), які містяться в m, але не містяться в g, додаються до d, тобто ті права, рішення за якими ще не було прийнято, помічаються як заборонені: d=d|(a(i) & m & ~g) • Якщо i-й АСЕ має тип “доступ дозволено”, то права доступу з a(i), які містяться в m, але не містяться в d, додаються до g, тобто надаються ті права, які ще не були у явному вигляді заборонені, і при цьому надані права вилучаються із списку прав, які були запитані: g=g|(a(i) & m & ~d), m=m & ~g

44. Алгоритм з’ясування можливості доступу з заданими правами (3/3) • Після кожної ітерації циклу здійснюється перевірка m • Якщо m=0, це означає, що всі запитані права вже надані, при цьому цикл завершується і потоку надається доступ до об’єкта за списком методів, що заданий маскою g • Якщоm=d, цеозначає, що всі запитані і досі не надані права вже заборонені, при цьому цикл завершується і потоку доступ до об’єкта не надається • Якщо досягнуто кінець DACL, і деякі із запитаних прав доступу ще не надані (m≠0), доступ до об’єкта забороняється • Якщо всі права доступу надані, але в маркері доступу потоку, що викликає, є хоча б один обмежений SID, тоді система повторно сканує DACL у пошуку ACE, маски доступу яких відповідають наборові запитаних прав доступу • При цьому, також йде пошук ACE, SID яких збігається з будь-яким з обмежених SID потоку, що викликає. Потік отримує доступ до об’єкту, якщо запитані права доступу надавались після кожного проходу по DACL

45. Особливості алгоритмів з’ясування прав доступу • Поведінка обох алгоритмів перевірки прав доступу залежить від відносного розташування ACE, що дозволяють та що забороняють • Вбудовані засоби Windows завжди організують DACL таким чином, що передують ACE, що забороняють • Обробка DACL системою захисту при кожному використанні визначнику процесом була б неефективною, тому SRM перевіряє права доступу тільки при відкриванні визначнику, а не при кожному його використанні • Таким чином, якщо процес один раз вдало відкрив визначник, система захисту не може анулювати надані при цьому права доступу – навіть коли DACL об’єкту змінився • Оскільки код режиму ядра звертається до об’єктів за покажчиками, а не за визначниками, то при використанні об’єктів операційною системою права доступу не перевіряються. Інакше кажучи, виконавча система Windows повністю довіряє собі в сенсі захисту. • Власник об’єкта завжди отримує право на запис DACL при доступі до об’єкту • Це право надається через привілей власника ще до початку перевірки DACL • Його буде надано навіть якщо з якихось причин DACL об’єкту пустий • Власник привілею захоплення у власність (наприклад, адміністратор) має доступ до будь-якого об’єкту в системі • Маючи привілей заволодіння у власність, користувач може відкрити об’єкт з правом “запис власника” (Write-Owner Permission) і змінити власника на “Администратор” • Після цього він може закрити об’єкт і повторно відкрити його з правом доступу до DACL для запису, а потім змінити DACL так, щоб обліковому записові адміністратора був наданий повний доступ до об’єкту.

46. Архітектура підсистеми автентифікації Windows

47. Архітектура підсистеми автентифікації Windows • На верхньому рівні підсистеми автентифікації знаходиться процес автентифікації WinLogon.exe • Цей процес є звичайним процесом Win32, що виконується від імені псевдокористувача SYSTEM • Процес автоматично запускається під час старту ОС і залишається активним до вимикання живлення комп’ютера або перезавантаження ОС • В разі аварійного завершення WinLogon, здійснюється примусове аварійне завершення роботи всієї ОС ( “блакитний екран”). • Більшість високорівневих функцій процесу автентифікації реалізуються бібліотеками-провайдерами • Наприклад, msgina.dll – провайдер локального входу в систему • Якщо в системі встановлено програмне забезпечення, що підтримує вхід користувачів з віддалених терміналів (наприклад, сервер Telnet), то це програмне забезпечення повинно зареєструвати свого провайдера • На середньому рівні головну роль грає локальний розпорядник безпеки (LSA) і так звані пакети автентифікації – бібліотеки, що реалізують більшість низкорівневих функцій автентифікації. • LSA виконується в процесі lsass.exe в режимі користувача і від імені псевдокористувача SYSTEM • LSA також передовіряє більшість своїх функцій бібліотекам, що заміняються • Стандартна схема автентифікації реалізується пакетом MSV (бібліотека msv1_0.dll) • На нижньому рівні підсистеми автентифікації знаходяться сховища облікових записів користувачів, в тому числі еталонних образів паролів. В стандартній конфігурації ОС нижній рівень підсистеми автентифікації включає: • базу даних SAM • використовується для отримання даних з реєстру локального комп’ютера • сервіс NetLogon, • використовується для отримання даних з контролера домену.

48. Послідовність входу користувача в систему (1/2) • Провайдер отримує від користувача інформацію, що ідентифікує та автентифікує його • В стандартній конфігурації: • інформація, що ідентифікує, – це умовне ім’я користувача • інформація, що автентифікує – це пароль • Провайдер здійснює автентифікацію, передаючи інформацію, що ідентифікує та автентифікує користувача, на середній рівень • Для цього використовується системний виклик LogonUser • На середньому рівні пакет автентифікації отримує від верхнього рівня інформацію, що ідентифікує та автентифікує користувача. • Пакет автентифікації генерує образ пароля • Звертаючись до нижнього рівня підсистеми, пакет автентифікації отримує еталонний образ пароля і здійснює його порівняння з образом пароля, що він отримав з верхнього рівня

49. Послідовність входу користувача в систему (2/2) • У разі збігу паролів, LSA отримує з нижнього рівня інформацію про те, чи може цей користувач в цей момент розпочинати роботу з системою • чи не застарілий пароль? • чи не заблоковано обліковий запис користувача? • тощо • При позитивному результаті останньої перевірки LSA створює маркер доступу користувача • Для цього LSA додатково отримує всю необхідну інформацію з нижнього рівня підсистеми автентифікації • Сформований маркер доступу повертається на верхній рівень підсистеми • Якщо маркер доступу було створено успішно, провайдер здійснює авторизацію користувача • Для цього він запускає процес UserInit.exe від імені користувача, якого щойно було автентифіковано • Процес UserInit: • завантажує індивідуальні настроювання цього користувача • монтує його ключ реєстру • завантажує програмне середовище (Explorer)

50. Особливості підсистеми автентифікації Windows • Архітектура підсистеми авторизації досить гнучка і дозволяє використовувати будь-які способи перевірки істинності • WinLogon використовує привілеї псевдокористувача SYSTEM створювати маркери доступу і призначати маркери доступу процесам. • Якщо не надати ці привілеї псевдокористувачу SYSTEM, то вхід користувачів в систему стане неможливим. • Образи паролів зберігаються в спеціальному розділі реєстру • Авторизація користувача може відбуватися як локально, так і делегуватися контролерові домену • Windows за допомогою оснастки керування обліковими записами локальних користувачів і групами забезпечує широкі можливості по керуванню обліковими записами користувачів • Для кожного користувача може бути задано ряд атрибутів, таких як належність до груп, місцезнаходження профілю користувача (user profile), робочі години, повноваження на доступ по комутованим лініям і т.д. • Крім того, може бути задана політика керування обліковими записами, що регламентує: • мінімальний та максимальний терміни життя паролю; • мінімальну довжину паролю; • унікальність паролю як вимога не належати до заданої кількості востаннє використаних; • кількість невдалих спроб автентифікації, після яких обліковий запис блокується, та відрізок часу, протягом якого вони мають відбутися; • тривалість блокування облікового запису. • Також ця оснастка дозволяє • призначати користувачам привілеї (права на всю систему, а не на конкретний об’єкт) • задавати політику аудиту.