Жихаревич В.В. Операційні системи: лабораторний практикум

Подождите немного. Документ загружается.

241

них ситуаціях для отримання конфіденційної інформації існують

простіші способи.

Захист від зовнішнього нав’язування

Відповідно до політики безпеки операційна система повинна

захищати себе від зовнішнього впливу або нав’язування, такого

як модифікація завантаженої системи або системних файлів, що

зберігаються на диску. Щоб задовольнити вимогам політики без-

пеки, в ОС Windows вбудовані засоби захисту файлів (Windows

File Protection, WFP), які захищають системні файли навіть від

змін із боку користувача з адміністративними правами. У основі

захисту лежать засоби фіксації змін у системних файлах. Дана

міра, безумовно, підвищує стабільність системи.

Згідно з документацією, моніторингу і захисту підлягають усі

файли, що поставляються у складі ОС, з розширеннями sys, dll,

exe і ocx, а також деякі шрифти TrueType (Micros.ttf, Tahoma.ttf і

Tahomabd.ttf). Якщо з’ясовується, що файл підмінено, він заміню-

ється копією з каталога %systemroot%\system32\dllcache, на який

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

для цього каталогу, не достатній, то в ньому зберігаються копії не

всіх системних файлів. У тих випадках, коли робиться спроба

видалення системного файла і при цьому його не опиняється в

каталозі dllcache, система намагається відновити його з установо-

чного компакт-диска ОС Windows або з мережних ресурсів.

Окрім того, адміністратор системи за допомогою утиліти

Sfc.exe (system file checker) може здійснити перевірку коректності

версії всіх системних файлів. Відомості про файли з некоректним

номером версії заносяться в протокол. Коректність системних

файлів перевіряється за допомогою механізму електронного під-

пису і до непідписаних файлів слід ставитися з обережністю. Для

перевірки підпису і виявлення непідписаних файлів служить шта-

тна утиліта SigVerif.exe.

Як самостійне завдання спробуйте видалити який-небудь сис-

темний файл із каталогу Windows\system32, наприклад sol.exe

(гра "косинка").

242

Маркер доступу. Контекст користувача

Як уже мовилося, найбільш важливою характеристикою

суб’єкта є маркер доступу. Зазвичай маркер створюється при ін-

терактивному вході користувача в систему і зберігає відомості

про контекст користувача. Спочатку маркер зв’язується з проце-

сом-оболонкою Windows Explorer, а потім усі процеси, породжені

користувачем під час сеансу роботи, одержують дублікат даного

маркера. Важливо розуміти, що самостійно створити маркер до-

даток користувача не може. Це може зробити тільки служба

Lsass.

Раніше були розглянуті характеристики маркера як однієї з

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

описані можливості тоншої настройки контексту користувача за

допомогою функцій, зорієнтованих на роботу з маркером доступу

відповідно до принципу мінімуму привілеїв. Принцип мінімаль-

них привілеїв рекомендує виконання всіх операцій із мінімаль-

ними привілеями, необхідними для досягнення результату. Це

дозволяє зменшити втрати від спроб навмисного збитку й уник-

нути випадкових втрат даних. Наприклад, користувачу не реко-

мендується реєструватися як адміністратор системи без необхід-

ності. (В крайньому випадку, можна вдатися до послуг штатної

утиліти runas, яка дозволяє запускати додатки від імені іншого

облікового запису.)

Для безпечної роботи в дусі принципу мінімуму привілеїв ОС

Windows підтримує механізми створення маркерів з обмеженими

привілеями і запозичення маркера. Перший дозволяє вилучити з

маркера певні привілеї, наявність яких при виконанні даної опе-

рації не потрібна, а другий дозволяє запускати додатки від імені

іншого облікового запису. API системи дозволяє впливати на пе-

релік діючих привілеїв маркера, дублювати маркер, щоб його міг

запозичувати інший процес, розв’язувати проблеми перевтілення

і створення обмежених маркерів

Зчитування відомостей про привілеї користувача з марке-

ра доступу

У попередній лабораторній роботі описані привілеї користува-

ча (розділ "ролевий доступ") і основні функції для зчитування

243

інформації з маркера (OpenProcessToken, GetTokenInformation) у

розділі "суб’єкти". Для отримання списку привілеїв із маркера за

допомогою функції GetTokenInformation потрібно для параметра

TokenInformationClass, вибрати значення TokenPrivileges. Раніше

ми вже одержували перелік привілеїв облікового запису. Перелік

привілеїв, що входять до складу маркера, істотно ширше, оскіль-

ки включає привілеї користувача і привілеї груп, до складу яких

входить користувач.

Дослідження роботи програми отримання списку привіле-

їв із маркера доступу процесу

Як самостійний приклад складіть програму, завдання якої –

отримання переліку привілеїв користувача і його груп із маркера

доступу даного процесу.

Суть роботи складеної програми – одержати описувач поточ-

ного процесу за допомогою функції OpenProcessToken і застосу-

вати функцію GetTokenInformation для витягування з нього спис-

ку привілеїв. Функція LookupPrivilegeName дозволяє одержати

програмне ім’я привілею по її локальному ідентифікатору (Luid),

а функція LookupPrivilegeDisplayName перетворить програмне

ім’я привілею в дружнє ім’я.

Включення і відключення привілеїв у маркері

Велику частину інформації в маркері змінювати не можна.

Наприклад, не можна ні додати, ні видалити привілей. Можли-

вість додавання привілеїв у маркер була б "глибоким підкопом

під систему захисту Windows". Останнє означає, що зміна приві-

леїв суб’єкта – прерогатива підсистеми локальної авторизації

(LSA) і повинна здійснюватися централізовано тільки за допомо-

гою функцій сімейства LSA.

Отже, сформувати список привілеїв у маркері не можна, зате

їх можна відключати і включати. Для включення і відключення

певних привілеїв служить функція AdjustTokenPrivileges.

Перевтілення

У ОС Windows є цікаві можливості виконання коду з марке-

ром, відмінним від маркера даного процесу. Це, наприклад, істо-

тно для серверів, які повинні виступати від імені і з привілеями

клієнтів. Одна з таких можливостей – запуск нового процесу з

244

вказаним маркером за допомогою функції CreateProcessAsUser.

Ця функція є аналогом функції CreateProcess, за винятком пара-

метра hToken, який указує на маркер, що визначає контекст кори-

стувача нового процесу.

Інший спосіб виконати код із запозиченим маркером – здійс-

нити перевтілення (impersonation). Перевтілення означає, що

один із потоків процесу функціонує з маркером, відмінним від

маркера поточного процесу. Зокрема, клієнтський потік може пе-

редати свій маркер доступу серверному потоку, щоб сервер міг

дістати доступ до захищених файлів і інших об’єктів від імені

клієнта. Згодом потік може повернутися в нормальний стан, тоб-

то використовувати маркер процесу.

Windows не дозволяє серверам виступати в ролі клієнтів без їх

відома. Щоб уникнути цього, клієнтський процес може обмежити

рівень імперсонації. Тому для участі в перевтіленні маркер пови-

нен мати відповідний рівень перевтілення. Цей рівень визнача-

ється параметром маркера TokenImpersonationLevel і може бути

запитаний функцією GetTokenInformation. Для процесу перевті-

лення важливо, щоб цей параметр мав значення не нижче за

SecurityImpersonation, що означає можливість імперсонації на ло-

кальній машині. Значення SecurityDelegation дозволяє серверному

процесу виступати від імені клієнта як на локальному, так і на

віддаленому комп’ютері. Останнє значення має відношення до

делегування, яке є природним розвитком перевтілення, але пра-

цює тільки за наявності домена і функціонуванні активного ката-

логу. За замовчуванням встановлюється рівень

SecurityImpersonation.

Маркер перевтілення зазвичай створюють шляхом дублюван-

ня існуючого маркера і додання йому потрібних прав доступу і

рівня імперсонації. Це можна зробити за допомогою функції

DuplicateTokenEx. Власне, перевтілення здійснюється за допомо-

гою функції ImpersonateLoggedOnUser. Щоб повернутися в почат-

ковий стан, потік повинен викликати функцію RevertToSelf.

Важливо також не забувати, що коли перевтілений потік здій-

снює доступ до об’єкта, то решта потоків процесу, навіть не пере-

втілених, також має до нього доступ. Подібні ситуації вимагають

245

ретельного аналізу, оскільки тут можуть виникати важко відсте-

жувані помилки.

Дослідження роботи програми запозичення маркера до-

ступу й отримання з нього потрібної інформації

Як самостійну вправу рекомендується написати програму, за-

вдання якої – створити маркер доступу з потрібним рівнем пере-

втілення для вказаного облікового запису, і передати його поточ-

ному процесу. Потім для контролю потрібно вивести на екран

основні характеристики цього (що вже став поточним) маркера,

наприклад перелік привілеїв, після чого повернути значення по-

точного маркера до початкового і ще раз витягнути з нього приві-

леї.

Інші можливості настройки контексту користувача

У ОС Windows є й інші можливості настройки контексту кори-

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

принципу мінімуму привілеїв. Як приклад можна навести схему

контролю доступу за допомогою маркерів, які називаються обме-

женими. Обмежені маркери створюються функцією

CreateRestrictedToken. У цей маркер у момент його створення мо-

жна внести такі зміни: видалити привілеї, відключити деякі SID-

ідентифікатори і додати "обмежені" SID’и облікових записів.

Останні просто додають ряд нових перевірок до тих, що вже іс-

нують при організації доступу до об’єкта. Обмежені маркери зру-

чні, коли додаток підміняє клієнта при виконанні коду, здатного

завдати збитку системі.

Висновок

У даній лабораторній роботі описана структура менеджера

безпеки ОС Windows. Система захисту даних повинна задоволь-

няти вимогам, сформульованим у ряді нормативних документів,

які визначають політику безпеки. Далі в роботі описані можливо-

сті настройки привілеїв облікового запису. Підтримка моделі ро-

левого доступу пов’язана із завданнями переліку, додавання і від-

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

ступу суб’єкта.

Відповідно до політики безпеки, в системі реалізовані: аутен-

тифікація користувачів, аудит і захист від повторного викорис-

246

тання об’єктів. Успішна аутентифікація закінчується формуван-

ням маркера доступу, який передається всім процесам користува-

ча протягом сеансу роботи. Для спостереження за діями користу-

вачів підтримується журнал, де можна фіксувати всі події, які

можуть вплинути на стан безпеки системи. Зануління сторінок

пам’яті перед виділенню їх процесу покликане не допустити зчи-

тування інформації, що залишилася від їх колишнього власника.

У ОС Windows є захист від модифікації системних файлів, яка

базується на фіксації змін у файлах і заміні спотворених систем-

них файлів їх резервною копією. Для тонкої настройки контексту

користувача відповідно до складних сценаріїв захисту підтриму-

ється механізм перевтілення.

Практична частина

1. Складіть програми, рекомендовані як самостійні вправи.

Запустіть програми та переконайтеся, що вони працюють прави-

льно (згідно з описом алгоритму їх роботи).

4. Оформіть звіт із виконаної лабораторної роботи, який пови-

нен містити текст програм, демонстрацію результатів роботи, та

дайте відповіді на контрольні запитання.

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

1. Опишіть структуру системи безпеки ОС Windows.

2. Яке призначення політики безпеки?

3. Розкрийте зміст поняття привілею.

4. Наведіть перелік програмних імен привілеїв облікового

запису групи.

5. Які АРІ-функції управління привілеями ви знаєте?

6. Розкрийте зміст поняття аутентифікації користувача.

7. Які інструменти виявлення вторгнень в ОС ви знаєте?

8. Обґрунтуйте необхідність захисту від повторного викорис-

тання об’єктів. Наведіть методи захисту.

9. Обґрунтуйте необхідність захисту від зовнішнього

нав’язування. Наведіть методи захисту.

10. Розкрийте зміст поняття перевтілення. Для чого воно викори-

стовується?

247

Список літератури

1. Шеховцов В.А. Операційні системи. – К.: Видавнича група

ВHV, 2005. – 576 с.

2. Саймон Р. Windows 2000 API. – СПб.: Питер, 2002. – 1085 с.

3. Таненбаум Э., Вудхалл А. Операционные системы: разработ-

ка и реализация. – СПб.: Питер, 2006. – 576 с.

4. Олифер В.Г., Олифер Н.А. Сетевые операционные системы. –

СПб.: Питер, 2002. – 544 с.

5. Таненбаум Э. Современные операционные системы. – 2-е изд.

– СПб.: Питер, 2002. – 1040 с.

6. Щупак Ю. А. Win32 API. Эффективная разработка приложе-

ний. – СПб.: Питер, 2007. – 572 с.

7. Побегайло А. П. Системное программирование в Windows. –

СПб.: БХВ-Петербург, 2006. – 1056 с.

8. Вильямс А. Системное программирование в Windows для

профессионалов. – СПб.: Питер, 2007. – 572 с.

9. Илюшкин Б. И. Операционные системы. Процессы и потоки:

Учебное пособие. – СПб.: СЗТУ, 2005. – 103 с.

10. Румянцев П. В. Азбука программирования в Win32 API. –

СПб.: Питер, 2000. – 310 с.

11. Безбогов, А.А. Безопасность операционных систем: Учебное

пособие. – М.: Машиностроение-1, 2007. – 220 с.

12. Рощин А.В. Операционные системы. Часть 1. Основы управ-

ления ресурсами: Учебное пособие. – М.: МГУПИ, 2007. –

119 с.: ил.

13. Харт Д. М. Системное программирование в среде Windows –

3-е изд. – М.: Издательский дом «Вильямс», 2005. – 592 с.

14. Румянцев П.В. Работа с файлами в WIN 32 API. – СПб.: Пи-

тер, 2005. – 197 с.

15. Финогенов К.Г. WIN 32 Основы программирования. 2-е изд.

– М.: Диалог МИФИ, 2006. – 416 с.

248

Навчальне видання

Операційні системи

Методичні рекомендації до лабораторних робіт

Укладач Жихаревич Володимир Вікторович

Відповідальний за випуск Остапов С.Е.

Літературний редактор Колодій О.В.

Друкарня видавництва “Рута”

Чернівецького національного університету ім. Ю. Федьковича

58012, Чернівці, вул. Коцюбинського, 2