BOS Merged

Київський політехнічний інститут імені Ігоря Сікорського
Навчально-науковий Фізико-технічний інститут

Кафедра інформаційної безпеки
Безпека
операційних
систем
Лекція 01
Автор курсу: Грайворонський Микола Владленович

Основні питання
 Спочатку нагадаємо концептуальний
підхід до захисту інформації
 А потім розберемось із структурою
курсу
Безпека ОС - Лекція 01 2/4

Які поняття вам необхідно
знати і пам’ятати
 Інформаційно-телекомунікаційна система
 Політика безпеки
 Властивості інформації (КЦД або CIA)
 Безпека інформації
 Загроза, атака, вразливість
 Модель політики безпеки
 Модель загроз, модель порушника
 Захищена ІТС
План лекційного курсу
1) Модель загроз для ОС

2) Концепція розробки захищених ОС
3) Комплекс засобів захисту ОС
4) Стандарти оцінювання безпеки ОС (НД ТЗІ, ISO
15408)
5) Засоби захисту ОС Windows
6) Засоби захисту ОС Linux
7) Засоби захисту ОС Android
8) Апаратні засоби як основа механізмів захисту
ОС (на прикладі архітектури процесорів x86)

Безпека
систем
Лекція 02. Модель загроз для операційної системи

Основні питання
 Спочатку нагадаємо концептуальний
підхід до захисту інформації
 А потім розберемось із структурою
курсу

Етапи побудови засобу
захисту
1. Формування вимог
2. Розроблення моделі загроз
3. Розроблення політики безпеки, моделі
безпеки
4. Розроблення технічного завдання (ТЗ)
5. Проектування
6. Реалізація
7. Тестування (сертифікація)
8. Впровадження
9. Супроводження
Модель загроз для операційної
системи (класична)
 Сканування файлової системи

 Викрадення ключової інформації
 Підбирання паролів
 Збирання сміття
 Перевищення повноважень
 Програмні закладки
 Жадібні програми

Сканування файлової
системи 1/2
 Ця загроза полягає в тому, що порушник переглядає (сканує) всю
файлову систему, і намагається прочитати усі файли поспіль
 Замість зчитування порушник може намагатись скопіювати або видалити файли
 Якщо порушник не може отримати доступ до деякого об’єкта файлової системи
(окремого файлу або каталогу), то він(вона) пропускає захищений об’єкт і
продовжує сканування
 Порушник може здійснювати цю атаку, використовуючи спеціальне програмне
забезпечення
 Сканування файлової системи – це в першу чергу атака на політику
безпеки
 Будь-який користувач в системі повинен отримати доступ лише до тих файлів, до
яких він повинен мати доступ згідно політики безпеки
 Якщо порушник в результаті сканування отримує доступ до інших файлів, він
порушує політику безпеки, тобто здійснює НСД (несанкціонований доступ)
 При цьому порушник отримує можливість несанкціоновано ознайомитись з
інформацією (порушення конфіденційності), або несанкціоновано модифікувати
або видалити інформацію (порушення цілісності)

Сканування файлової
системи 2/2
 В подальшому ми взагалі не будемо розглядати ті ОС, які не
здійснюють контроль доступу до файлів
 Але й ті ОС, що такий контроль (керування, аудит) здійснюють, можуть бути
атакованими
 Можливість НСД до об’єктів файлової системи визначається
наявністю її вбудованої системи розмежування доступу і
коректністю її адміністрування
 У сучасних англомовних термінах — IAAA (Identification, Authentication,
Authorization, Accountability), тобто ідентифікація, автентифікація,
авторизація, підзвітність
 Оскільки звичайна файлова система містить величезну кількість об’єктів,
помилки в настроюванні виникають з великою ймовірністю
 Джерелом атаки може бути будь-який легальний користувач
системи
 Цю атаку може здійснювати анонімний користувач (гість), якщо можливість
анонімного входу в систему не заблокована

Викрадення ключової
інформації
 На рівні ОС використовується різна інформація, яку можна віднести до
ключової. Найпоширеніший вид такої інформації – паролі доступу до системи
 Такий спосіб атак на паролі називають “не-електронні атаки” (non-electronic
attacks)
 Типові способи викрадення паролів:
 Соціальна інженерія (social engineering)
 Підглядання пароля в момент, коли користувач його набирає (shoulder surfing)
 На клавіатурі — достатньо всього кілька тижнів тренувань для того, щоби фіксувати пароль за рухами рук
користувача по клавіатурі
 На екрані — хоча усі сучасні ОС приховують і не демонструють пароль, що вводиться, його видно:
- якщо його помилково вводять у інше поле введення

- коли його вводять як аргумент в командному рядку
- у командних файлах (сценаріях)
 Викрадення паролів, що записані або роздруковані на папері (dumpster diving)
 якщо використовуються зовнішні носії ключової інформації (дискети, пристрої флеш-пам’яті, токени), то ці
носії можуть бути просто викрадені
 При тимчасовому фізичному доступі до комп’ютера — отримання паролів, що ненадійно
зберігаються
 іноді паролі ховаються у деякому файлі у відкритому вигляді
 часто паролі ненадійно кодують (наприклад, за допомогою операції XOR)

Підбирання паролів
 Підбирання паролів передбачає використання засобів автентифікації
для знаходження того пароля, який буде прийнятий як правильний
 Порушник отримує несанкціонований доступ до певного ресурсу, якщо пароль
використовується для обмеження доступу до ресурсу
 або можливість працювати в системі від імені іншого користувача, якщо пароль
використовується для автентифікації
 Будь-яка система передбачає можливість того, що користувач під час
введення пароля зробив помилку, тому введення пароля можна
повторити
 Раніше кількість таких повторів не обмежувалась, а швидкість їх введення
визначалась лише можливостями користувача
 Це надавало можливість порушникам методично перебирати ймовірні паролі
 Ще більшу небезпеку несла в собі можливість застосування спеціальних програмних
засобів, які здійснюють спроби автентифікації
 Програмні засоби здатні тривалий час без утоми повторювати спроби автентифікації,
 Вони можуть робити такі спроби із значно більшою швидкістю, ніж користувач-людина
 Також вони можуть використовувати словники, відсортовані з урахуванням частоти
використання тих чи інших паролів

Підбирання паролів —
різновиди атаки
 Активні атаки онлайн (Active Online Attacks)
 Вгадування паролів (Password Guessing) — в загальному випадку передбачає певні
знання про жертву, що дозволяють передбачити, який пароль він(вона) могли б обрати
 Атака за словником (Dictionary Attack) — зазвичай дуже ефективна, якщо жертва не дуже
вибаглива у вигадування паролів
 Повний перебір (Brute Forcing Attack) — в решті-решт дасть результат, але потрібний на
це час може бути неприйнятно тривалим
 Також до активних атак онлайн відносять фішинг (phishing), ін’єкції хешу (hash injection),
LLMNR/NBT-NS poisoning, застосування троянів, spyware, клавіатурних шпигунів
(keyloggers) тощо
 Пасивні атаки онлайн (Passive Online Attacks)
 В таких атаках порушник прослуховує або записує дані, що проходять комунікаційним
каналом, а потім використовує ці дані для проникнення в систему
 Sniffing
 Man-in-the-Middle
 Атака відтворення (Replay Attack)
 Атаки оффлайн (Offline Attacks)
 В таких атаках порушник намагається відтворити пароль з (раніше отриманого) файлу
хешів
 Для підвищення ефективності застосовують Rainbow Tables

Підбирання паролів —
протидія
 В усіх сучасних системах автентифікації
вживаються заходи, які суттєво послаблюють
цю загрозу
 Основні такі заходи:
 обмеження швидкості введення паролів шляхом
введення штучних затримок в процедуру їх перевірки
 обмеження кількості спроб введення паролів (як правило
до 3...5), після чого система автентифікації на певний час
блокує подальші спроби введення паролів з тієї консолі
 реєстрація спроб автентифікації
 негайне повідомлення адміністратора про повторні
невдалі спроби автентифікації, тощо

Збирання сміття
 Збирання сміття – це отримання даних, які залишаються у
об’єктах, що звільняються ОС після їх використання
 Найтиповішими з таких об’єктів є файли на дисках і ділянки оперативної
пам’яті
 У більшості файлових систем файли після їх видалення не
знищуються фізично, а лише помічаються як знищені
 Сектори диску, які були відведені для цього файлу, вважаються вільними, і на
них можуть бути записані частини інших файлів. Але до нового запису вони
продовжують містити дані, які знаходились у видаленому файлі
 Здійснюючи прямий доступ до секторів диску, можна прочитати цю
інформацію
 Саме такий принцип використовують програми відновлення помилково видалених файлів
 Збирання сміття можливе навіть у серверних файлових системах, де
відновлення видалених файлів вкрай малоймовірне (і тому серверні ОС не
мають утиліт відновлення помилково видалених файлів)
 Наприклад, у багатозадачній серверній ОС може бути запущений окремий процес, який
постійно переглядає вміст секторів диску, що звільняються

Збирання сміття —
тимчасові файли
 Простий спосіб збирання сміття – копіювання і вивчення
тимчасових файлів
 Практично усі програми для роботи створюють тимчасові файли, які
вилучаються по завершенні роботи програми або після закриття робочого
файлу
 Досить часто з різних причин ці файли не вилучаються
 Велику цінність має вміст “файлу підкачування”, який
створюється для реалізації механізму віртуальної пам’яті
 Деякі дуже інформативні для порушників файли можуть виникати
під час збоїв
 наприклад, дамп ядра системи (записаний на диск у вигляді файлу вміст
системних областей оперативної пам’яті)
 У більшості сучасних систем для мінімізації наслідків
помилкового вилучення файли, які вилучають, копіюють у
спеціальне сховище – “кошик для сміття” (trash bin), звідки їх
можна повністю відновити

Збирання сміття
в оперативній пам'яті
 Стосовно оперативної пам’яті комп’ютера можна
зазначити, що звичайні ОС не утрудняють собі життя її
очищенням
 Оскільки очищення пам'яті (заповнення її нулями) вимагає певних
ресурсів, а користувачеві результатів цієї операції не видно, для
більшості звичайних користувачів виконання такого очищення
виглядало б як неефективна робота (зниження швидкодії) системи
 Коли прикладна програма запитує додаткову пам’ять, їй
виділяють ділянки пам’яті, що продовжують зберігати
дані попередніх програм, які ці ділянки використовували
 Нормальні прикладні програми починають використання пам'яті з її
ініціалізації
 Можна (і неважко) написати програму, яка буде захоплювати пам’ять
і копіювати із щойно захопленої пам’яті цікаві дані
 наприклад, здійснюючи пошук за ключовими словами

Перевищення повноважень
 Ця загроза полягає у тому, що порушник
якимось чином отримує повноваження, що
перевищують ті, які йому надані згідно
політики безпеки
 Перевищення повноважень можливе
 або через помилки в розробці й реалізації
політики безпеки (наприклад, невірні
настроювання системи розмежування доступу)
 або шляхом використання наявних вразливостей
в програмному забезпеченні, яке входить до
складу ОС
Перевищення повноважень
користувачів Unix-подібних ОС
 Категорії користувачів в Unix-подібних ОС:
 Адміністратор
 У більшості класичних Unix-подібних ОС він має властивості суперкористувача, тобто повні і необмежені права в
системі
 Спеціальний користувач
 Це “фіктивні” користувачі, від імені яких виконуються деякі системні процеси
 Такі користувачі можуть мати значні повноваження стосовно окремих захищених об’єктів системи, а повноваження
стосовно інших об’єктів – навпаки, менші за звичайних користувачів
 Як правило, облікові записи спеціальних користувачів не можуть використовуватись для здійснення інтерактивного
входу в систему.
 Звичайний користувач
 Псевдокористувач
 До цієї категорії належать користувачі, які не реєструються в системі, але виконують в ній певні дії шляхом
взаємодії з системними процесами – демонами (англ. – daemon), як правило, через мережу. Самі демони працюють
в системі з великими повноваженнями, і безпека взаємодії з псевдокористувачами цілком залежить від коректності
їхнього програмного коду
 Отже, перевищення повноважень реалізується при будь-якому несанкціонованому
переході користувача з нижчої категорії до вищої. Типовими загрозами є перехід:
 з категорії 3 до 1 (звичайний користувач отримав права адміністратора),
 з 4 до 3 (псевдокористувач отримав можливість інтерактивно працювати в системі з правами
користувача)
 і з 4 до 1 (те ж саме, але з правами адміністратора)

Програмні закладки
 До програмних закладок відносять програми або окремі модулі програм, які протягом
тривалого часу функціонують в комп’ютерній системі, здійснюючи заходи щодо
приховування свого існування від користувача
 Найгірший варіант — rootkit
 Програмні закладки можуть впроваджуватись вірусом, “троянським конем”, мережним
хробаком або безпосередньо користувачем-зловмисником
 Функції програмних закладок:
 перехоплення і передавання інформації:
 крадіжка паролів;
 шпигунські програми (Spyware);
 порушення функціонування систем (“логічні бомби”):

 знищення інформації;
 зловмисна модифікація інформації;
 блокування системи (у тому числі Ransomware, хоча для цього не обов’язково встановлювати програмну закладку);
 модифікація програмного забезпечення:

 утиліти віддаленого адміністрування (люки — backdoors);
 організація DoS і DDoS атак (Botnet);
 майнінг криптовалют;
 несанкціонована робота з мережею і телефоном (Інтернет-клікери, проксі-сервера, дзвінки на платні ресурси тощо);
 психологічний тиск на користувача:

 реклама (Adware);
 злі жарти і містифікації.

Жадібні програми
 Жадібні програми – це шкідливі програми, які
захоплюють значну частину ресурсів
комп’ютера, внаслідок чого робота інших
користувачів та/або процесів помітно
утруднюється або взагалі стає неможливою
 Жадібні програми можуть призводити до краху ОС
 Здебільшого, жадібні програми належать до
класу “троянських коней”
 Жадібні програми можуть бути Web-
застосунками, які запускаються при заході
браузером на певні Web-сторінки
Доповнення класичної
моделі
 Шкідливі функції прикладних програм
 Можуть бути прихованими і тривалий час не проявлятись
 Прикладна програма має доступ до файлів користувача і може
здійснювати НСД не компрометуючи ОС
 Протидія — встановлення програм з магазину прикладних
програм, обмеження домену прикладних програм (як наприклад
в Android), перевірка функцій прикладних програм в процесі
роботи
 Атаки на систему оновлення
 Намагання впровадити оновлення з неавторизованого джерела
 Атаки на “ланцюг постачання” (репозиторій)
 Атаки на криптографічну підсистему

Методика STRIDE
 Фактично, STRIDE — це саме модель загроз
1) Підміна мережних об’єктів (Spoofing identity)
2) Модифікація даних (Tampering with data)
3) Відмовлення від авторства (Repudiation)
4) Розголошення інформації (Information disclosure)
5) Відмова в обслуговуванні (Denial of service)
6) Підвищення привілеїв (Elevation of privilege)
 Питання:
1) Чи можна її застосувати до ОС безпосередньо?
2) На якій стадії?
Методика STRIDE
насправді
 Це методика розроблення безпечних
програм, яку пропонують компанії Microsoft і
Symantec
 Складається з певних етапів:
1) Декомпозиція програми на складові
 Застосування DFD – Data Flow Diagrams
2) Визначення (моделювання) загроз
 Застосування методики STRIDE
3) Ранжування загроз (оцінка ризиків)
 Застосування методики DREAD
4) Запобігання загрозам
DFD – діаграми потоків
даних – умовні позначення
Процес Межа
Перетворення Межі між машинами,
або оброблення областями з різним
даних рівнем безпеки,
адресного простору
Група тощо
процесів
Перетворення Зовнішній суб’єкт
або оброблення Зовнішнє джерело
даних даних
Сховище Потік даних

даних Автентифіковані Описує потоки даних
Місце зберігання дані зі сховищ даних,
тимчасових або процесів і зовнішніх
постійних даних суб’єктів

Застосування DFD-діаграм 1
Інтрамережа Центр даних
3.0 Запит на
Адміністратор адміністративну дію
Відгук на
адміністративну
дію
0.0
Запит Програма
1.0 інформації Відповідь на розрахунку
Користувач про зарплату запит зарплати
про зарплату
2.0
Web-розробник Оновлені
файли Записи
журналу
аудиту
4.0
Аудитор

Застосування DFD-діаграм 2
6.0 12.0
Дані автентифікації Дані по зарплаті
Атрибути Статус
Запит Запит Запит Дані
інформації про інформації
зарплату про Запит
зарплату
5.0 9.0
11.0
1.0 Оброблення Застосування
Доступ до
Користувач клієнтських політики
даних
запитів даних
Відповідь
на запит Відповідь
Дані
інформації на запит Новий
про інформації запис
зарплату про зарплату
Інтрамережа Центр даних 13.0
Межа
машини Журнал аудиту
Підхід Common Criteria
(ISO/IEC 15408)
 Критерії, що застосовують для оцінювання безпеки продуктів
інформаційних технологій (ПІТ), а також заснований на них
міжнародний стандарт, що застосовують для сертифікації цих
продуктів (зокрема, операційних систем)
 Сертифікацію проводять для так званого “об’єкта оцінювання” (ОО) —
Target of Evaluation (TOE), який може бути ПІТ, може бути частиною ПІТ,
комбінацією декількох ПІТ тощо
 Модель загроз для продукту описують у документах ST
(Security Target — Завдання з безпеки) та PP (Protection Profile
— Профіль захисту) у відповідних розділах
 Сам стандарт не містить переліку можливих загроз — їх
формують розробники названих документів
 Розглянемо приклади профілів захисту для операційних
систем

Controlled Access Protection
Profile (CAPP) — 1999
 Був розроблений як заміна класу C2 зі
стандарту TCSEC (“Оранжева книга”)
 Усі задачі захисту (security objectives)
визначені з організаційних політик
безпеки (organizational security policies)
 Модель загроз у явному вигляді не
сформульована
 На сьогодні є застарілим і для
сертифікації сучасних систем не
використовується
Operating Systems Protection
Profile (OSPP) — 2010
 Визначені:
 Активи (Assets), що підлягають захисту
 Порушники (Threat Agents)
 Загрози (Threats), яким має протидіяти
об’єкт оцінювання (Target of Evaluation,
TOE)
 Надалі: TSF = TOE security functions =

= (нашою мовою) КЗЗ — комплекс засобів
захисту
Активи
 Активи, що підлягають захисту:
 Постійні об’єкти сховища, що застосовуються для зберігання
даних користувача і КЗЗ, у випадках де ці дані мають бути
захищені від будь-якої з названих подій:
 Несанкціонований (unauthorized) доступ на зчитування
 Несанкціонована модифікація
 Несанкціоноване вилучення об’єкту
 Несанкціоноване створення нових об’єктів
 Несанкціоноване керування атрибутами об’єкту
 Тимчасові об’єкти сховища, включаючи дані з мережі
 Функції КЗЗ і пов’язані з ними дані КЗЗ
 Ресурси під керуванням КЗЗ, що застосовуються для зберігання
вищеназваних об’єктів, включаючи метадані, необхідні для
керування цими об’єктами
Агенти загроз
 Агенти загроз — це зовнішні сутності, які потенційно можуть
атакувати ОО. Вони задовольняють щонайменше одному з
наведених критеріїв:
 Зовнішні сутності, які не авторизовані для доступу до активів, можуть
намагатись здійснити до них доступ або удаючи з себе авторизовану сутність
(“маскарад”), або намагаючись використовувати функції КЗЗ без належної
авторизації
 Зовнішні сутності, авторизовані для доступу до певних активів, можуть
намагатись здійснити доступ до інших активів, авторизації на доступ до яких
вони не мають, або шляхом зловживання сервісами, які їм дозволено
використовувати, або удаючи з себе іншу зовнішню сутність (“маскарад”)
 Недовірені суб’єкти можуть намагатись здійснити доступ до активів, на який
вони не авторизовані, або шляхом зловживання сервісами, які їм дозволено
використовувати, або удаючи з себе іншого суб’єкта (“маскарад”)
 Агенти загроз типово характеризуються низкою факторів, таких
як кваліфікація (expertise), доступні ресурси, і мотивація, причому
мотивація напряму пов’язана з цінністю “цільових” активів

Загрози, яким протидіє ОО 1/2
T.ACCESS.TSFDATA (Доступ до даних КЗЗ)

Агент загроз може читати або модифікувати дані КЗЗ без необхідної
авторизації коли ці дані зберігаються або передаються
T.ACCESS.USERDATA (Доступ до даних користувача)
Агент загроз може отримати доступ до даних користувача, що
зберігаються, обробляються, або передаються ОО, без належної
авторизації у відповідності до політики безпеки ОО
T.ACCESS.TSFFUNC (Доступ до функцій КЗЗ)
Агент загроз може використовувати або модифікувати
функціональність КЗЗ без необхідних привілеїв для надання собі або
іншим несанкціонованого доступу до даних КЗЗ або користувачів
T.ACCESS.COMM (Доступ до каналу зв’язку)
Агент загроз може отримати доступ до каналу зв’язку (communication
channel), що встановлює довірені відносини між ОО й іншою
віддаленою довіреною інформаційною системою, або удавати із
себе (masquerade) іншу віддалену довірену інформаційну систему

Загрози, яким протидіє ОО 2/2
T.RESTRICT.NETTRAFFIC (Доступ до мережного

трафіку)
Агент загроз може отримати доступ до інформації або
передавати інформацію іншим абонентам через мережні
канали зв’язку без належної авторизації для такої спроби
обміну з боку політики керування потоками інформації
T.IA.MASQUERADE (“Маскарад”)
Агент загроз може удавати з себе (masquerade) авторизовану
сутність, включаючи сам ОО, або частину ОО, для отримання
несанкціонованого доступу до даних користувача, даних КЗЗ,
або ресурсів ОО
T.IA.USER (Неналежна автентифікація користувачів)
Агент загроз може отримати доступ до даних користувача,
даних КЗЗ, або ресурсів ОО, за винятком загальнодоступних
об’єктів, без ідентифікації та автентифікації

Protection Profile for General
Purpose Operating Systems
 Це — сучасний профіль захисту
(остання редакція — 2018)
 Вимагає лише рівень гарантій 1
(найнижчий!)
 В якості агента загроз розглядають
зловмисника (an attacker)

Модель загроз PPGPOS
T.NETWORK_ATTACK (Мережна атака)
– Зловмисник знаходиться у каналі зв’язку або десь в мережній інфраструктурі
– Зловмисники можуть вступати в інформаційний обмін з прикладними програмами і
сервісами, що працюють під керуванням або є частиною ОС, з метою компрометації
– Такий обмін може бути модифікуванням встановлених легітимних обмінів
T.NETWORK_EAVESDROP (Прослуховування мережі)

– Зловмисник знаходиться на каналі зв’язку або десь в мережній інфраструктурі
– Зловмисники можуть здійснювати моніторинг і отримувати доступ до до даних,
якими обмінюються прикладні програми і сервіси, що працюють під керуванням або
є частиною ОС
T.LOCAL_ATTACK (Локальна атака)
– Зловмисник може скомпрометувати прикладні програми, що виконуються під
керуванням ОС
– Скомпрометована прикладна програма може надавати спеціально (зловмисно)
сформовані дані для ОС через низку каналів обміну, включаючи непривілейовані
системні виклики і обмін повідомленнями через файлову систему
T.LIMITED_PHYSICAL_ACCESS (Обмежений фізичний доступ)
– Зловмисник може намагатись здійснити доступ до даних ОС в умовах обмеженого
часу з фізичним пристроєм

Безпека
систем
Лекція 03. Розроблення захищених операційних систем

Поняття захищеної
операційної системи
 Будемо вважати захищеною таку ОС,

яка передбачає захист від основних
загроз, визначених в ухваленій
моделі загроз
 Якщо ОС передбачає захист лише від
деяких загроз з ухваленої моделі, то
таку ОС іноді називають частково
захищеною
Підходи до побудови
захищених операційних систем
1 Розроблення захищених систем “з

нуля”
2 Побудова так званих “довірених”
(trusted) версій шляхом модернізації
систем, що існують

Розроблення захищених
систем “з нуля”
 При розробці захищених систем “з нуля” на етапі проектування
закладаються усі функціональні можливості та архітектурні
рішення, що розраховані на сертифікацію за встановленим
профілем і рівнем гарантій
 Головною рисою цього підходу є розробка методів гарантованої
реалізації встановлених вимог
 Застосовується класична схема проектування захищених систем:
 визначення вимог безпеки;
 розробка моделі безпеки;
 визначення об’єктів взаємодії;
 визначення правил керування доступом;
 вибір механізмів керування доступом;
 вибір методів ідентифікації й автентифікації сторін, що взаємодіють;
 визначення множини подій, що підлягають аудиту;
 реалізація системи.
Побудова “довірених” версій шляхом
модернізації систем, що існують
 При побудові “довірених” версій шляхом

модернізації систем, що існують, як правило:
 додають функції шифрування і цифрового підпису (в сучасних
ОС ці функції вже впроваджені),
 підсилюють керування доступом шляхом впровадження
мандатного (адміністративного) керування (MAC —
Mandatory Access Control),
 розподіляють обов’язки адміністратора системи між різними
обліковими записами або “ролями” (на практиці це означає,
що в системі також впроваджують рольове керування
доступом, RBAC — Role-Based Access Control),
 впроваджують додаткові засоби ідентифікації й
автентифікації, аудиту та моніторингу.

Порівняння підходів до побудови
захищених операційних систем
 Прикладів розроблення захищених систем “з нуля” небагато через
складність і значну вартість проведення таких робіт
 Лише таким чином вдавалося створити системи, які в подальшому були
сертифіковані на відповідність найвищим класам вимог
 Наприклад, XTS 400 STOP https://www.baesystems.com/en/product/stop-os
 Перевагою побудови “довірених” версій шляхом модернізації систем,
що існують, є економічна ефективність
 Вона зумовлена меншим обсягом робіт з розробки та реалізації системи, а також
можливістю збереження сумісності з рішеннями, що існують
 Модернізовані системи успадковують імідж систем-прототипів, а це підвищує довіру
до них за рахунок репутації фірм-розробників, дозволяє використати наявний досвід
експлуатації й супроводження
 Удосконалення систем, що існують, може привести лише до обмежених (але у
більшості застосувань цілком достатніх) результатів у досягненні безпеки інформації
 Типовими прикладами такого підходу були ОС Тrusted Solaris, СКБД Trusted Oracle.
Сучасним прикладом є SE Linux

Принципи створення
захищених систем
 Принцип інтегрованості
 Принцип інваріантності
 Принцип уніфікації
 Принцип гарантованості
 Принцип коректності

Принцип інтегрованості
 Засоби захисту повинні бути вбудовані в
систему таким чином, щоби усі без винятку
механізми взаємодії знаходились під їх
контролем
 Найпростішим методом, що реалізує цей принцип
при створенні ОС, є максимальне обмеження числа
механізмів взаємодії та інтеграція засобів захисту
безпосередньо в ці механізми
 Додавання “сторонніх” засобів, що не повністю
інтегруються в ОС, як правило не дозволяє досягти
повного контролю механізмів взаємодії
Принцип інваріантності
 Засоби захисту не повинні залежати від
особливостей реалізації утиліт і
прикладних програм, і не повинні
враховувати логіку їх функціонування
 Засоби захисту повинні бути
універсальними для усіх типів взаємодій
 Для ОС інваріантність засобів захисту може
бути досягнута шляхом застосування строго
регламентованої парадигми функціонування
програм, що обмежує способи взаємодій
Принцип уніфікації
 Засоби захисту мають бути
універсальними, що дозволяє
використовувати їх без змін як для
реалізації різних моделей безпеки, так і
для керування доступом до об’єктів
різної природи
 При розробленні ОС слідування цьому принципу
приводить до необхідності створення
універсального інтерфейсу доступу, що об’єднує
всі способи взаємодій між суб’єктами й об’єктами

Принцип гарантованості
(адекватності)
 Для забезпечення реальної здатності протидіяти
атакам необхідно виключити усі чинники, які
спричиняють виникнення вразливостей
 Необхідна мінімізація обсягу довіреного коду самих засобів
захисту з метою зменшення ймовірності появи в них помилок
 Однією з головних причин появи вразливостей є
непослідовність в реалізації керування доступом
 Системи, що існують, містять привілейовані засоби та служби, які
передають користувачам частину своїх повноважень, минаючи
засоби контролю (Типовий приклад – механізм SUID/SGID в системі
UNIX)
 Переважну більшість причин появи вразливостей можна усунути,
реалізувавши керування доступом на основі універсального
інтерфейсу та єдиного механізму взаємодії без будь-яких винятків

Принцип коректності
 Засоби захисту повинні реалізовувати керування
доступом відповідно до формальних моделей
 Повинна існувати однозначна відповідність між взаємодіями
суб’єктів і об’єктів, що контролюються, та операціями
доступу, керування якими описується моделями безпеки
 Усі функції універсального інтерфейсу доступу (див. принцип
уніфікації) повинні однозначним чином відображатись на множину
операцій, що описуються моделлю безпеки
 Наявність несуперечливої моделі безпеки:
 дозволяє формально обґрунтувати безпеку системи,
 надає об’єктивний критерій коректності її роботи,
 може бути основою для побудови вичерпних тестів, що перевіряють
правильність роботи засобів захисту в усіх режимах і обставинах.

Типова архітектура комплексу
засобів захисту операційних систем
Основні підсистеми КЗЗ ОС
Керування політикою безпеки ОС
Ідентифікація
Керування й Розмежування
Реєстрація Реєстрація й
Антивірусний
доступом
автентифікація (Аудит)
доступу захист
облік (аудит)
Ідентифікація й Оновлення Контроль
автентифікація
Криптографічні програм
Забезпечення цілісності
Антивірусний
функції
Криптографічні цілісності
функції Мережнізахист
функції
Апаратні засоби

Основні підсистеми КЗЗ ОС 1/4
1.Розмежування доступу
 Кожному користувачеві надається доступ лише до тих захищених об’єктів, доступ до
яких дозволений йому політикою безпеки
 Ця підсистема безпосередньо реалізовує політику безпеки
2.Ідентифікація й автентифікація
 Жодний користувач не може розпочати роботу в середовищі захищеної ОС, не
надавши системі свого ідентифікатора і не підтвердивши справжність наданого
ідентифікатора за допомогою додаткової інформації, що автентифікує цього
користувача
 Система повинна ідентифікувати усі об’єкти, а також здійснювати автентифікацію
об’єктів, що не знаходяться під її безпосереднім контролем (мережні об’єкти)
3.Реєстрація та аудит
 В захищеній ОС здійснюється реєстрація всіх подій, що є потенційно небезпечними
 Підсистема аудиту здійснює захист журналів, в яких відбувається реєстрація, від
НСД
 Також ця підсистема може надавати засоби для аналізу журналів і відстеження
джерел тих чи інших подій

4.Антивірусний захист
 Як правило, під підсистемою антивірусного захисту розуміють сукупність
програм, які надають можливість виявляти і знешкоджувати відомі шкідливі
програми, що відносяться як до вірусів (у широкому розумінні – включаючи
троянських коней, мережних хробаків, шпигунські програми), так і до засобів
здійснення атак
 Без антивірусного захисту в наш час неможливо підтримувати ОС у безпечному
стані, особливо якщо вона встановлена на комп’ютері, що підключений до
мережі
 Часто антивірусні засоби не входять до складу ОС, а постачаються окремо
5.Забезпечення цілісності
 Будь-яка сучасна ОС надає додаткові засоби для захисту цілісності даних не
лише від НСД, але й від випадкових помилок, а також від аварій і збоїв системи
 Насамперед, це стосується даних у файлових системах
 Такі засоби реалізують можливості відкату, а також автоматизацію процесу
створення резервних копій і відновлення з них

6.Оновлення програм
 Сучасні технології розроблення програмних продуктів — як прикладних програм, так і ОС, не
дозволяють гарантувати відсутність уразливостей. Тому сучасний підхід до забезпечення
захищеного стану інформаційно-телекомунікаційних систем передбачає обов’язкове постійне
оновлення програм
 Підсистема оновлення програм повинна гарантувати встановлення оновлень лише з надійних
джерел
7.Криптографічні функції
 Криптографічні функції застосовуються для захисту конфіденційності і цілісності інформації,
для автентифікації і забезпечення неможливості відмовлення від авторства
 Криптографічні функції можуть використовуватись в якості самостійних засобів захисту
(шифрування файлових систем), або в якості допоміжних механізмів в інших засобах
(криптографічний захист цілісності журналів реєстрації)
8.Мережні функції
 Мережний обмін є можливим шляхом доступу зловмисників до системи і найбільш критичним
джерелом проникнення в систему шкідливих програм. Тому мережні функції відносять до
комплексу засобів захисту
 Мережні функції повинні протистояти мережним атакам, насамперед — атакам на протоколи

9.Керування політикою безпеки

 Захищена ОС повинна надавати інтерфейси, які
дозволяють адміністраторам ефективно вирішувати
завдання з підтримання адекватної політики безпеки
 Обов’язково надаються інтерфейси для
настроювання підсистем розмежування доступу,
ідентифікації й автентифікації, аудиту
10.Апаратні засоби
 КЗЗ ОС спирається на функції захисту, реалізовані в
апаратних засобах – процесорі і системній платі

Особливості архітектури
КЗЗ ОС
 КЗЗ ОС практично завжди є сукупністю значної кількості
програмних модулів
 частина модулів КЗЗ виконується у режимі ядра, а частина – у режимі
користувача, тобто як прикладні програми
 В деяких ОС, де використовується більша кількість рівнів
привілеїв процесів (кілець захисту), будується ієрархія засобів
захисту
 В сучасних ОС КЗЗ чітко виділяється в архітектурі системи
 наприклад, Windows
 Зустрічаються такі ОС, в яких підсистеми і окремі компоненти КЗЗ
розпорошені по всій системі
 наприклад, традиційні системи Unix і Linux
 Як правило, підсистема захисту дозволяє додавати додаткові
модулі, які реалізують підсилені функції захисту, для чого
передбачаються відповідні інтерфейси

Адміністративні заходи
захисту
 Постійний контроль коректності функціонування ОС, зокрема, її підсистеми
захисту
 реєстрація подій у системі (event logging);
 контроль цілісності файлів, зокрема, файлів, що містять програмний код компонентів ОС;
 виконання тестів на коректність функціонування компонентів ОС.
 Організація й підтримання адекватної політики безпеки
 Політика безпеки в ОС фактично визначає:
 які користувачі мають доступ до яких компонентів ОС;
 які користувачі мають доступ до яких об’єктів, що знаходяться під керуванням ОС (наприклад, файлів на
диску, зовнішніх носіїв, пристроїв введення-виведення тощо);
 яким чином користувачі ОС ідентифікують себе і які вимоги висунуті стосовно їхніх атрибутів доступу;
 які події повинні реєструватись у системних журналах.
 Політика безпеки повинна постійно коригуватись з урахуванням змін у конфігурації ОС,

номенклатурі і настроюваннях встановлених прикладних програм, спроб порушників
подолати захист ОС, поточних загроз (наприклад, епідемій небезпечних вірусів).
 Навчання користувачів
 Створення резервних копій
 Постійний контроль змін в конфігураційних даних і політиці безпеки ОС

Адекватна політика
безпеки
 Адекватна політика безпеки в ОС – це така політика безпеки, яка
забезпечує захист від визначеної множини загроз з достатньою надійністю
 Вибір адекватної політики безпеки – завдання адміністратора безпеки,
підтримання цієї політики безпеки – одна з найважливіших задач
адміністратора ОС
 Не слід вважати адекватною політику безпеки, яка забезпечує
максимальний можливий захист
 Як правило, підвищення захищеності пов’язано з обмеженням функціональності і
утрудненням роботи користувачів
 Єдиної адекватної політики безпеки на всі можливі випадки не існує й
існувати не може
 Адекватна політика безпеки визначається задачами тієї інформаційної системи, яка
побудована з застосуванням конкретної ОС, а також загрозами безпеці інформації у
конкретній ІКС
 Також адекватна політика безпеки може залежати від версії застосованої ОС, її
конфігурації, встановленого прикладного ПЗ.

Основні етапи визначення і підтримання
адекватної політики безпеки 1/2
1.Аналіз загроз
 Вивчають можливі загрози безпеці конкретного екземпляру ОС
 Будують модель загроз
 Оцінюють ризики
 Визначають пріоритети у захисті від конкретних загроз
2.Формування вимог до політики безпеки
 Визначають засоби і методи, які будуть застосовані для захисту від кожної окремої загрози
 Як правило, неминучим є компроміс між вадами захисту від певних загроз і утрудненням роботи користувачів у
системі
 Результатом робіт є формування набору вимог до реалізації політики безпеки у вигляді переліку
методів і засобів захисту, які повинні бути реалізованими
3.Формальне визначення політики безпеки
 Здійснюють чітке визначення засобів, які будуть реалізовувати ті вимоги, що були сформульовані на
попередньому етапі
 Зокрема, з’ясовується, чи можна домогтися виконання зазначених вимог лише штатними засобами ОС, або
необхідно встановлювати додатково спеціальне ПЗ
 Формулюють вимоги до конфігурації ОС і усіх додаткових програм, що реалізують функції захисту,
якщо такі встановлені
 Результатом робіт є детальний перелік конфігураційних настроювань ОС і додаткових програм
 Повинні бути передбачені різні нештатні ситуації і відповідні настроювання ОС для таких ситуацій.

Основні етапи визначення і підтримання
адекватної політики безпеки 2/2
4.Втілення політики безпеки

 Виконують настроювання ОС і додаткових програм, які реалізують функції захисту,
у точній відповідності до формалізованої політики безпеки
5.Підтримання і корекція політики безпеки
 Ретельний контроль дотримання політики безпеки, що була розроблена на
третьому етапі
 Контроль обов’язково включає перевірки налаштовувань засобів захисту у складі ОС і може
виконуватись за допомогою спеціального ПЗ
 Відстеження повідомлень про
 появу нових загроз (наприклад, розповсюдження в Інтернеті небезпечних вірусів)
 виявлення раніше невідомих уразливостей
 розроблення виправлень для ОС і прикладного ПЗ
 У деяких випадках може знадобитись корекція політики безпеки
 Виявлення уразливостей, для усунення яких немає необхідних виправлень
 Будь-які зміни в самій системі
– Наприклад, встановлення нового програмного продукту може вимагати корекції політики безпеки, по-перше,
для забезпечення нормального функціонування цього програмного продукту (розширення повноважень), а
по-друге, для виключення шляхів несанкціонованого доступу, які можуть в результаті з’явитись (додаткові
обмеження).

Безпека
систем
Лекція 04. Стандарти оцінювання захищеності операційних
систем

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

Оптимістичний погляд на
стандарти оцінювання
 Викорінення вад захисту – це тактичний шлях побудови
захищених систем, чи підхід “знизу”
 Дозволяє позбутися окремих уразливостей і підвищити
захищеність системи
 Не дозволяє оцінити ані повноту виконання цієї задачі, ані
досягнутий рівень захисту
 Стандарти визначають стратегічний підхід до побудови
захищених систем, або підхід “зверху”
 Безпека системи – характеристика якісна, для неї не існує
одиниць виміру
 Різні фахівці запропонують різні шляхи підвищення захищеності системи і
по-різному оцінять її
 Єдиним способом встановити шкалу оцінки захищеності систем, а
також узгодити погляди різних фахівців, є розробка стандарту

Реалістичний погляд на
стандарти оцінювання
 На жаль, стандарти лише частково вирішують питання
захищеності систем
 Традиційний погляд на застосування стандартів передбачає, що
конфігурація оцінюваної системи чітко фіксується і в подальшому не
змінюється — це ніби-то гарантує, що система залишається у
захищеному стані
 Насправді, жодна перевірка не дозволяє гарантувати повну
відсутність уразливостей — тому постійний пошук і виправлення
вразливостей залишаються актуальними
 В результаті виправлення вразливостей (встановлення патчів)
змінюється код системи (у тому числі можливі зміни коду ядра) — а
отже потрібне повторне оцінювання за стандартом
 Незважаючи на це, підготовка системи до оцінювання за
стандартом (compliance) позитивно впливає на якість
розроблюваної системи

Розвиток стандартів
оцінювання систем
 TCSEC – Критерії оцінювання захищених
комп’ютерних систем Міністерства
оборони США («Оранжева книга»), 1983 р.
 ITSEC – Європейські критерії безпеки
інформаційних технологій, 1991 р.
 “Руководящие документы
Гостехкомиссии России”, 1992 р.
 FCITS – Федеральні критерії безпеки
інформаційних технологій США, 1992 р.

TCSEC (“Оранжева книга”)
 Trusted Computer System Evaluation Criteria. – US
Department of Defense. – CSC-STD-001-83, 1983.
 Trusted Network Interpretation. – National Computer
Security Center. NCSC-TG-005 Version 1, 1987.
 Trusted Database Management System
Interpretation. – National Computer Security Center.
NCSC-TG-021 Version 1, 1991.
 The Interpreted Trusted Computer System
Evaluation Criteria Requirements. – National
Computer Security Center. NCSC-TG-007-95, 1995.

TCSEC
 Визначення безпечної системи
 система, що підтримує керування доступом таке, що лише
уповноважені користувачі або процеси, що діють від їх
імені, одержують можливість читати, записувати,
створювати і знищувати інформацію
 6 вимог до безпечної системи
 Політика безпеки
 Мітки безпеки
 Ідентифікація і автентифікація
 Реєстрація і облік
 Коректність засобів захисту
 Неперервність захисту
TCSEC: перелік вимог
 Політика безпеки  Коректність
 Дискреційне керування
 Коректність функціонування
 Архітектура системи
доступом
 Цілісність системи
 Повторне використання об’єктів  Аналіз прихованих каналів
 Мітки безпеки  Керування безпекою
 Відновлення
 Цілісність міток безпеки
 Коректність розробки
 Експорт поміченої інформації  Тестування безпеки
 Мітки повноважень суб'єктів  Розробка і верифікація специфікацій
 Мітки пристроїв  Керування конфігурацією
 Мандатне керування доступом  Дистрибуція
 Документація
 Аудит  Настанова з безпеки користувача
 Ідентифікація і автентифікація  Настанова адміністратора безпеки
 Пряма взаємодія з КЗЗ  Документування процесу тестування
 Реєстрація і облік подій  Документування процесу розроблення

TCSEC: класифікація систем
Групи Класи
A A1 Верифікований захист
B B1 B2 B3 Мандатний захист
C C1 C2 Дискреційний захист
D D1 Мінімальний захист

Основні вимоги рівня С2 щодо
операційних систем 1/2
 Засіб безпечного входу в систему
 Вимагає унікальної ідентифікації користувачів і
одержання ними повноважень доступу до комп'ютера
тільки після того, як вони тим чи іншим способом
пройдуть автентифікацію
 Дискреційне керування доступом
 Дозволяє власнику ресурсу (наприклад, файлу)
визначити, хто може отримати доступ до ресурсу і що
він при цьому може з ним робити
 Власник надає права, що дозволяють різні види
доступу, окремому користувачу або групі
користувачів
Основні вимоги рівня С2 щодо
 Контроль (аудит) безпеки
 Дозволяє виявляти і записувати події, які стосуються питань безпеки,
або будь-які спроби створення системних ресурсів, а також звернення
до них чи їх видалення
 Записування ідентифікаторів під час входу в систему, що дозволяє
встановлювати ідентичність усіх користувачів, спрощуючи тим самим
відстежування будь-якого користувача, що намагається здійснити
неавторизовану дію
 Захист від повторного використання об'єкта
 Не дозволяє користувачам переглядати дані, що були видалені іншим
користувачем, або не дозволяє звертатись до пам'яті, яка раніше була
використана, а далі звільнена іншим користувачем (“збирання сміття”)
 Захист від повторного використання об'єкта реалізується шляхом
ініціалізації усіх об'єктів, включаючи файли і пам'ять, перед їх
виділенням користувачеві

Деякі важливі вимоги рівня В
щодо операційних систем
 Механізм “довіреного маршруту”
 Не дає троянським програмам можливості перехоплення імен і паролів
користувачів при спробі їх входу в систему
 Приклад:
 У Windows механізм довіреного маршруту реалізований у формі “послідовності переносу
уваги” на вход до системи Ctrl+Alt+Delete — secure attention sequence (SAS), яка не може
бути перехопленою непривілейованими програмами
 Ця клавіатурна послідовність завжди виводить екран безпеки Windows, яким керує система
 При введенні SAS троянська програма, яка надає несправжнє діалогове вікно, буде
обійдена.
 SAS може також бути відправлена програмно шляхом використання API-функції SendSAS
 Довірений засіб керування
 Вимагає підтримки ролей окремих облікових записів для здійснення
адміністративних функцій
 Наприклад, для адміністрування, для користувачів, що відповідають за резервне
копіювання комп'ютера, і для звичайних користувачів надаються окремі облікові
записи

Висновки по TCSEC
 Перша спроба створити єдиний стандарт безпеки,
що розрахований на розробників, споживачів і
спеціалістів із сертифікації КС
 Орієнтований на системи спеціального (військового)
застосування, головним чином на операційні
системи (домінують вимоги з конфіденційності)
 Критерії гарантій реалізації засобів захисту і
адекватності політики безпеки розроблені
недостатньо
 Оцінка системи зводиться до перевірки виконання
вимог одного з наперед визначених класів. Шкала
класів є ієрархічною

ITSEC – Європейські
критерії
 Information Technology Security Evaluation
Criteria. Harmonized Criteria Of France-Germany-
Netherlands-United Kingdom. – Department of
Trade and Industry. – London, 1991.
 Спільна розробка уповноважених служб

Великої Британії, Нідерландів, Німеччини та
Франції
 Документ базується на “Оранжевій книзі” і
може розглядатись як її розвиток і доповнення

ITSEC – класи безпеки
 F-C1, F-C2, F-B1, F-B2, F-B3 – відповідають TCSEC
 F-IN – підвищені вимоги до забезпечення цілісності
(СКБД)
 F-AV – підвищені вимоги до забезпечення
працездатності (промислові системи керування)
 F-DI – розподілені системи з підвищеними вимогами
до цілісності
 F-DC – розподілені системи з підвищеними вимогами
до конфіденційності
 F-DX – розподілені системи з підвищеними вимогами
до конфіденційності, цілісності і неможливості
відмови від авторства
ITSEC – критерії гарантій 1/2
 Критерії ефективності
 Відповідність набору засобів захисту заданим
цілям
 Взаємна узгодженість різних засобів і механізмів
захисту
 Здатність засобів захисту протистояти атакам
 Можливість практичного використання недоліків
архітектури засобів захисту
 Простота використання засобів захисту
 Можливість практичного використання
функціональних недоліків засобів захисту
ITSEC – критерії гарантій 2/2
 Критерії коректності
 Процес розроблення
 Специфікація вимог безпеки
 Розроблення архітектури
 Створення робочого проекту
 Реалізація
 Середовище розроблення
 Засоби керування конфігурацією
 Використовувані мови програмування і компілятори
 Безпека середовища розроблення
 Експлуатаційна документація
 Настанова користувача
 Настанова адміністратора
 Середовище експлуатації
 Доставка і встановлення
 Запуск и експлуатація

Висновки по ITSEC
 ITSEC тісно пов'язані з TCSEC (не повністю
самостійний документ)
 Головне досягнення – введення поняття
гарантій захисту і визначення окремої шкали
для критеріїв гарантій
 Відмова від єдиної ієрархічної шкали
оцінювання систем
 Визнання можливості наявності недоліків у
сертифікованих системах і введення
критерію можливості використання недоліків
захисту
Руководящие документы
ГТК России
 Концепция защиты средств
вычислительной техники (СВТ) от
несанкционированного доступа (НСД) к
информации
 СВТ. Защита от НСД к информации.
Показатели защищенности от НСД к
информации
 Автоматизированные системы (АС). Защита
от НСД к информации. Классификация АС и
требования по защите информации

Руководящие документы
ГТК России: классы СВТ и АС
 СВТ: 7 классов от 7 к 1
 АС: 3 группы, 9 классов
 Группа 3
АС, в которых работает один пользователь, допущенный
ко всей информации. Классы 3Б и 3А
 Группа 2
АС, в которых пользователи имеют одинаковые
полномочия доступа ко всей информации. Классы 2Б и 2А
 Группа 1
Многопользовательские АС, обрабатывается информация
разных уровней конфиденциальности, пользователи
имеют различные права доступа.
Классы 1Д, 1Г, 1В, 1Б, 1А

«Руководящие документы
ГТК России»: висновки
 Подібно до «Оранжевої книги», документи орієнтовані на
системи військового застосування
 Поняття «Політика безпеки» трактується винятково як
підтримання режиму секретності й відсутність НСД
 Засоби захисту орієнтуються винятково на протидію
зовнішнім загрозам
 Відсутні вимоги до захисту від загроз працездатності і
до адекватності реалізації політики безпеки
 До структури самої системи і до її функціонування
вимоги не висуваються
 Застосовується єдина універсальна шкала ступеня
захищеності. Ранжування вимог за класами максимально
спрощено
FCITS – «Федеральні
критерії»: мета розробки
 Federal Criteria for Information Technology Security.
– National Institute of Standards and Technology &
National Security Agency. Version 1.0, 1992.
 Визначення універсального й відкритого для подальшого

розвитку набору основних вимог безпеки, що висувають до
сучасних інформаційних технологій
 Удосконалення вимог і критеріїв безпеки, що існують
 Узгодження між собою вимог і критеріїв безпеки
інформаційних технологій, що прийняті у різних країнах
 Нормативне закріплення головних принципів інформаційної
безпеки

FCITS – етапи розроблення
продукту ІТ
1.Розроблення і аналіз профілю захисту
 Вимоги, що викладені у профілі захисту, визначають функціональні
можливості продуктів ІТ із забезпечення безпеки і умови експлуатації,
за дотримання яких гарантується відповідність висунутим вимогам
 Профіль захисту аналізують на повноту, несуперечність і технічну
коректність
2.Розроблення і кваліфікаційний аналіз продуктів ІТ
 Розроблені продукти ІТ піддають незалежному аналізу, мета якого –
визначення ступеня відповідності характеристик продукту вимогам
профілю захисту
3.Компонування і сертифікація системи оброблення
інформації в цілому
 Отримана в результаті система повинна задовольняти вимогам, що
заявлені у профілі захисту

FCITS – структура профілю
захисту
 Опис
 Класифікаційна інформація, що необхідна для
ідентифікації профілю у спеціальній картотеці
 Обґрунтування
 Опис середовища експлуатації, загроз безпеці, що
передбачаються, і методів використання продукту ІТ
 Функціональні вимоги до продукту ІТ
 Вимоги до технології розроблення продукту ІТ
 Вимоги до процесу кваліфікаційного аналізу
продукту ІТ

FCITS – функціональні
вимоги
 Реалізація політики безпеки  Моніторинг взаємодій
 Політика аудиту  Логічний захист КЗЗ
 Ідентифікація і автентифікація
 Реєстрація в системі
 Фізичний захист КЗЗ
 Забезпечення прямої взаємодії з  Самоконтроль КСЗ
КЗЗ
 Реєстрація і облік подій
 Ініціалізація і відновлення
 Політика керування доступом
КЗЗ
 Дискреційне керування доступом  Обмеження привілеїв під час
 Мандатне керування доступом роботи з КЗЗ
 Контроль прихованих каналів  Простота використання КЗЗ
 Політика забезпечення
працездатності
 Контроль за розподілом ресурсів
 Забезпечення стійкості до відмов
 Керування безпекою

FCITS – Вимоги до
технології розробки
 Процес розробки
 Визначення множини функцій КЗЗ у відповідності до функціональних вимог
 Реалізація КЗЗ
 Визначення складу функціональних компонент КЗЗ
 Визначення інтерфейсу КЗЗ
 Декомпозиція КЗЗ на функціональні модулі
 Структуризація КЗЗ на домени безпеки
 Мінімізація функцій і структури КЗЗ
 Гарантії реалізації КЗЗ
 Тестування і аналіз КЗЗ
 Тестування функцій КЗЗ
 Аналіз можливостей порушення безпеки
 Аналіз прихованих каналів
 Середовище розробки
 Інструментальні засоби
 Засоби керування процесом розробки
 Процедура дистрибуції

FCITS – Вимоги до
технології розробки
 Документація функцій КЗЗ
 Повна документація на продукт ІТ (інтерфейси, компоненти, модулі,
структура КЗЗ, методика проектування, вихідні тексти і специфікація
апаратних засобів)
 Документація тестування і аналізу продукту ІТ
 Документація процесу тестування функцій
 Документація аналізу можливостей порушення безпеки
 Документація аналізу прихованих каналів
 Документація середовища і процесу розробки
 Супроводження
 Документація користувача
 Настанова з адміністрування системи безпеки
 Процедура оновлення версій і виправлення помилок
 Процедура інсталяції

FCITS – Вимоги до процесу
кваліфікаційного аналізу
 Аналіз
 Аналіз архітектури
 Аналіз реалізації
 Контроль
 Контроль середовища розробки
 Контроль процесу супроводження продукту ІТ
 Тестування
 Тестування функцій КЗЗ виробником
 Незалежне тестування функцій КЗЗ
FCITS – Висновки
 Вперше запропонована концепція профілю
захисту
 У стандарті визначені три незалежні групи вимог
 Функціональні вимоги безпеки добре структуровані
 Вимоги до технології розроблення змушують виробників
застосовувати сучасні технології програмування, що
дозволяють підтвердити безпеку продукту
 Вимоги до процесу кваліфікаційного аналізу узагальнені і
не містять конкретних методик
 Відсутня загальна оцінка рівня безпеки за
допомогою універсальної шкали, запропоновано
незалежне ранжування вимог кожної групи
Безпека
систем
Лекція 05. Нормативні документи системи технічного
захисту інформації в Україні (НД ТЗІ)

НД ТЗІ з питань захисту інформації
в комп’ютерних системах від НСД 1/2
 Загальні положення із захисту інформації в комп'ютерних

системах від несанкціонованого доступу (НД ТЗІ 1.1-002-99)
 Термінологія в галузі захисту інформації в комп'ютерних
 Критерії оцінки захищеності інформації в комп'ютерних
 Класифікація автоматизованих систем і стандартні
функціональні профілі захищеності оброблюваної інформації
від несанкціонованого доступу (НД ТЗІ 2.5-005-99)
 Методичні вказівки по розробці технічного завдання на
створення комплексної системи захисту інформації в
автоматизованій системі (НД ТЗІ 3.7-001-99)
 Типове положення про службу захисту інформації в
автоматизованій системі (НД ТЗІ 1.4-001-2000)

НД ТЗІ з питань захисту інформації
в комп’ютерних системах від НСД 2/2
 Технічний захист інформації. Комп'ютерні системи. Порядок створення,

впровадження, супроводження і модернізації засобів технічного захисту
інформації від несанкціонованого доступу. (НД ТЗІ 3.6-001-2000)
 Вимоги із захисту конфіденційної інформації від несанкціонованого
доступу під час оброблення в автоматизованих системах класу 2
(НД ТЗІ 2.5-008-02)
 Вимоги до захисту інформації WEB–сторінки від несанкціонованого
доступу (НД ТЗІ 2.5-010-03)
 Порядок проведення робіт із створення комплексної системи захисту
інформації в інформаційно-телекомунікаційній системі
(НД ТЗІ 3.7-003-05)
 Методичні вказівки з оцінювання функціональних послуг безпеки в
засобах захисту інформації від несанкціонованого доступу
(НД ТЗІ 2.7-009-09)
 Методичні вказівки з оцінювання рівня гарантій коректності реалізації
функціональних послуг безпеки в засобах захисту інформації від
несанкціонованого доступу (НД ТЗІ 2.7-010-09)

Термінологія в галузі захисту
інформації в КС від НСД
Об’єкт-користувач
Суб’єкт
Об’єкт-процес
Доступ:
користувач процес пасивний об’єкт
Керування доступом:
Дискреційне Довірче
Мандатне Адміністративне

Термінологія в галузі захисту
 Довірче керування доступом
 Користувачам дозволено керувати доступом до об’єктів
свого домену (наприклад, на підставі права володіння
об’єктами)
 Це є аналогом дискреційного керування доступом
 Адміністративне керування доступом
 Керувати доступом до об’єктів дозволено лише спеціально
уповноваженим користувачам (адміністраторам)
 Це є аналогом мандатного (mandatory — обов’язковий,
примусовий) керування доступом
 На відміну від, наприклад, TCSEC, сама модель за якою
здійснюється адміністративне керування доступом, не
визначена
Критерії оцінки захищеності
 Критерії конфіденційності
 Критерії цілісності
 Критерії доступності
 Критерії спостережності
 Критерії гарантій
Функціональні критерії

Концепція функціонального
профілю в НД ТЗІ
 Послуга (сервіс) безпеки
 Сукупність функцій, що забезпечують захист від певної
загрози або від множини загроз
 Для кожної послуги запропонована окрема шкала
оцінок, яка визначає рівень реалізації цієї послуги
 Функціональний профіль
 Перелік рівнів функціональних послуг, які реалізуються
комп’ютерною системою
 Функціональний профіль оформлюється певним чином
 зокрема, специфіковано порядок, у якому повинні бути
названі послуги

Критерії конфіденційності
 Довірча конфіденційність (КД-1…4)
 дозволяє користувачу керувати потоками інформації від захищених об'єктів, що
належать його домену, до інших користувачів
 Адміністративна конфіденційність (КА-1…4)
 дозволяє адміністратору або спеціально авторизованому користувачу керувати
потоками інформації від захищених об'єктів до користувачів
 Повторне використання об'єктів (КО-1)
 дозволяє забезпечити коректність повторного використання розділюваних об'єктів, тобто
таких, які почергово виділяються різним користувачам та/або процесам
 гарантує, що коли розділюваний об'єкт виділяється новому користувачу або процесу, він
не містить інформації, яка залишилась від попереднього користувача або процесу
 Аналіз прихованих каналів (КК-1…3)
 забезпечує виявлення і усунення потоків інформації, які існують, але не контролюються
іншими послугами
 Конфіденційність при обміні (КВ-1…4)
 забезпечує захист об'єктів від несанкціонованого ознайомлення з інформацією, яку вони
містять, під час їх передавання через незахищене середовище

Критерії цілісності
 Довірча цілісність (ЦД-1…4)
 дозволяє користувачу керувати потоками інформації від інших
користувачів до захищених об'єктів, що належать його домену
 Адміністративна цілісність (ЦА-1…4)
 дозволяє адміністратору або спеціально авторизованому користувачу
керувати потоками інформації від користувачів до захищених об'єктів
 Відкат (ЦО-1...2)
 забезпечує можливість відмінити операцію або послідовність
операцій і повернути (відкотити) захищений об'єкт до попереднього
стану
 Цілісність при обміні (ЦВ-1…3)
 забезпечує захист об'єктів від несанкціонованої модифікації
інформації, яку вони містять, під час їх передавання через
незахищене середовище

Критерії доступності
 Використання ресурсів (ДР-1…3)
 забезпечує керування використанням користувачами послуг і
ресурсів
 Стійкість до відмов (ДС-1…3)
 гарантує доступність КС (можливість використання інформації,
окремих функцій або КС в цілому) після відмови її компонента
 Гаряча заміна (ДЗ-1…3)
 дозволяє гарантувати доступність КС (можливість використання
інформації, окремих функцій або КС в цілому) в процесі заміни
окремих компонентів
 Відновлення після збоїв (ДВ-1…3)
 забезпечує повернення КС у відомий захищений стан після
відмови або переривання обслуговування

Критерії спостережності 1/2
 Реєстрація (НР-1…5)
 дозволяє контролювати небезпечні для КС дії шляхом реєстрації і аналізу
подій, що мають відношення до безпеки
 Ідентифікація й автентифікація (НИ-1…3)
 дозволяє КЗЗ визначити і перевірити особистість користувача, що
намагається одержати доступ до КС
 Достовірний канал (НК-1…2)
 дозволяє гарантувати користувачу можливість безпосередньої взаємодії з
КЗЗ
 Розподіл обов'язків (НО-1…3)
 дозволяє зменшити потенційні збитки від навмисних або помилкових дій
користувача і обмежити авторитарність керування
 Цілісність комплексу засобів захисту (НЦ-1…3)
 визначає міру здатності КЗЗ захищати себе і гарантувати свою спроможність
керувати захищеними об'єктами

Критерії спостережності 2/2
 Самотестування (НТ-1…3)
 дозволяє КЗЗ перевірити і на підставі цього гарантувати правильність
функціонування і цілісність певної множини функцій КС
 Ідентифікація й автентифікація при обміні (НВ-1…3)
 дозволяє одному КЗЗ ідентифікувати інший КЗЗ (встановити і перевірити
його ідентичність) і забезпечити іншому КЗЗ можливість ідентифікувати
перший, перш ніж почати взаємодію
 Автентифікація відправника (НА-1…2)
 дозволяє забезпечити захист від відмови від авторства і однозначно
встановити належність певного об'єкта певному користувачу, тобто той
факт, що об'єкт був створений або відправлений даним користувачем
 Автентифікація одержувача (НП-1…2)
 дозволяє забезпечити захист від відмови від одержання і дозволяє
однозначно встановити факт одержання певного об'єкта певним
користувачем

Критерії гарантій
 Архітектура
 Середовище розроблення:
 процес розроблення
 керування конфігурацією
 Послідовність розроблення:
 функціональні специфікації (політика безпеки)
 функціональні специфікації (модель політики безпеки)
 проект архітектури
 детальний проект
 реалізація
 Середовище функціонування
 Випробування комплексу засобів захисту

КД-1. Мінімальна КД-4. Абсолютна
КД-2. Базова довірча КД-3. Повна довірча
довірча довірча
конфіденційність конфіденційність
конфіденційність конфіденційність
Політика довірчої конфіденційності, що Політика довірчої конфіденційності, що
реалізується КЗЗ, повинна визначати множину реалізується КЗЗ, повинна відноситись до всіх
об'єктів КС, до яких вона відноситься об'єктів КС
КЗЗ повинен здійснювати розмежування доступу на підставі атрибутів доступу
процесу і захищеного користувача, процесу і
користувача і захищеного об'єкта
об'єкта захищеного об'єкта
Запити на зміну прав доступу до об'єкта повинні оброблятися КЗЗ на підставі атрибутів доступу
користувача, що ініціює запит, і об'єкта
КЗЗ повинен надавати користувачу можливість для кожного захищеного об'єкта, що належить його
домену, визначити
конкретні процеси конкретних користувачів конкретних користувачів (і конкретних користувачів і
процеси (і групи
і/або групи процесів, і/або групи користувачів, групи користувачів), які користувачів і процесів),
які мають право які мають право мають, а також тих, які не які мають, а також тих, які
одержувати одержувати інформацію мають права одержувати не мають права
інформацію від об'єкта одержувати інформацію
інформацію від об'єкта від об'єкта від об'єкта
КЗЗ повинен надавати користувачу можливість для кожного процесу, що
належить його домену, визначити
—
конкретних користувачів
конкретних користувачів (і групи користувачів), які
і/або групи користувачів,
мають, а також тих, що не мають права ініціювати
які мають право
процес
ініціювати процес
Права доступу до кожного захищеного об'єкта повинні встановлюватись в момент його створення або
ініціалізації. Як частина політики довірчої конфіденційності повинні бути представлені правила
збереження атрибутів доступу об'єктів під час їх експорту та імпорту
НЕОБХІДНІ УМОВИ: НИ-1 НЕОБХІДНІ УМОВИ: КО-1, НИ-1
Обмеження на
функціональний профіль
 Обов’язково має виконуватись послуга “Цілісність комплексу
засобів захисту” (щонайменше, рівень НЦ-1)
 Мають бути задоволені усі вимоги специфікацій послуг щодо
виконання інших послуг
 КД, КА, ЦД, ЦА, ЦО, НР, НО, НА, НП → НИ-1 (ідентифікація,
автентифікація)
 КА, ЦА, КВ-2-4, ЦВ-2,3, ДР, ДС, ДЗ, ДВ, НР-2,5, НЦ-1, НТ-2 → НО-1
(виділення адміністратора)
 КД-3,4, КА-3,4, ЦД-3,4, ЦА-3,4, КК → КО-1 (повторне використання об’єктів)
 КК-2, КВ-4, НЦ-1 → НР-1 (реєстрація)
 КВ-3,4, ЦВ-3 → НВ-1 (ідентифікація й автентифікація при обміні)
 ДЗ-2,3 → ДС-1 (стійкість до відмов)
 НИ-2,3 → НК-1 (достовірний канал)
 КК, КВ-4 → Г-3

Класифікація АС і стандартні
функціональні профілі ЗІ в КС
 Клас 1: одномашинний однокористувачевий комплекс
 Окрема робоча станція, що не підключена до мережі
 Клас 2: локалізований багатомашинний
багатокористувачевий комплекс
 Локальна мережа
 Багатотермінальний сервер
 Кілька комп’ютерів, що не поєднані у мережу, але знаходяться у
спільному приміщенні і виконують спільні завдання
 Клас 3: розподілений багатомашинний
багатокористувачевий комплекс
 Головна ознака – принципова неможливість повного контролю
території, на якій знаходиться АС

Семантика профілю
 Опис профілю складається з трьох частин:
 буквено-числового ідентифікатора
 знака рівності
 переліку рівнів послуг, взятого в фігурні дужки
 Ідентифікатор у свою чергу включає:
 позначення класу АС (1, 2 або 3)
 буквену частину, що характеризує види загроз, від яких забезпечується захист (К, і/або Ц, і/або Д)
 номер профілю і необов’язкове буквене позначення версії
 Всі частини ідентифікатора відділяються один від одного крапкою
 Наприклад, 2.К.4 — функціональний профіль номер чотири, що визначає вимоги до АС класу 2,
призначених для обробки інформації, основною вимогою щодо захисту якої є забезпечення
конфіденційності
 Версія може служити, зокрема, для вказівки на підсилення певної послуги
всередині профілю
 Наприклад, нарощування можливостей реєстрації приведе до появи нової версії
 Внесення деяких істотних змін, особливо додання нових послуг, може або
привести до появи нового профілю, або до того, що профіль буде відноситись
до іншого класу чи підкласу АС

Приклади стандартних
функціональних профілів захищеності
1.Ц.2 = { ЦА-2, ЦО-1, НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-1 }
1.Д.2 = { ДР-2, ДС-1, ДЗ-1, ДВ-2, НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-2 }
1.Д.3 = { ДР-2, ДС-2, ДЗ-2, ДВ-2, НР-3, НИ-2, НК-1, НО-1, НЦ-2, НТ-2 }
1.КЦ.2 = { КА-1, КО-1, ЦА-2, ЦО-1, НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-1 }
2.КЦ.2 = { КД-2, КО-1, ЦД-1, ЦО-1, НР-2, НИ-2, НК-1, НО-1, НЦ-2, НТ-1 }
2.КЦД.2 = { КД-2, КА-2, КО-1, ЦД-1, ЦА-2, ЦО-1, ДР-1, ДВ-1,

НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2 }
3.КЦД.2 = { КД-2, КА-2, КО-1, КВ-2, ЦД-1, ЦА-2, ЦО-1, ЦВ-2, ДР-1, ДВ-1,
НР-2, НИ-2, НК-1, НО-2, НЦ-2, НТ-2, НВ-1 }

НД ТЗІ 2.5-008-02
 Повна назва документа - Вимоги із захисту конфіденційної інформації від
несанкціонованого доступу під час оброблення в автоматизованих системах
класу 2
 Мета документа – надання нормативно-методологічної бази під час
розроблення комплексів засобів захисту від НСД до конфіденційної інформації,
яка обробляється в АС класу 2, створення КСЗІ, проведення аналізу та оцінки
захищеності інформації від несанкціонованого доступу в системах такого
класу, а також рекомендацій для визначення необхідного функціонального
профілю захищеності інформації в конкретній АС
 В документі наведені:
 загальні вимоги до захисту конфіденційної інформації, які випливають з вимог чинного
законодавства
 характеристики типових умов функціонування АС класу 2. Розглянуті обчислювальна система,
фізичне середовище, в якому вона знаходиться і функціонує, користувачі АС та оброблювана
інформація, у тому числі й технологія її оброблення.
 детальні вимоги щодо захисту інформації в АС класу 2
 докладно розібрана політика реалізації послуг безпеки інформації в АС класу 2
 Фактично, документ є детальною настановою з розроблення технічного
завдання на створення КСЗІ в АС класу 2

Політика безпеки згідно
НД ТЗІ 2.5-008-02
 Як основний принцип політики безпеки визначено адміністративний принцип
розмежування доступу, який забезпечується послугами безпеки КА і ЦА
 Реалізація послуг безпеки, що базуються на довірчому принципі розмежування
доступу (КД і ЦД), може здійснюватися у випадках:
 коли політикою безпеки передбачено створення груп користувачів з однаковими повноваженнями
щодо роботи з конфіденційною інформацією для розмежування доступу до об’єктів, що таку
інформацію містять, у межах цих груп
 для розмежування доступу до об’єктів, які потребують захисту, але не містять конфіденційної
 Визначені такі стандартні функціональні профілі захищеності оброблюваної
інформації:
 2.К.3 = {КД-2, КА-2, КО-1, НР-2, НК-1, НЦ-2, НТ-2, НИ-2, НО-2}
 2.КЦ.3 = {КД-2, КА-2, КО-1, ЦД-1, ЦА-2, ЦО-1, НР-2, НК-1, НЦ-2, НТ-2, НИ-2, НО-2}
 2.КД.1а = {КД-2, КА-2, КО-1, ДР-1, ДС-1, ДЗ-1, ДВ-1, НР-2, НК-1, НЦ-2, НТ-2, НИ-2, НО-2}
 2.КЦД.2а = {КД-2, КА-2, КО-1, ЦД-1, ЦА-2, ЦО-1, ДР-1, ДС-1, ДЗ-1, ДВ-1,
НР-2, НК-1, НЦ-2, НТ-2, НИ-2, НО-2}
 Мінімальним достатнім рівнем гарантій реалізації КЗЗ АС класу 2 є рівень Г–2
 Реалізація послуги безпеки КО-1 є необов’язковою у тому випадку, коли в АС класу
2 усі користувачі допущені до обробки конфіденційної інформації одного рівня

НД ТЗІ 2.5-010-03
 Повна назва документа – Вимоги до захисту інформації WEB–сторінки від
несанкціонованого доступу
 Документ встановлює вимоги до технічних та організаційних заходів захисту
інформації Web-сторінки (Web-сайту) в мережі Інтернет
 Зокрема, мінімально необхідний перелік послуг безпеки інформації та рівнів їх реалізації у
комплексах засобів захисту інформації Web-сторінки від несанкціонованого доступу згідно з
визначеними НД ТЗІ 2.5-004-99 специфікаціями
 Мета документа – надання нормативно-методологічної бази для розроблення
комплексу засобів захисту від несанкціонованого доступу до інформації Web-
сторінки під час створення КСЗІ
 В документі наведені:
 загальні вимоги до захисту інформації Web-сторінки, які випливають з вимог чинного
законодавства
 актуалізація розміщених на Web-сторінці інформаційних ресурсів та керування доступом до них
здійснюється за допомогою АС, в якій повинна бути створена КСЗІ
 характеристики типових умов функціонування такої АС
 детальні вимоги щодо захисту інформації Web-сторінки
 докладно розібрана політика реалізації послуг безпеки інформації в АС, що забезпечує
функціонування Web-сторінки

Категорії інформації Web-сторінок
згідно НД ТЗІ 2.5-010-03
 Інформація Web-сторінки поділяється на дві категорії: загальнодоступна і
технологічна
 Загальнодоступна – інформація, що розміщується на Web-сторінці з метою надання можливості
користування нею будь-яким фізичним або юридичним особам, які мають доступ до мережі
Інтернет
 Технологічна інформація Web-сторінки – технологічна інформація КСЗІ та технологічна
інформація щодо адміністрування та управління обчислювальною системою АС і засобами
обробки інформації
 дані про мережні адреси,
 імена, персональні ідентифікатори та паролі користувачів,
 їхні повноваження та права доступу до об’єктів,
 інформація журналів реєстрації дій користувачів,
 інша інформація баз даних захисту,
 встановлені робочі параметри окремих механізмів або засобів захисту,
 інформація про профілі обладнання та режими його функціонування,
 робочі параметри функціонального ПЗ тощо.
 Розміщення на Web-сторінці конфіденційної інформації діючим законодавством
не припускається
 Якщо інформація не є власністю держави або інформацією з обмеженим доступом, вимога щодо
захисту якої встановлена законом, то власник інформації може запроваджувати правила доступу
до неї на свій розсуд, але при цьому вимоги НД ТЗІ 2.5-010-03 не дотримуються

Технології доступу до інформації
 Web-сторінка може бути розміщена
 на території власника інформації
 на території сторонньої організації (наприклад, оператора мережі доступу до Інтернет)
 Власник інформації, виходячи з чинного законодавства, визначає правила доступу до інформації
 Власник системи здійснює захист інформації, зокрема, забезпечуючи відповідне розмежування доступу
до інформації
 Доступ до технологічної інформації та передавання даних для актуалізації
загальнодоступної інформації може здійснюватись у два способи:
 Технологія Т1: з робочої станції, розміщеної на тій самій території, що і Web-сервер
(установи-власника Web-сторінки або оператора) або з консолі Web-сервера
 Технологія Т2: з робочої станції, яка розміщена на території установи-власника Web-
сторінки, до Web-сервера, що розміщений на території оператора, з використанням мереж
передачі даних
 Технологія Т2 відрізняється від технології Т1:
 наявністю незахищеного середовища, яке не контролюється
 додатковими вимогами щодо ідентифікації та автентифікації між КЗЗ робочої станції й КЗЗ
Web-сервера під час спроби розпочати обмін інформацією
 додатковими вимогами щодо забезпечення цілісності інформації при обміні

Функціональні профілі захищеності
 Коли доступ до технологічної інформації та передавання

даних для актуалізації загальнодоступної інформації
здійснюється за технологією Т1, мінімально необхідний
функціональний профіль визначається:
{КА-2, ЦА-1, ЦО-1, ДВ-1, ДР-1, НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-1}
 Коли передбачається можливість доступу до
технологічної інформації та/або передавання даних для
актуалізації загальнодоступної інформації за технологією
Т2, мінімально необхідний функціональний профіль
визначається:
{КА-2, КВ-1, ЦА-1, ЦО-1, ЦВ-1, ДВ-1, ДР-1,
НР-2, НИ-2, НК-1, НО-1, НЦ-1, НТ-1, НВ-1}
 Мінімальним достатнім рівнем гарантій реалізації КЗЗ
Web-сторінки є рівень Г–2

Оцінювання за критеріями
 Передбачено дві процедури:
 Сертифікація засобів захисту
 Порядок проведення робіт із сертифікації засобів забезпечення
технічного захисту інформації загального призначення
– Наказ Держстандарту України та Департаменту спеціальних
телекомунікаційних систем та захисту інформації Служби безпеки України від
9.07.2001 № 329/32
 Державна експертиза КСЗІ
 Положення про державну експертизу в сфері технічного захисту
– Наказ Адміністрації Державної служби спеціального зв'язку та захисту
інформації України від 16.05.2007 № 93
 Реально побудована система проведення

державної експертизи, як для КСЗІ, так і для засобів
захисту
Безпека
систем
Лекція 06. ISO/IEC 15408 (Common Criteria)

Історія розробки 1/3
 1990 рік: Міжнародна організація із стандартизації (ISO)
розпочинає роботи із створення стандарту у сфері оцінки
безпеки інформаційних технологій (ІТ). Основні цілі розробки:
 уніфікація національних стандартів у сфері оцінки безпеки ІТ
 підвищення рівня довіри до оцінки безпеки ІТ
 скорочення витрат на оцінку безпеки ІТ на основі взаємного визнання
сертифікатів
 Червень 1993 року: організації із стандартизації та забезпечення
безпеки США, Канади, Великої Британії, Франції, Німеччини та
Нідерландів об’єднали свої зусилля в рамках проекту із
створення єдиної сукупності критеріїв оцінки безпеки ІТ
 Проект отримав назву Common Criteria — Загальні критерії (ЗК)
 Також перекладали як “Спільні критерії”, що також певною мірою має сенс
 Задача Загальних критеріїв – забезпечити взаємне визнання результатів
стандартизованої оцінки безпеки на світовому ринку ІТ

 1996 рік: Завершена розробка версії 1.0 Загальних
критеріїв
 Версія 1.0 ЗК ухвалена ISO в квітні 1996 року
 Було проведено ряд експериментальних оцінок на основі версії 1.0
ЗК, а також організовано широке обговорення документу
 1998 рік: Оприлюднена версія 2.0 ЗК
 Ця версія розроблена з урахуванням зауважень і досвіду, що були
отримані під час обговорення й апробації версії 1.0
 1999 рік: На основі версії 2.0 ЗК прийнято міжнародний
стандарт ISO/IEC 15408
 Офіційний текст стандарту виданий 1 грудня 1999 року
 Зміни, що були внесені в стандарт на завершальній стадії його
прийняття, враховані у версії 2.1 ЗК, що ідентична стандарту за
змістом

 Вже після прийняття стандарту з урахуванням досвіду його
використання з’явився ряд інтерпретацій ЗК
 Такі інтерпретації після розгляду Комітетом з інтерпретацій (CCIMB) приймаються,
офіційно оприлюднюються та набувають чинності як діючі зміни й доповнення до ЗК
 2005 рік: Версія 2.2 ЗК стала основою для внесення змін у стандарт ISO
 Версію стандарту позначили як ISO/IEC 15408:2005
 Ідентична їй за змістом версія ЗК – 2.3
 Протягом певного часу паралельно проводили урахування
інтерпретацій (була завершена версія 2.4 ЗК і розроблювали версію 2.6
ЗК) і вели розробку версії 3.0 ЗК, яка має дещо змінену (спрощену)
структуру вимог
 2008 рік: в якості стандарту ISO/IEC 15408:2008 ухвалили версію 3.0 ЗК
 Діюча версія 1-ї частини стандарту була змінена у 2009 році
 Методологія застосування ЗК оформлена у вигляді окремого документа
“Загальна методологія оцінювання безпеки інформаційних технологій” і
також набула статусу стандарту, діюча версія: ISO/IEC 18045:2008

Основні відомості
 У застосуванні до оцінки безпеки продуктів інформаційних
технологій (ПІТ) стандарт задає систему понять, в термінах
яких повинна проводитись оцінка
 Стандарт містить відносно повний каталог вимог безпеки
(функціональних та гарантій), але не надає конкретних
наборів вимог та критеріїв для тих чи інших типів об’єктів
оцінювання (Target of Evaluation, TOE), виконання яких
необхідно перевіряти
 Вимоги та критерії формулюються у профілях захисту
(Protection Profile, PP) та завданнях з безпеки (Security
Target, ST)
 Офіційно прийняті профілі захисту утворюють побудовану
на основі ЗК нормативну базу, що використовується на
практиці у сфері інформаційної безпеки

Структура Загальних
критеріїв
 ЗК є сукупністю самостійних, але взаємопов’язаних частин
1.Розділ Представлення і загальна модель – визначає загальну концепцію й
принципи оцінки безпеки ІТ і подає загальну модель оцінки, а також конструкції
для:
 формування задач захисту ІТ
 вибору й визначення вимог безпеки ІТ
 опису специфікацій високого рівня для продуктів і систем.
2.Розділ Вимоги до функцій безпеки – встановлює набір функціональних
компонентів як стандартний шлях формулювання функціональних вимог до
об’єктів оцінки
3.Розділ Вимоги гарантій безпеки – включає компоненти вимог гарантій оцінки, а
також рівні гарантій оцінки, які визначають ранжирування за ступенем
задоволення вимог
 У версії 1.0 був передбачений розділ Визначені профілі захисту, що містив
приклади профілів захисту, які включали функціональні вимоги безпеки та
вимоги гарантій оцінки, що були ідентифіковані у діючих на той час стандартах
(ITSEC, CTCPEC, FC, TCSEC), а також інші профілі
 Цей розділ був вилучений із ЗК починаючи з версії 2.0 (тобто, до складу стандарту ISO не
увійшов)

Поняття та їх відношення

Поняття з оцінювання та їх
відношення

Базові поняття 1/2
 Об’єкт оцінювання (Target of Evaluation, TOE)
 Загальні критерії є гнучкими у тому, що оцінювати, і як наслідок, не
обмежені продуктами інформаційних технологій, як це зазвичай розуміють
 В контексті оцінювання, Загальні критерії застосовують термін “TOE” (Target
of Evaluation) — об’єкт оцінювання (ОО)
 ОО визначають як набір програмного забезпечення (software, firmware)
та/або апаратного забезпечення (hardware), що, можливо, супроводжується
експлуатаційною документацією (настановами)
 Існують випадки, коли ОО складається з продукту інформаційних технологій
(ПІТ), але це не обов’язково має бути так
 ОО може бути ПІТ, частиною ПІТ, набором ПІТ, унікальною технологією, яка може
ніколи не бути реалізована в якості продукту, або комбінацією вищеназваного
 Задачі захисту (Security Objectives)
 Потреба споживачів ОО
 у протистоянні заданій множині загроз безпеці
 у необхідності реалізації політики безпеки

Базові поняття 2/2
 Профіль захисту (Protection Profile)
 Спеціальний нормативний документ, що містить:
 вступну частину,
 заявку на відповідність,
 визначення проблеми безпеки,
 задачі захисту,
 (опціонально) визначення розширених компонентів,
 вимоги безпеки.
 Профіль захисту можна розглядати як технічне завдання на створення підсистеми захисту ОО
 Профіль захисту не прив’язаний до конкретного ОО
 Завдання з безпеки (Security Target)
 Спеціальний нормативний документ, що містить:
 вступну частину,
 заявку на відповідність,
 визначення проблеми безпеки,
 задачі захисту,
 (опціонально) визначення розширених компонентів,
 вимоги безпеки,
 загальні специфікації засобів захисту ОО.
 Розробляється для конкретного ОО
 У ході кваліфікаційного аналізу служить як опис функцій безпеки ОО

Три стадії процесу
кваліфікаційного аналізу
1.Аналіз Профілю захисту на предмет
 його повноти,
 несуперечності,
 можливості реалізації та
 можливості використання як набору вимог для ОО
2.Аналіз Завдання з безпеки на предмет
 його відповідності вимогам профілю захисту,
 повноти,
 несуперечності,
 можливості реалізації та
 можливості використання як опису ОО
3.Аналіз ОО на предмет відповідності Завданню з безпеки

Процес кваліфікаційного
аналізу

Структура вимог
 Функціональні вимоги (частина 2) та вимоги гарантій (частина 3) подані в
одному спільному стилі та використовують одну і ту саму організацію та
термінологію
 Клас
 Термін клас використовується для найбільш загального групування вимог безпеки
 Усі члени класу поділяють спільний намір при різниці в охопленні цілей безпеки
 Сімейство
 Члени класу названі сімействами
 Сімейство – це групування наборів вимог безпеки, які забезпечують виконання певної частини
цілей безпеки, але можуть відрізнятись в акценті або жорсткості
 Компонент
 Члени сімейства названі компонентами
 Компонент описує визначений набір вимог безпеки – найменший набір вимог безпеки, що
обирається для включення у структури, визначені в ЗК
 Елемент
 Компоненти побудовані з елементів
 Елемент – найнижчий і неподільний рівень вимог безпеки, на якому проводиться оцінка їх
виконання

Набори структур
 ЗК визначають набори структур, що поєднують компоненти вимог
безпеки
 Пакет — це проміжна комбінація компонентів
 Пакет включає набір вимог, які забезпечують виконання піднабору задач
захисту
 Пакет призначений для багаторазового використання
 Пакет визначає вимоги, які є необхідними для досягнення ідентифікованих
задач
 Пакет може використовуватись для формування Профілів захисту і Завдань з
безпеки
 Рівні гарантій оцінки (EAL) – це визначені пакети вимог гарантій
 Рівень гарантій – це набір базових вимог гарантій для оцінки
 Дуже часто EAL використовують як міру рівня захищеності продукту,
визначеного у ході кваліфікаційного аналізу
 Насправді, це не відповідає основній концепції ЗК, і в деяких випадках може давати
взагалі хибне уявлення

Перетворення компонентів
 Компоненти можуть бути перетворені за допомогою дозволених дій, щоби
забезпечити виконання певної політики безпеки або протистояти певній загрозі
 Не усі дії припустимі на усіх компонентах
 Кожний компонент ідентифікує і визначає дозволені дії або обставини, за яких дія може
застосовуватись до компонента, а також результати застосування дії
 До дозволених дій належать:
 Призначення
 Призначення дозволяє заповнити специфікацію ідентифікованого параметра при використанні компонента
 Параметр може бути ознакою або правилом, що конкретизує вимоги до певної величини або діапазону
величин.
 Вибір
 Вибір – це дія вибору одного чи більшої кількості пунктів із списку, щоби конкретизувати можливості
елементу
 Обробка
 Обробка дозволяє включити додаткові деталі в елемент, і передбачає інтерпретацію вимоги, правила,
константи або умови, засновану на задачах захисту
 Обробка повинна лише обмежувати набір можливих функцій або механізмів, щоби здійснити вимоги, але не
збільшувати їх
 Обробка не дозволяє створювати нові вимоги або видаляти ті, що існують, і не впливає на список
залежностей, що пов’язані з компонентом

Таксономія вимог
Функціональні вимоги – класи 1/2
 FAU – Аудит безпеки
 Вимоги до розпізнання, реєстрації, зберігання та аналізу інформації, що пов’язана з діями,
що стосуються безпеки об’єкта оцінювання (ОО)
 FCO – Інформаційний обмін
 Вимоги до визначення ідентичності сторін, що беруть участь в обміні даними
 FCS – Криптографічна підтримка
 FDP – Захист інформації користувача
 Вимоги до функцій безпеки ОО та політики функцій безпеки ОО, що пов’язані із захистом
даних користувача
 FIA – Ідентифікація й автентифікація
 Вимоги до функцій, що призначені для встановлення й перевірки ідентичності користувача
 FMT – Керування безпекою
 Вимоги, що пов’язані з керуванням безпекою ОО
 FPR – Конфіденційність доступу до системи
 Вимоги таємності, що забезпечують захист користувача від розкриття й невірного
використання його ідентифікаторів іншими користувачами

Функціональні вимоги – класи 2/2
 FPT – Захист функцій безпеки
 Вимоги, що стосуються цілісності та контролю механізмів, що забезпечують функції
безпеки, та цілісності й контролю даних функцій безпеки
 FRU – Контроль за використанням ресурсів
 FTA – Контроль доступу до системи
 Функціональні вимоги, понад вимог ідентифікації й автентифікації, для керування
сеансом роботи користувача
 FTP – Забезпечення прямої взаємодії
 Вимоги до забезпечення надійного маршруту зв’язку між користувачами і функціями
безпеки та надійного каналу зв’язку між функціями безпеки, що мають такі спільні
характеристики:
 маршрут комунікацій побудований із застосуванням внутрішніх і зовнішніх каналів комунікацій, що
ізолюють ідентифікований піднабір даних та команд функцій безпеки від інших частин функцій
безпеки та даних користувача;
 використання маршруту комунікацій може бути ініційовано користувачем та/або функцією безпеки;
 маршрут комунікацій здатний забезпечити гарантії того, що користувач взаємодіє з потрібною
функцією безпеки і що функція безпеки взаємодіє з потрібним користувачем, тобто забезпечується
надійна ідентифікація кінцевих пунктів.

Вимоги гарантій – класи
 APE – Оцінка профілю захисту
 Вимоги до оцінки профілю захисту з метою підтвердження того, що він є повним, несуперечливим, технічно
вірним, і таким чином придатним для розробки завдань з безпеки і для занесення в реєстр
 ASE – Оцінка завдання з безпеки
 Вимоги до оцінки завдання з безпеки з метою підтвердження того, що воно є повним, несуперечливим,
технічно вірним, і таким чином придатним для використання в якості основи для оцінки відповідного ОО
 ADV – Розробка
 Вимоги до процесу розробки, що дозволяють перевірити, чи були фактично відпрацьовані функції безпеки
 AGD – Документація
 Вимоги до зрозумілості, повноти й завершеності експлуатаційної документації
 ALC – Підтримка життєвого циклу
 Вимоги до прийняття добре визначеної моделі етапів життєвого циклу ОО
 ATE – Тестування
 Вимоги до об’єму, глибини та виду тестування ОО
 AVA – Оцінка вразливості
 Вимоги, що спрямовані на виявлення вразливих місць
 ACO – Інтеграція
 Вимоги, що надають впевненості у тому, що інтегрований ОО буде функціонувати безпечно, якщо він
спирається на функції захисту раніше оцінених компонентів

Обов’язковий зміст
Завдання з безпеки
 Завдання з безпеки повинно містити:
a)вступну частину, що містить три описи ОО на різних рівнях абстракції;
b)заявку на відповідність, що демонструє, чи претендує Завдання з безпеки на
відповідність будь-яким профілям захисту та/або пакетам, і якщо так, то яким саме;
c)визначення проблеми безпеки (a security problem definition), що демонструє загрози
(threats), організаційні політики безпеки (OSPs) і припущення (assumptions);
d)задачі захисту (security objectives), що демонструють як вирішення проблеми
безпеки розподіляється між задачами захисту ОО і задачами захисту операційного
середовища (оточення) ОО;
e)(опціонально) визначення розширених компонентів, де можуть бути визначені нові
компоненти (тобто ті, що не включені в частину 2 або частину 3 ЗК). Ці нові
компоненти необхідні для визначення розширених функціональних вимог і
розширених вимог гарантій;
f) вимоги безпеки, де наводиться трансляція (“переклад”) задач захисту ОО у
стандартизовану мову. Ця стандартизована мова має форму функціональних вимог
безпеки (SFRs). Додатково, цей розділ визначає вимоги гарантій безпеки (SARs);
g)підсумкову специфікацію ОО, що демонструє як в ОО досягнуто виконання
функціональних вимог безпеки.

Зміст
Завдання
з безпеки

Структура Завдання з
безпеки згідно ЗК версії 2
 Вступ  Загальні специфікації ОО
 Ідентифікатор  Специфікації функцій захисту
 Огляд змісту  Специфікації рівня гарантій
 Заявка на відповідність ЗК  Заявка на відповідність профілю
захисту
 Опис ОО
 Посилання на профіль захисту
 Середовище експлуатації
 Відповідність профілю захисту
 Загрози безпеці
 Удосконалення профілю захисту
 Умови експлуатації  Обґрунтування
 Задачі захисту
 Обґрунтування задач захисту
 Задачі захисту ОО
 Обґрунтування вимог безпеки
 Інші задачі захисту
 Обґрунтування функцій захисту
 Обґрунтування рівня гарантій
 Вимоги безпеки
 Обґрунтування відповідності профілю
 Функціональні вимоги захисту
 Вимоги гарантій
 Вимоги до середовища експлуатації

Структура Завдання з
безпеки згідно ЗК версії 3
 Вступ  Вимоги безпеки
 Ідентифікатор ЗБ  Функціональні вимоги
 Ідентифікатор ОО  Вимоги гарантій
 Огляд ОО  Вимоги до середовища експлуатації
 Опис ОО  Задачі захисту
 Заявка на відповідність  Задачі захисту ОО
 Заявка на відповідність ЗК
 Задачі захисту операційного
середовища
 Заявка на відповідність Профілю  Обґрунтування задач захисту
захисту
 Заявка на відповідність Пакетам вимог
 Визначення розширених
компонентів
 Обґрунтування відповідності
 Вимоги безпеки
 Визначення проблеми безпеки
 Функціональні вимоги безпеки
 Загрози
 Вимоги гарантій безпеки
 Організаційні політики безпеки  Обґрунтування вимог безпеки
 Припущення
 Підсумкова специфікація ОО

Як має використовуватись
Завдання з безпеки
 Типово, Завдання з безпеки виконує дві функції:
1.До і під час кваліфікаційного аналізу, Завдання з безпеки
визначає “що має бути оцінено”
 У цій ролі, Завдання з безпеки служить як основа для угоди між
розробником і оцінювачем щодо конкретних властивостей безпеки ОО і
конкретного предмету кваліфікаційного аналізу
 Технічна коректність і повнота є головними проблемами для цієї ролі
2.Після завершення кваліфікаційного аналізу, Завдання з безпеки
визначає “що було оцінено”
 У цій ролі, Завдання з безпеки служить як основа для угоди між
розробником або постачальником ОО і потенційним споживачем ОО
 Завдання з безпеки описує властивості безпеки ОО в абстрактному стилі, і
потенційний споживач може покладатись на цей опис тому що ОО був
оцінений на відповідність Завданню з безпеки
 Простота використання і зрозумілість є головними проблемами для цієї ролі

Як Завдання з безпеки
використовуватись не повинно
 Дві функції (з багатьох), які Завдання з безпеки не повинно мати:
1.Детальна специфікація:
 Завдання з безпеки призначене для того, щоби бути описом безпеки на
відносно високому рівні абстракції
 Завдання з безпеки у загальному випадку не повинно містити детальних
специфікацій протоколів, детальних описів алгоритмів та/або механізмів,
довгих описів деталізованих процедур, тощо
2.Повна специфікація:
 Завдання з безпеки призначене для того, щоби бути специфікацією безпеки
але не загальною специфікацією
 Якщо вони не стосуються безпеки, такі властивості як сумісність, фізичні
розміри та вага, потрібна напруга тощо, не повинні бути частиною Завдання
з безпеки
 Це означає, що у загальному випадку Завдання з безпеки може бути
частиною повної специфікації, але не самою повною специфікацією

Обов’язковий зміст
профілю захисту
 Профіль захисту містить:
a)вступну частину, що містить опис типу ОО;
b)заявку на відповідність, що демонструє, чи претендує профіль захисту на
відповідність будь-яким профілям захисту та/або пакетам, і якщо так, то яким
саме;
c)визначення проблеми безпеки, що описує загрози, організаційні політики
безпеки та припущення;
d)задачі захисту, що описують, як вирішення проблеми безпеки розподіляється
між задачами захисту ОО та задачами захисту операційного середовища
(оточення) ОО;
e)визначення розширених компонентів, де можуть бути визначені нові
компоненти (тобто ті, що не включені в частину 2 або частину 3 ЗК). Ці нові
компоненти необхідні для визначення розширених функціональних вимог і
розширених вимог гарантій;
f) вимоги безпеки, де наводиться трансляція (“переклад”) задач захисту ОО у
стандартизовану мову. Ця стандартизована мова має форму функціональних
вимог безпеки (SFRs). Додатково, цей розділ визначає вимоги гарантій
безпеки (SARs).

Зміст
Профілю захисту

Структура профілю захисту
згідно ЗК версії 2
 Вступ  Функціональні вимоги
 Ідентифікатор  Вимоги гарантій
 Огляд змісту
 Вимоги до
 Опис ОО
 Середовище експлуатації експлуатації
 Загрози безпеці
 Додаткові відомості
 Умови експлуатації  Обґрунтування
 Задачі захисту  Обґрунтування задач
захисту
 Задачі захисту ОО
 Інші задачі захисту
 Обґрунтування вимог
безпеки

Структура профілю захисту
гідно ЗК версії 3
 Вступ  Задачі захисту
 Ідентифікатор профілю  Задачі захисту ОО
 Опис ОО  Задачі захисту операційного
 Заявка на відповідність
 Обґрунтування задач захисту
 Заявка на відповідність ЗК
 Відповідність Профілю захисту
 Визначення розширених
 Обґрунтування відповідності
 Формулювання відповідності  Вимоги безпеки
 Визначення проблеми
 Функціональні вимоги безпеки
безпеки  Вимоги гарантій безпеки
 Загрози безпеці  Обґрунтування вимог безпеки
 Організаційні політики безпеки
 Припущення

Як має використовуватись
Профіль захисту
 Зазвичай, Профіль захисту є формулюванням потреб, коли
співтовариство користувачів, регуляторний орган, або група
розробників визначають загальний набір потреб захисту
 Профіль захисту надає споживачам засіб посилання на такий
набір, і полегшує подальшу оцінку на відповідність цим потребам
 Таким чином, Профіль захисту зазвичай використовують як:
1.частину специфікацій вимог конкретного споживача або групи споживачів, які
розглядатимуть придбання певного типу продуктів ІТ лише якщо він
задовольняє вимогам цього профілю захисту;
2.частину директивних вимог певного регуляторного органу, який дозволить
використання певного типу продуктів ІТ якщо він задовольняє вимогам цього
профілю захисту;
3.деякі базові вимоги, визначені групою розробників ІТ, які домовляються, що усі
продукти ІТ визначеного типу, що вони виробляють, будуть задовольняти цим
вимогам,
хоча це не заперечує інші можливості застосування.

Як профіль захисту
використовуватись не повинен
 Три функції (з багатьох), які Профіль захисту виконувати не повинен:
1.детальна специфікація:
 Профіль захисту призначений бути специфікацією безпеки на порівняно високому рівні
абстракції
 У загальному випадку Профіль захисту не повинен містити деталізовані специфікації
протоколів, деталізовані описи алгоритмів та/або механізмів, довгі описи деталізованих
процедур тощо
2.повна специфікація:
 Профіль захисту призначений бути специфікацією безпеки але не загальною
специфікацією
 Якщо вони не мають відношення до безпеки, такі властивості як сумісність, фізичні розміри
та вага, потрібна напруга живлення тощо, не повинні бути частиною Профілю захисту
 Це означає, що у загальному випадку Профіль захисту є частиною повної специфікації, але
не самою повною специфікацією
3.специфікація одного продукту:
 На відміну від Завдання з безпеки, профіль захисту призначений для опису певного типу ІТ,
але не одного продукту
 Якщо описують один продукт, для цього краще застосовувати Завдання з безпеки

Роль сертифікації
 Сертифікація за Загальними критеріями не
може гарантувати безпеку
 Натомість, сертифікація може гарантувати, що
заяви щодо властивостей безпеки оціненого
продукту були перевірені незалежно
 Іншими словами, продукти, що оцінені за стандартом
Загальні критерії, демонструють прозорі докази того,
що процеси специфікації, впровадження та оцінювання
були проведені ретельним і стандартним шляхом
 Зверніть увагу! - EAL не рівень безпеки продукту, а
рівень гарантій того, що оцінювання є повним і
достовірним (Evaluation Assurance Level)

Критика
У різних джерелах формулювали такі зауваження до процесу і
методології оцінювання за Загальними критеріями:
 Оцінювання – дорогий процес ($XXX,XXX), а в результаті постачальник не
обов’язково отримує більш безпечний продукт
 Кваліфікаційний аналіз насамперед фокусується на оцінці документації, а не
на реальній безпеці, технічній коректності або перевагах самого продукту
 При оцінюванні в США, лише для EAL5 і вище залучають експертів з АНБ, і
лише для EAL7 необхідний аналіз усього вихідного коду
 На підготовку матеріалів для оцінювання необхідно так багато часу, що коли
оцінювання завершено, продукт може вже стати застарілим (вийшла нова
версія або оновлення безпеки)
 Висловлювали думку, що вимоги гарантій Загальних критеріїв певною мірою
прив’язані до каскадної моделі розробки програмного забезпечення, і
дискримінують гнучкі моделі розробки, що веде до дискримінації вільного ПЗ
з відкритим кодом
 Немає належного контролю за виробництвом продуктів після їх сертифікації

Безпека
систем
Лекції 07-09. Засоби захисту Windows

Надійні джерела
 Windows Internals, 7th Edition by Mark E. Russinovich, Andrea Allievi,
Alex Ionescu, David A. Solomon
 Windows Internals, Seventh Edition, Part 1: System architecture, processes, threads, memory
management, and more by Pavel Yosifovich, Alex Ionescu, Mark E. Russinovich, and David A.
Solomon. - Microsoft Press, 2017. - ISBN: 978-0-7356-8418-8
 Windows Internals, Seventh Edition, Part 2 by Andrea Allievi, Alex Ionescu, Mark E.
Russinovich, and David A. Solomon. - Microsoft Press, 2021. - ISBN: 978-0-13-546240-9
 Найдетальніший опис того, як Windows влаштована і працює
 Фактично, це декларація можливостей Windows від розробника
 Microsoft Windows 10, Windows Server (April 2018 Update) Security
Target
 Документ, підготовлений фахівцями Microsoft для сертифікації чергової версії
системи за стандартом ISO/IEC 15408:2008
 Фактично, це декларація можливостей Windows з урахуванням необхідності
підтвердження заявлених функцій у ході випробувань незалежними експертами
 З іншого боку, Security Target описує лише функції безпеки, і не є ані повною, ані
детальною специфікацією
Безпека ОС - Лекції 7-9 2/106

Коротка характеристика
системи
TOE Overview за Security Target
 Об’єкт оцінювання включає:
 Операційну систему Windows 10,
 Операційну систему Windows Server,
 Програми, необхідні для керування, підтримки та конфігурування операційної системи
 Windows 10 і Windows Server можуть постачатись попередньо
встановленими на новому комп’ютері або можуть бути скачані з
вебсайту Microsoft
 Усі редакції Windows 10 і Windows Server, що узагальнено називають
“Windows”, є багатозадачними (з підтримкою витісняльної — preemptive
— багатозадачності), багатопроцесорними і багатокористувацькими
операційними системами
 Базова функція операційних систем — надавати користувачам можливість керувати
розподілом обчислювальних ресурсів таких як процесори, пам’ять і пристрої
введення-виведення
 Додатково до цього, Windows надає можливості керування і розподілу ресурсів
вищого рівня, таких як security principals (облікові записи користувачів або
комп’ютерів), файли, об’єкти друку, сервіси (служби), віконні станції, робочі столи,
криптографічні ключі, трафік мережних портів, об’єкти каталогів і веб контент.

Використання Windows
 Windows 10 призначена для десктопів, ноутбуків і
конвертованих комп’ютерів
 Ця система призначена для робочих станцій, і хоча вона може
використовуватись сама по собі, вона спроектована щоби
служити клієнтом в доменах Windows
 Windows Server побудований для навантажень у
діапазоні від відділу до підприємства і до хмарних
сервісів. Сервер забезпечує:
 Розумне спільне використання файлів і принтерів;
 Безпечні з’єднання засновані на технологіях Інтернету;
 Централізоване управління політиками робочих станцій.
 Windows надає інтерактивний інтерфейс користувача
— User Interface (UI) — а також мережний інтерфейс

Визначення проблеми
безпеки
згідно Security Target
 Визначення проблеми безпеки складається з
 Загроз безпеці
 Організаційних політик безпеки
 (не визначені для GP OS PP та WLAN EP)
 Припущень щодо використання
 Припущення, загрози та політики скопійовані з:
 the General Purpose Operating Systems Protection Profile,
Version 4.1, March 9, 2016 (“GP OS PP”)
 the General Purpose Operating Systems Protection Profile/
Mobile Device Fundamentals Protection Profile Extended
Package (EP) Wireless Local Area Network (WLAN) Clients
(“WLAN EP”)

Модель загроз для
Windows
 T.NETWORK_ATTACK (Мережна атака)
 Зловмисник знаходиться у каналі зв’язку або десь в мережній інфраструктурі
 Зловмисники можуть вступати в інформаційний обмін з прикладними програмами і сервісами,
що працюють під керуванням або є частиною ОС, з метою компрометації
 Такий обмін може бути модифікуванням встановлених легітимних обмінів
 T.NETWORK_EAVESDROP (Прослуховування мережі)
 Зловмисник знаходиться у каналі зв’язку або десь в мережній інфраструктурі
 Зловмисники можуть здійснювати моніторинг і отримувати доступ до до даних, якими
обмінюються прикладні програми і сервіси, що працюють під керуванням або є частиною ОС
 T.LOCAL_ATTACK (Локальна атака)
 Зловмисник може скомпрометувати прикладні програми, що виконуються під керуванням ОС
 Скомпрометована прикладна програма може надавати спеціально (зловмисно) сформовані
дані для ОС через низку каналів обміну, включаючи непривілейовані системні виклики і обмін
повідомленнями через файлову систему
 T.LIMITED_PHYSICAL_ACCESS (Обмежений фізичний доступ)
 Зловмисник може намагатись здійснити доступ до даних ОС в умовах обмеженого часу з
фізичним пристроєм

Додаткова модель загроз для
Windows (WLAN EP Threats)
EP = Extended Package
 T.TSF_FAILURE (Відмова КЗЗ)
 Механізми безпеки Windows здебільшого побудовані з примітивного набору механізмів
(як-то керування пам’яттю, привілейовані режими виконання процессів) утворюючи
складніші набори механізмів
 Відмова примітивних механізмів може призвести до компрометації більш складних
механізмів, що призводить до компрометації КЗЗ
 T.UNAUTHORIZED_ACCESS (Несанкціонований доступ)
 Користувач може отримати несанкціонований доступ до даних і виконуваного коду
Windows
 Зловмисний користувач, процес, або зовнішня сутність можуть здійснювати “маскарад”,
удаючи із себе авторизовану сутність для отримання несанкціонованого доступу до даних
або ресурсів Windows
 Зловмисний користувач, процес, або зовнішня сутність можуть удавати із себе Windows
або її компонент для отримання даних ідентифікації та автентифікації
 T.UNDETECTED_ACTIONS (Невиявлені дії)
 Зловмисні користувачі або зовнішні сутності можуть вчиняти дії що ворожо впливають на
безпеку Windows
 Такі дії можуть залишатись непоміченими і таким чином їхній вплив не зможе бути
ефективно зниженим

Припущення щодо безпечного
використання Windows
 A.PLATFORM (Платформа)
 Операційна система покладається на надійну обчислювальну
платформу для її виконання
 A.PROPER_USER (Належний користувач)
 Користувач операційної системи не є навмисно недбалим або
ворожим, і використовує програмне забезпечення у відповідності
з впровадженою корпоративною політикою безпеки
 У той же час, зловмисне програмне забезпечення може діяти як
користувач, тому вимоги, що обмежують зловмисних суб’єктів,
залишаються чинними
 A.PROPER_ADMIN (Належний адміністратор)
 Адміністратор операційної системи не є легковажним, навмисно
недбалим або ворожим, і адмініструє операційну систему у
відповідності з впровадженою корпоративною політикою безпеки

Припущення WLAN EP щодо
безпечного використання Windows
 A.NO_TOE_BYPASS (Немає обходу Windows)

 Інформація не може передаватись між бездротовим
клієнтом і внутрішньою дротовою мережею без проходу
через Windows
 A.TRUSTED_ADMIN (Довірений
адміністратор)
 Адміністраторам Windows довіряють, що вони виконують і
застосовують усі настанови адміністраторів надійним
чином

Компоненти КЗЗ Windows 1/6
Згідно “Windows Internals”
 Монітор безпеки (Security Reference Monitor, SRM)
 Компонент системи (Ntoskrnl.exe), що виконується в режимі ядра і
відповідає за перевірку прав доступу до об’єктів, операції над
привілеями (правами користувачів) й генерацію повідомлень аудиту
безпеки
 Підсистема локальної безпеки (Local Security Authority
Subsystem Service, Lsass)
 Процес режиму користувача (Lsass.exe), що відповідає за політику
безпеки в локальній системі (наприклад, визначає коло користувачів,
що мають право на вхід в систему, правила, пов’язані з паролями,
привілеї, що видані користувачам та їх групам, параметри аудиту
безпеки системи), а також за автентифікацію користувачів і передачу
повідомлень аудиту безпеки в Event Log
 Основну частину цієї функціональності реалізує Local Security
Authority Service (Lsasrv.dll) – DLL-модуль, що його завантажує
Lsass
 LSAIso.exe (Відомий також як Credential Guard)

 Підтримується на системах Windows 10 і Server 2016
 Використовується Lsass (якщо це сконфігуровано) для зберігання хешів токенів
користувачів, замість того, щоби зберігати їх у пам’яті Lsass
 Оскільки Lsaiso.exe є “трастлетом” (Trustlet) — ізольованим процесом режиму
користувача, що виконується в VTL 1 (Virtual Trust Level 1), жодний звичайний процес, і
навіть звичайне ядро, не можуть здійснити доступ до його адресного простору
 Сам Lsass зберігає зашифрований бінарний об’єкт (blob) хешу паролю, який потрібен
коли він зв’язується з Lsaiso (через ALPC)
 База даних політики Lsass
 База даних, що зберігає параметри політики безпеки локальної системи
 Розташована в розділі реєстру HKLM\SECURITY та включає таку інформацію:
 яким доменам довірено автентифікацію спроб входу до системи
 хто має права на доступ до системи й яким чином
 кому надані ті або інші привілеї
 які види аудиту потрібно виконувати
 База даних політики Lsass також зберігає «таємниці», які включають в себе реєстраційні
дані, що застосовуються для входу до домену та під час виклику Win32-сервісів

 Диспетчер облікових записів безпеки (Security Accounts Manager, SAM)
 Сервіс (служба), що відповідає за підтримку бази даних, яка зберігає імена користувачів і
груп, визначених на локальній машині
 Служба SAM, реалізована у модулі Samsrv.dll, виконується в процесі Lsass
 База даних SAM
 База даних, що зберігає інформацію про локальних користувачів та групи, разом з їхніми
паролями та іншими атрибутами
 Ця база даних розташована в розділі реєстру HKLM\SAM
 На контролерах домену SAM не зберігає користувачів, визначених у домені, а натомість
зберігає дані (і пароль) облікового запису системного адміністратора для відновлення
системи
 Active Directory
 Служба каталогів, що зберігає базу даних із відомостями про об’єкти в домені
 Active Directory зберігає інформацію про об’єкт домену, у тому числі про користувачів, групи й
комп’ютери. Відомості про паролі й привілеї користувачів домену та їхні групи зберігаються в
Active Directory та реплікуються на комп’ютери, що виконують роль контролерів домену.
 Сервер Active Directory реалізований у модулі Ntdsa.dll, виконується в процесі Lsass

 Пакети автентифікації
 DLL-модулі, що виконуються як у контексті процесу Lsass, так і у контексті клієнтських
процесів, і реалізують політику автентифікації у Windows
 DLL-автентифікація відповідає за перевірку пароля й імені користувача, а також
повернення Lsass (у разі вдалої перевірки) докладної інформації про права користувача,
що Lsass використовує при створенні токена
 Інтерактивний диспетчер входу в систему (Winlogon)
 Процес режиму користувача (Winlogon.exe), що відповідає за підтримку SAS (Secure
Attention Sequence) і керування сеансами інтерактивного входу в систему
 В процесі входу користувача в систему Winlogon створює перший процес користувача
 Користувацький інтерфейс входу в систему — Logon user interface
(LogonUI)
 Процес режиму користувача (LogonUI.exe), що надає користувачам інтерфейс, який
може бути застосований ними для самоідентифікації у системі.
 Процес стартує по запиту від Winlogon під час виконання SAS
 LogonUI використовує постачальників облікових даних («провайдерів») для запиту
облікових даних користувача за допомогою різних методів

 Постачальники облікових даних — Credential providers (CP)

 COM-об’єкти, що виконуються в процесі LogonUI, і які використовують для
одержання імені користувача і пароля, PIN-кода смарт-карти,
біометричних даних (наприклад, відбитка пальця) або інших
ідентифікаційних даних
 Стандартними CP є бібліотеки authui.dll, SmartcardCredentialProvider.dll,
Bio.Cred.Prov.dll та FaceCredentialProvider.dll (останню додали у
Windows 10)
 Служба мережного входу до системи (Netlogon)
 Сервіс Windows (Netlogon.dll), виконується в Lsass (або в SvcHost —
залежить від версії системи) і встановлює захищений канал до контролеру
домену, через який спрямовуються запити такі як інтерактивний вхід (якщо
домен контролер працює під Windows NT 4) або валідація автентифікації
LAN Manager та NT LAN Manager (v1 та v2)
 Netlogon також використовується для входу в Active Directory

 Kernel Security Device Driver (KSecDD)

 Бібліотека функцій режиму ядра (Ksecdd.sys), що реалізує інтерфейси
локального виклику процедур (Advanced Local Procedure Call, ALPC)
 ALPC використовується іншими компонентами захисту режиму ядра –
у тому числі файловою системою, що шифрує (Encrypting File
System, EFS) – для взаємодії з Lsass у режимі користувача
 AppLocker
 Механізм, що дозволяє адміністраторам визначати, які виконувані
файли, DLL-бібліотеки і сценарії можуть використовуватись
конкретними користувачами і групами
 AppLocker складається з драйвера (AppId.sys) і служби
(AppIdSvc.dll), що виконується у процесі SvcHost

Взаємодія компонентів й БД
системи безпеки
Ілюстрація з Windows Internals, Part 1, 7th edition

Захист на основі віртуалізації
 Windows 10 and Server 2016 включають архітектуру безпеки на основі
віртуалізації (Virtualization-Based Security, VBS), що забезпечує
додатковий ортогональний рівень віртуального захисту (virtual trust
level, VTL)
 Звичайний код режиму користувача і код ядра виконуються в VTL 0, і
нічого не знають про існування VTL 1
 Це означає, що будь-що розміщене в VTL 1 є прихованим і недоступним для коду
VTL 0
 Якщо ШПЗ здатне проникнути в звичайне ядро (наприклад, використовуючи
сторонній драйвер), воно все одно не може отримати доступ до будь-чого в VTL 1,
включаючи навіть код режиму користувача, що виконується у VTL 1 (що має назву
Isolated User Mode)
 Credential Guard і Device Guard підтримують VTLs для захисту даних
користувача і надання додаткового рівня безпеки на основі
обладнання для цифрового підписування коду
 Kernel Patch Protection (KPP) надається компонентом PatchGuard і
підсилюється технологією HyperGuard на основі VBS

Архітектура безпеки на основі
віртуалізації VBS
 На схемі показані основні компоненти VBS:

 Hypervisor-Based Code Integrity (HVCI) та Kernel-Mode Code Integrity (KMCI), які
є основою для Device Guard
 LSA (Lsass.exe) та isolated LSA (LsaIso.exe), які є основою для Credential Guard

КЗЗ Windows 1/2
 Концептуально Windows можна розглядати як набір
сервісів безпеки
 Ці сервіси надаються компонентами Windows:
 Диспетчер завантаження (Boot Manager), який активується
кодом завантаження комп’ютера
 Завантажувач Windows (Windows Loader), який завантажує
операційну систему в пам’ять комп’ютера
 Ядро Windows (Windows Kernel), що містить драйвери
файлової системи, шифрування розділів (full volume
encryption), фільтр аварійного дампу (crash dump filter), і
криптографічну бібліотеку режиму ядра
 Стек IPv4 / IPv6 в ядрі
 Захищений інсталятор Windows (Windows Trusted Installer),
який встановлює оновлення операційної системи Windows

КЗЗ Windows 2/2
 Підсистема локальної автентифікації (Local Security
Authority Subsystem), яка ідентифікує та автентифікує
користувачів перед їх входом у систему і генерує події для
журналу аудиту безпеки
 Криптографічні алгоритми, ухвалені FIPS (FIPS-
Approved cryptographic algorithms), для захисту даних
користувача і системи
 Служба захисту ключів (Key Isolation Service), яка захищає
таємні та приватні ключі
 Локальні та віддалені інтерфейси адміністрування
(administrative interfaces) для управління безпекою
 Windows Explorer, який може використовуватись для
управляння операційною системою та перевірки цілісності
файлів і оновлень Windows

Сервіси безпеки Windows
(TOE Security Services)
 Аудит безпеки (Security Audit)
 Криптографічна підтримка (Cryptographic Support)
 Захист даних користувача (User Data Protection)
 Ідентифікація й автентифікація (Identification and
Authentication)
 Захист КЗЗ (Protection of the TOE Security Functions)
 Блокування сеансу (Session Locking)
 Доступ до ОО (TOE Access)
 Захищений канал взаємодії (Trusted Path for
Communications)
 Управління безпекою (Security Management)
Аудит безпеки
Цей сервіс здійснює:

 Збирання даних аудиту
 Селективний аудит
 Захист журналу аудиту від переповнення
 Захист обмеженого доступу до журналу
аудиту

Збирання даних аудиту
 Служба Windows Event Log створює журнал подій
безпеки (security event log)
 Цей журнал містить записи аудиту, що стосуються безпеки,
зібрані в системі
 Існують інші журнали подій які зареєстровані іншими
провайдерами записів аудиту
 Сервер Local Security Authority (LSA)
 Збирає події аудиту з усіх інших компонентів КЗЗ
 та спрямовує їх до служби Windows Event Log
 Ця служба помістить подію в журнал відповідного провайдера
 Обмежень на розмір окремого запису аудиту немає
 Авторизований адміністратор може визначити обмеження на
розмір кожного з журналів аудиту

Потік даних аудиту

Дані аудиту
 Кожний запис аудиту містить такі стандартні поля:
 Дата події;
 Час події;
 SID користувача, причетного до події;
 Ідентифікатор події (унікальний для кожної категорії);
 Джерело — компонент Windows, що згенерував подію;
 Результат (чи є подія результатом успішної чи неуспішної
спроби);
 Категорія
 Кожний запис аудиту може також містити дані,
специфічні для категорії цієї події, що містяться у
тілі запису
Категорії подій
 Служба LSA визначає такі категорії подій аудиту в
журналі безпеки:
 Система (System);
 Вхід / Вихід (Logon / Logoff);
 Доступ до об’єкта (Object Access);
 Доступ до служби каталогів (Directory Service Access);
 Використання привілеїв (Privilege Use);
 Детальне відстеження процесу (Detailed Process
Tracking);
 Зміна політики (Policy Change);
 Управління обліковими записами (Account Management);
 Вхід в обліковий запис (Account Logon)

Де збирають події аудиту
безпеки
 В КЗЗ є два місця, де збирають події аудиту безпеки
1)В ядрі монітор безпеки (Security Reference Monitor — SRM), що є частиною
виконавчої системи (NT Executive), відповідає за генерування усіх подій аудиту
таких категорій:
 Доступ до об’єктів,
 Використання привілеїв,
 Детальне відстеження процесу.
Компоненти Windows можуть запросити SRM згенерувати запис аудиту і надати
усі елементи цього запису крім системного часу, який надає виконавча система
2)За одним винятком, події аудиту для інших категорій подій генерують різні
служби, які
 Або співіснують в сервері LSA,
 Або, маючи привілей SeAuditPrivilege, викликають інтерфейси AuthZ Report Audit,
імплементовані в субкомпоненті LSA Policy
 Винятком є те, що сама служба Event Log Service створює запис події, коли
 Здійснюють очищення журналу безпеки
 Або журнал безпеки перевищує рівень попередження, встановлений авторизованим
адміністратором

Політика аудиту 1/2
 Сервер LSA підтримує в своїй базі даних
політику аудиту, що визначає, які категорії
подій повинні збиратися
 Визначення і модифікація політики аудиту дозволені
лише авторизованому адміністратору
 Єдиний інший компонент КЗЗ, що застосовує
політику аудиту — це SRM, який веде аудит
доступу до об’єктів, використання привілеїв, і
детального відстеження процесів
 LSA і SRM мають спільний приватний порт зв’язку, який
застосовується для того, щоби передати SRM політику
аудиту

Політика аудиту 2/2
 Додатково до визначення політики аудиту для усієї
системи, можливо визначити політику аудиту для
окремих користувачів (per-user audit policy),
використовуючи auditpol.exe
 Це дозволяє включати або відключати окремі категорії подій аудиту
для окремих користувачів
 Windows не дозволить локальному адміністратору відключити аудит для
облікових записів локальних адміністраторів
 У кожній категорії аудит може здійснюватись для подій
успішних, неуспішних, або усіх
 Для подій доступу до об’єктів аудит може далі
контролюватись на основі ідентифікації
користувача/групи і правах доступу використовуючи
системні списки керування доступом (System Access
Control Lists — SACL), що асоційовані з об’єктами
Криптографічна підтримка
 Криптографічні алгоритми та операції
 Валідація криптографічних
алгоритмів
 Мережний обмін (TLS)
 Захист даних за допомогою DPAPI

Огляд функцій 1/2
 Windows надає перевірені FIPS 140-2 CAVP
криптографічні функції, які підтримують
 шифрування / дешифрування,
 криптографічні підписи,
 криптографічне хешування,
 договір криптографічного ключа,
 і генерацію випадкових чисел.
 Windows додатково забезпечує:
 підтримку відкритих ключів,
 управління обліковими даними та функції перевірки сертифікатів,
 підтримку криптографічних алгоритмів Агенції національної
безпеки (NSA) Suite B

Огляд функцій 2/2
 Windows також надає
 широку аудиторську підтримку криптографічних операцій,
 можливість замінити криптографічні функції та генератори
випадкових чисел альтернативними реалізаціями,
 послугу ізоляції ключів, призначену для обмеження потенційного
розкриття секретних та приватних ключів.
 Крім використання криптографії для власних функцій
безпеки, Windows пропонує доступ до функцій
криптографічної підтримки програм користувача та
режиму ядра
 Сертифікати відкритих ключів, створені та використані
Windows, перевіряють автентичність користувачів та
машин, а також захищають як дані користувачів, так і
системи, під час передавання мережею
Cryptography API: Next
Generation
 API криптографії наступного покоління (CNG) розроблений як
розширюваний на багатьох рівнях та агностичний для наборів
криптографічних алгоритмів
 Windows використовує CNG виключно для власних потреб шифрування та
надає загальнодоступні API для зовнішніх розробників
 Важливою особливістю CNG є його власна реалізація алгоритмів
Suite B, включаючи алгоритми:
 AES (128, 192, 256-бітні ключі; 192-бітний розмір ключа не використовується
Windows, але доступний розробникам),
 алгоритми хешування сімейства SHA-1 та SHA-2 (SHA-256, SHA-384 та SHA-
512),
 еліптична крива Діффі Хеллмана (ECDH) та еліптична крива DSA (ECDSA) над
стандартними кривими NIST P-256, P-384 та P-521.
 Такі протоколи, як Internet Key Exchange (IKE) та Transport Layer
Security (TLS), використовують еліптичну криву Діффі-Хеллмана
(ECDH), включену в Suite B, а також функції хешування

Детермінована генерація
випадкових бітів
 Детермінована генерація випадкових бітів (Deterministic
Random Bit Generation — DRBG) реалізована відповідно
до Спеціальної публікації NIST 800-90
 Windows генерує випадкові біти, беручи вихідні дані з
 каскаду двох DRBG, заснованих на режимі лічильника SP800-90 AES-256, в
режимі ядра
 і чотирьох каскадних пристроїв SP800-90 AES-256 DRBG в режимі
користувача;
 програмні абоненти можуть вибрати 128 або 256 біт з RBG, який
засіяний з пулу ентропії Windows
 Windows має різні джерела ентропії (детерміновані та
недетерміновані), які виробляють дані ентропії, які
використовуються для генерації випадкових чисел
 Зокрема, ці дані ентропії разом з іншими даними (наприклад, nonce)
породжують алгоритм DRBG

Пул ентропії
 Пул ентропії (Entropy Pool) заповнюється з використанням таких
значень:
 Початкове значення ентропії із насіннєвого файлу, що надається завантажувачу
ОС Windows під час завантаження (512 біт ентропії)
 Завантажувач ОС Windows реалізує SP 800-90 AES-CTR-DRBG і передає ядру 384 біти
ентропії для використання CNG під час ініціалізації.
 Цей DBRG використовує ті самі алгоритми для отримання ентропії з лічильника циклів
процесора, TPM та RDRAND
 Розраховане значення на основі лічильника циклів процесора з високою
роздільною здатністю, який спрацьовує після кожних 1024 переривань
(безперервне джерело, що забезпечує 16384 біти ентропії).
 Випадкові значення, що періодично збираються з модуля довіреної платформи
(TPM), (320 біт ентропії при завантаженні, 384 біти після цього на вимогу на основі
таймера ОС).
 Випадкові значення періодично збираються, викликаючи команду процесора
RDRAND, (256 біт ентропії).
 Кожне джерело ентропії не залежить від інших джерел і не залежить від
часу

Захист криптографічних
функцій
 КЗЗ Windows захищає від фальсифікації джерел генерації
випадкових чисел (Random Number Generation — RNG) /
генерації псевдовипадкових чисел (Pseudorandom Number
Generation — PRNG), інкапсулюючи їх використання в драйвері
пристрою безпеки ядра — Kernel Security Device Driver
 Інтерфейсом для генератора випадкових чисел Windows є
BCryptGenRandom
 Постачальником CNG для генерації випадкових чисел є
AES_CTR_DRBG, коли Windows вимагає використання солі, вона
використовує Windows RBG
 Операції шифрування та дешифрування виконуються
незалежними модулями, відомими як постачальники
криптографічних послуг (Cryptographic Service Providers — CSP)
 Windows генерує симетричні ключі (ключі AES) за допомогою генератора
випадкових чисел, затвердженого FIPS

Інші криптографічні операції
 На додаток до послуг шифрування та дешифрування, TSF надає
інші криптографічні операції, такі як
 хешування
 цифрові підписи
 Хешування використовують інші алгоритми, схвалені FIPS,
реалізовані в Windows
 код автентифікації хешованого повідомлення,
 служби підпису RSA, DSA та EC DSA,
 узгодження ключів Діффі-Хеллмана та еліптична крива Діффі-Хеллмана,
 генерація випадкових бітів
 Коли Windows потребує встановлення спільного секретного ключа
на основі RSA, він може виступати як відправник, так і одержувач
 будь-які помилки дешифрування, які виникають під час встановлення ключа,
представляються користувачеві на дуже абстрагованому рівні, наприклад,
неможливість підключення

Стандарти криптографічних алгоритмів
Windows та методи оцінки 1/2
Криптографічна операція Стандарт Метод оцінки

FIPS 197 AES NIST CAVP # 5847, # 5859,
# 5860, # 5861
NIST SP 800-38A CBC mode # 5847, # 5861
Шифрування/Дешифрування NIST SP 800-38C CCM mode # 5847, # 5859
NIST SP 800-38E XTS mode # 5847
NIST SP 800-38F KW mode # 5860
NIST SP 800-38D GCM mode # 5847
Цифровий підпис (генерація FIPS 186-4 RSA NIST CAVP # 3079, # 3080
ключів)
Цифровий підпис (генерація) FIPS 186-4 RSA NIST CAVP # 3079, # 3080,
# 3082
Цифровий підпис (перевірка) FIPS 186-4 RSA NIST CAVP # 3079, # 3080,
# 3081, # 3082
Цифровий підпис (генерація і FIPS 186-4 DSA NIST CAVP # 1479
перевірка)

Стандарти криптографічних алгоритмів
Windows та методи оцінки 2/2
Криптографічна операція Стандарт Метод оцінки

Цифровий підпис (генерація FIPS 186-4 ECDSA NIST CAVP # 1563, #
ключів) 1564, # 1565
Цифровий підпис (генерація FIPS 186-4 ECDSA NIST CAVP # 1563, # 1564
ключів, генерація і перевірка
підпису)
Хешування FIPS 180-4 SHA-1 and NIST CAVP # 4633
SHA-256, SHA-384, SHA-
512
Код автентифікації FIPS 198-2 HMAC NIST CAVP # 3858, # 3859
повідомлень на основі хешу з
ключем
Генерація випадкових чисел NIST SP 800-90 CTR_DRBG NIST CAVP # 2435, # 2436
Узгодження ключів NIST SP 800-56A ECDH NIST CAVP # 200, # 201
Встановлення ключів NIST SP 800-56B RSA NIST CVL # 2111, # 2112
Виведення ключа на основі SP800-108 NIST CAVP # 242, # 243
ключа
IKEv1, IKEv2, TLS SP800-135 NIST CVL # 2110

Сховище ключів
 CNG включає послугу ізоляції ключів у режимі користувача,
розроблену спеціально для розміщення секретних та приватних
ключів у захищеному процесі для зменшення фальсифікації або
доступу до важливих матеріалів ключів для процесів у режимі
 CNG виконує перевірку виявлення помилок ключа при кожній передачі
ключа
 CNG запобігає архівуванню (приватних) ключів підпису, термін дії яких
завершився, та знищує непостійні криптографічні ключі
 Windows перезаписує кожну проміжну область зберігання для ключа відкритого
тексту / критичного параметра криптографічного захисту
 тобто будь-яке сховище, таке як буфери пам'яті для ключа або пароля відкритого тексту, який
було введено користувачем, включеного в шлях таких даних
 Цей перезапис виконується наступним чином:
 Для енергозалежної пам'яті перезапис — це один прямий перезапис, що складається з нулів за
допомогою функції RtlSecureZeroMemory.
 Зауважте, що адміністративні вказівки виключають сплячий режим комп’ютера, щоб
ключі не зберігалися в нестабільному сховищі

Типи ключів, що використовує
Windows 1/2
Ключі Опис
Symmetric Keys used for AES (FIPS 197) encryption/decryption for
encryption/decryption IPsec ESP, TLS, Wi-Fi.
keys
HMAC keys Keys used for HMAC-SHA1, HMAC-SHA256, HMAC-
SHA384, and HMAC-SHA512 (FIPS 198-1) as part of
IPsec
Asymmetric ECDSA Keys used for the verification of ECDSA digital signatures
Public Keys (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric ECDSA Keys used for the calculation of ECDSA digital signatures
Private Keys (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric RSA Keys used for the verification of RSA digital signatures
Public Keys (FIPS 186-4) for IPsec, TLS, Wi-Fi and signed product
updates.
Asymmetric RSA Keys used for the calculation of RSA digital signatures
Private Keys (FIPS 186-4) for IPsec, TLS, and Wi-Fi as well as TPM-
based health attestations. The key size can be 2048 or
3072 bits.
Типи ключів, що використовує
Windows 2/2
Ключі Опис
Asymmetric DSA Keys used for the calculation of DSA digital signatures
Private Keys (FIPS 186-4) for IPsec and TLS. The key size can be
2048 or 3072 bits.
Asymmetric DSA Keys used for the verification of DSA digital signatures
Public Keys (FIPS 186-4) for IPsec and TLS. The key size can be
2048 or 3072 bits.
DH Private and Private and public values used for Diffie-Hellman key
Public values establishment for TLS.
ECDH Private and Private and public values used for EC Diffie-Hellman key
DPAPI master secret 512-bit random value used by DPAPI
DPAPI master AES 256-bit encryption key that protects the DPAPI master
key secret
DPAPI AES key 256-bit encryption key used by DPAPI
DRBG seed The seed for the main DRBG, zeroized during reseeding
Мережний обмін (TLS)
 Windows реалізує TLS як надійний мережний шлях, який
використовується для автентифікації клієнта та сервера, а
також HTTPS
 Протоколи описані в документах:
 Профіль безпеки транспортного рівня (TLS) MS-TLSP
 RFC 2246 Протокол TLS, версія 1.0
 RFC 3268 AES набори шифрів для TLS
 RFC 3546 Розширення безпеки транспортного рівня (TLS)
 RFC 4366 Розширення безпеки транспортного рівня (TLS)
 RFC 4492 ECC набори шифрів для TLS
 RFC 4681 TLS Розширення картографування користувачів
 RFC 5246 - Протокол безпеки транспортного рівня (TLS), версія 1.2
 RFC 5289 - Набори TLS ECC із SHA-256384 та AES GCM

TLS RFCs Implemented by
Windows
RFC# Назва Як використовується
2246 The TLS Protocol Version 1.0 Specifies requirements for TLS 1.0.
3268 Advanced Encryption Standard (AES) Specifies additional ciphersuites implemented by
Ciphersuites for Transport Layer Security (TLS) Windows.
3546 Transport Layer Security (TLS) Extensions Updates RFC 2246 with TLS 1.0 extensions
implemented by Windows.
4346 The Transport Layer Security (TLS) Protocol Specifies requirements for TLS 1.1.
Version 1.1
4366 Transport Layer Security (TLS) Extensions Obsoletes RFC 3546 Requirements for TLS 1.1
extensions implemented by Windows.
4492 Elliptic Curve Cryptography (ECC) Cipher Suites Specifies additional ciphersuites
for Transport Layer Security (TLS) implemented by Windows.
4681 TLS User Mapping Extension Extends TLS to include a User Principal Name
during the TLS handshake.
5246 The Transport Layer Security (TLS) Protocol Obsoletes RFCs 3268, 4346, and 4366.
Version 1.2 Specifies requirements for TLS 1.2.
5289 TLS Elliptic Curve Cipher Suites with SHA- Specifies additional ciphersuites
256/384 and AES Galois Counter Mode (GCM) implemented by Windows.
SSL3 The SSL Protocol Version 3 Specifies requirements for SSL3.

Особливості реалізації TLS 1/3
 Під час узгодження набору шифрів еліптичної кривої TLS 1.2

Windows автоматично включатиме як частину повідомлення
клієнта Hello:
 його розширення еліптичних кривих, що підтримується, тобто secp256r1,
secp384r1 та secp521r1
 алгоритм підпису, тобто SHA256, SHA384 та SHA512 на основі шифрів,
вибраних адміністратором
 За замовчуванням крива secp521r1 вимкнена
 Цю криву можна включити, додавши її назву у файл замовлення кривої ECC
 Крім того, у цьому файлі можна редагувати пріоритет кривої
 З іншого боку, за замовчуванням алгоритмами підпису в
повідомленні клієнта Hello є: SHA1, SHA256, SHA384 та
SHA512
 Розширення алгоритму підпису можна налаштувати шляхом редагування
розділу реєстру, щоб задовольнити вимогу FCS_TLSC_EXT.3

 Кожен компонент Windows, який використовує TLS, перевіряє,

чи ідентифікаційна інформація у сертифікаті відповідає
очікуваному. Ці перевірки включають перевірку очікуваного
 Визначене ім’я (DN),
 Назва суб'єкта (SN),
 Атрибути альтернативного імені суб’єкта (SAN)
 А також будь-які застосовні ідентифікатори використання розширеного
ключа.
 Ідентифікатор DN та будь-яке альтернативне ім’я суб’єкта у
сертифікаті перевіряється на наявність ідентифікації DNS-
запису або IP-адреси віддаленого комп’ютера, щоб
переконатися, що вони збігаються, як описано в
http://technet.microsoft.com/en-us/library/cc783349(v=WS.10).aspx
зокрема розділ «Повідомлення про сертифікат сервера»

 Референсним ідентифікатором у Windows для TLS є ім'я DNS або

IP-адреса віддаленого сервера, яке порівнюється з іменем DNS у
вигляді представленого ідентифікатора в альтернативному імені
суб'єкта (SAN) або імені суб'єкта сертифіката
 Немає конфігурації референсного ідентифікатора
 Сертифікат, який використовує шаблон у крайній лівій частині
ідентифікатора ресурсу (тобто *.contoso.com), може бути
прийнятий для автентифікації, інакше сертифікат буде визнано
недійсним
 Windows не надає можливості загального призначення "прикріплювати"
сертифікати TLS
 Windows реалізує HTTPS, як описано в RFC 2818, так що Магазин
Windows та системні програми, що виконуються на ОО, можуть
надійно підключатися до зовнішніх серверів за допомогою HTTPS

Бездротова мережа
 Windows має власні реалізації IEEE 802.11-2012 та IEEE
802.11ac-2013 для забезпечення безпечних бездротових
локальних мереж (Wi-Fi)
 Windows може використовувати PRF-384 у сеансах Wi-Fi WPA2 та
генерувати 128-бітові ключі AES або використовувати PRF-704 для
генерації 256-бітових ключів AES, обидва використовують Windows RBG
 Windows відповідає стандартам IEEE 802.11-2012 та IEEE 802.11ac-2013 та
взаємодіє з іншими пристроями, що реалізують стандарт
 Комп’ютери з ОС Windows, як правило, мають сертифікати сумісності Wi-Fi
від Wi-Fi Alliance
 Windows реалізує обгортання та розгортання ключів (wrapping
and unwrapping) відповідно до специфікації NIST SP 800-38F
(режим «KW») і таким чином розгортає тимчасовий ключ групи
Wi-Fi (GTK), який було надіслано точкою доступу
 Оскільки GTK був захищений AES Key Wrap, коли він був доставлений у
кадрі EAPOL-ключа, GTK не демонструється мережі

Захист даних з DPAPI
 Windows надає API захисту даних DPAPI,
який компоненти Windows, власні та
сторонні програми можуть використовувати
для захисту будь-яких збережених даних, які
розробник вважає чутливими
 DPAPI використовуватиме шифрування AES CBC із
ключем, який частково базується на паролі
користувача для захисту даних користувача
 При зберіганні приватних ключів та секретів,
пов’язаних з обліковим записом користувача,
зашифровані дані зберігаються у файловій системі
в каталозі, який є частиною профілю користувача
Захист даних користувача
 Дискреційне керування доступом

(Discretionary Access Control — DAC)
 Клієнт VPN

Дискреційне керування
доступом
 Виконавчий компонент в ядрі Windows опосередковує
доступ між суб'єктами та об'єктами даних
користувача, також відомими як іменовані об'єкти
 Цей компонент ядра — це монітор безпеки (Security Reference
Monitor — SRM)
 Суб'єкти складаються з процесів з одним або
кількома потоками, що виконуються від імені
 Хоча політика дискреційного керування доступом
Windows керує декількома різними типами іменованих
об’єктів, профіль захисту, який є основним для цієї
оцінки, зосереджується на файлах NTFS та об’єктах
каталогів NTFS

Атрибути суб’єктів DAC
 Маркери (токени) доступу Windows (Access Tokens) містять атрибути безпеки
суб’єкта
 Токени пов'язані з процесами та потоками, що працюють від імені користувача
 Інформація в маркері доступу, який використовується DAC, включає:
 Ідентифікатор безпеки (Security ID, SID) для облікового запису користувача
 SID, що представляють групи, учасником яких є користувач
 Привілеї, призначені користувачеві
 SID власника (An Owner SID), який ідентифікує SID, що слід призначити власником для
новостворених об’єктів
 Дискреційний список керування доступом (Discretionary Access Control List, DACL) за
замовчуванням для новостворених об’єктів
 Тип маркера, який є або основним, або маркером уособлення (видавання себе за іншу особу) —
Impersonation Token
 Рівень уособлення (для маркерів уособлення)
 Мітка цілісності SID
 Необов’язковий список обмежуючих SID
 SID входу, який ідентифікує сеанс входу.
 Адміністратор може змінити все це, за винятком SID облікового запису користувача
та SID входу

Уособлені маркери
(Impersonation Tokens)
 Потоку може бути призначений “уособлений маркер” — маркер
видавання себе за іншу особу, — який буде використовуватися
замість основного маркера процесу під час здійснення перевірки
доступу та генерації даних аудиту
 Отже, цей потік уособлює клієнта, який надав уособлений маркер
 Уособлення припиняється, коли уособлений маркер видаляється з потоку або
коли потік закінчується
 Маркер доступу може також містити список обмежувальних SID,
які використовуються для обмеження доступу до об'єктів
 Обмежувальні SID містяться в обмежених маркерах
 Обмежені маркери — це особлива форма маркера уособлення потоку
 При налаштуванні вони служать для обмеження доступу відповідного процесу
до рівня, не більшого, ніж доступний для обмеженого SID
 Рішення щодо доступу приймаються з використанням уособленого
маркера потоку, якщо він існує, а в іншому випадку — основного
маркера процесу потоку (який завжди існує)

Атрибути об’єкта DAC
 Дескриптори безпеки (Security Descriptors — SD) містять усі атрибути безпеки,
пов’язані з об’єктом
 Усі іменовані об'єкти мають пов'язаний SD
 Атрибутами безпеки SD, що використовуються для дискреційного керування
доступом, є:
 SID власника об’єкта, який визначає власника дескриптора безпеки;
 прапор присутності списку дискреційного керування доступом (Discretionary Access Control
List — DACL;
 сам DACL, коли він присутній.
 DACL містять список записів керування доступом (Access Control Entries — ACE)
 Кожен ACE вказує
 тип ACE,
 SID, що представляє користувача або групу,
 маску доступу, що містить набір прав доступу.
 Кожен ACE має пов'язані з ним атрибути успадкування, які вказують, чи
застосовується ACE лише до асоційованого об'єкта, лише до його дочірніх
об'єктів або як до його дочірніх об'єктів, так і до асоційованого об'єкта

Два типи ACE
 Існує два типи ACE, які застосовуються до дискреційного
контролю доступу:
 ДОЗВОЛИТИ ДОСТУП
 ACCESS_ALLOWED_ACE: використовується для надання доступу
користувачеві або групі користувачів.
 ACCESS_ALLOWED_OBJECT_ACE: (для об'єктів служби каталогів), що
використовується для надання доступу користувачеві або групі до властивості
або набору властивостей об'єкту служби каталогів, або для обмеження
наслідування ACE до вказаного типу дочірнього об'єкта. Цей тип ACE
підтримується лише для об’єктів служби каталогів.
 ЗАБОРОНИТИ ДОСТУП
 ACCESS_DENIED_ACE: використовується для заборони доступу користувачеві
або групі користувачів.
 ACCESS_DENIED_OBJECT_ACE: (для об'єктів служби каталогів)
використовується для заборони доступу користувача або групи до властивості
або набору властивостей об'єкту служби каталогів, або для обмеження
наслідування ACE до вказаного типу дочірнього об'єкта. Цей тип ACE
підтримується лише для об’єктів служби каталогів.

Маска доступу
 В ACE маска доступу містить права доступу до об'єкта, надані (або
заборонені) SID, що представляють користувача або групу
 Також маска доступу використовується
 щоб вказати бажаний доступ до об'єкта при доступі до об'єкта
 ідентифікувати наданий доступ, пов'язаний з відкритим об'єктом
 Кожен біт у масці доступу представляє певне право доступу
 Існує чотири категорії прав доступу: стандартні, специфічні, спеціальні та
загальні (generic)
 Стандартні права доступу (Standard Access Rights) застосовуються до всіх типів об’єктів
 Специфічні права доступу (Specific Access Rights) мають різне семантичне значення
залежно від типу об’єкта
 Спеціальні права доступу (Special Access Rights) використовуються в масках бажаного
доступу для запиту спеціального доступу або запиту всіх дозволених прав
 Загальні права доступу (Generic Access Rights) — це зручні поєднання конкретних та
стандартних прав доступу
 Кожен тип об’єкта забезпечує своє власне відображення між загальними
правами доступу та стандартними та спеціальними правами доступу

Таблиці дескрипторів
(Handle Tables)
 Для більшості об’єктів суб’єкт запитує доступ до об’єкта (наприклад,
відкриває його) і отримує у відповідь вказівник на дескриптор (a
pointer to a handle)
 КЗЗ пов'язує надану маску доступу з кожним відкритим дескриптором
 Для об'єктів режиму ядра:
 Дескриптори підтримуються в таблиці дескрипторів режиму ядра
 Для кожного процесу існує одна таблиця дескрипторів
 Кожен запис у таблиці дескрипторів ідентифікує відкритий об’єкт та права доступу,
надані цьому об’єкту
 Для серверів КЗЗ режиму користувача:
 Дескриптор — це контрольований сервером вказівник контексту, пов’язаний із
зв’язком між суб’єктом та сервером
 Сервер використовує цей контекстний дескриптор так само, як і в режимі ядра
 (тобто, щоб знайти відкритий об’єкт і пов’язану з ним маску дозволеного доступу).
 В обох випадках (об'єкти режиму користувача та ядра) SRM приймає
всі рішення щодо керування доступом

Права доступу DAC та
іменовані об’єкти
Каталог NTFS Файл NTFS
ACCESS_SYSTEM_SECURITY ACCESS_SYSTEM_SECURITY
READ_CONTROL READ_CONTROL
WRITE_DAC WRITE_DAC
WRITE_OWNER WRITE_OWNER
SYNCHRONIZE SYNCHRONIZE
FILE_LIST_DIRECTORY FILE_WRITE_DATA
FILE_ADD_FILE FILE_READ_DATA
FILE_ADD_SUBDIRECTORY FILE_APPEND_DATA
FILE_DELETE_CHILD FILE_WRITE_EA
FILE_READ_ATTRIBUTES FILE_EXECUTE
FILE_WRITE_ATTRIBUTES FILE_READ_ATTRIBUTES
FILE_DELETE_CHILD | FILE_WRITE_ATTRIBUTES
FILE_ADD_FILE FILE_WRITE_DATA and FILE_WRITE_ATTRIBUTES
DELETE DELETE
FILE_WRITE_DATA | FILE_READ_DATA
FILE_READ_DATA | FILE_EXECUTE
FILE_READ_DATA | FILE_EXECUTE |
FILE_WRITE_DATA
FILE_WRITE_DATA | FILE_WRITE_EA |
FILE_WRITE_ATTRIBUTES

Алгоритм DAC (огляд)
 КЗЗ застосовує політику DAC до об'єктів на підставі
 SID і привілеїв в маркері запитувача,
 бажаної маски доступу, що запитується,
 дескриптора безпеки об’єкта.
 Для надання доступу всі права доступу, зазначені у бажаній масці доступу,
повинні бути надані одним із наступних кроків
1.Перевірка привілеїв
2.Перевірка власника
3.DACL відсутній
4.DACL присутній, але порожній
5.Ітеративна обробка кожного ACE у тому порядку, в якому вони відображаються в DACL
6.Перевірка доступу щодо обмежуючих SID
 В кінці будь-якого кроку, якщо всі запитувані права доступу надані, доступ
надається
 В кінці алгоритму, якщо будь-яке запитуване право доступу не було
надано, доступ заборонено

Алгоритм DAC 1/3
1.Перевірка привілеїв:
a)Перевірка привілею SeSecurity: Це потрібно, якщо ACCESS_SYSTEM_SECURITY (доступ до
даних аудиту) знаходиться у масці бажаного доступу
 Якщо запитується ACCESS_SYSTEM_SECURITY, а запитувач не має цього привілею, доступ заборонено
 В іншому випадку надається ACCESS_SYSTEM_SECURITY
b)Перевірка привілею SeTakeOwner:
 Якщо маска бажаного доступу має право доступу WRITE_OWNER, а привілей знайдено в маркері
запитувача, тоді доступ WRITE_OWNER надається
c)Перевірка привілею SeBackupPrivilege: привілей резервного копіювання файлів та каталогів
дозволяє суб’єкту читати файли та об’єкти реєстру для операцій резервного копіювання
незалежно від їх ACE в DACL
 Якщо процес має привілей SeBackupPrivilege, а операція вимагає привілею, подальша перевірка не
проводиться, і доступ надається
 В іншому випадку ця перевірка неактуальна, і перевірка доступу триває
d)Перевірка привілею SeRestorePrivilege: привілей «Відновлювати файли та каталоги»

дозволяють процесу писати файли та об’єкти реєстру для операцій відновлення незалежно
від їх ACE в DACL
 Якщо процес-суб’єкт має привілей SeRestorePrivilege, і операція вимагає привілею, подальша перевірка
не проводиться, і доступ дозволений
 В іншому випадку ця перевірка неактуальна, і перевірка доступу триває

2.Перевірка власника:
a)Якщо DACL містить один або більше ACE з OwnerRights SID, ці записи, разом із усіма
іншими застосовними ACE для користувача, використовуються для визначення прав
власника
b)В іншому випадку перевіряють усі SID в маркері, щоб визначити, чи існує збіг із власником
об’єкта. Якщо так, то права READ_CONTROL та WRITE_DAC надаються якщо були запитані
3.DACL відсутній:
Усі подальші запитувані права доступу надаються
4.DACL присутній, але порожній:
Якщо вимагаються будь-які додаткові права доступу, у доступі відмовляється
5.Ітеративно обробляють кожен ACE у тому порядку, в якому вони
відображаються в DACL, як описано нижче:
a)Якщо атрибути успадкування ACE вказують, що ACE застосовується лише до дочірніх об’єктів
асоційованого об’єкта, ACE пропускається
b)Якщо SID в ACE не відповідає жодному SID у маркері доступу запитувача, ACE
пропускається
c)Якщо знайдено збіг SID, а маска доступу в ACE відповідає доступу в бажаній масці доступу
(див. Наступний слайд)

i. ACE типу “Доступ дозволено”:
 Якщо ACE має тип ACCESS_ALLOWED_OBJECT_ACE, і ACE включає GUID, що
представляє набір властивостей або властивість, пов'язану з об'єктом, тоді доступ
надається набору властивостей або конкретній властивості, представленій GUID (а не до
цілого об'єкта)
 В іншому випадку (ACCESS_ALLOWED_ACE) ACE надає доступ до всього об’єкта
ii. ACE типу “Доступ заборонено”:
 Якщо ACE має тип ACCESS_DENIED_OBJECT_ACE, і ACE включає GUID, що представляє
набір властивостей або властивість, пов'язану з об'єктом, тоді доступ заборонено до набору
властивостей або конкретної властивості, представленої GUID
 В іншому випадку (ACCESS_DENIED_ACE) ACE забороняє доступ до всього об’єкта
 Якщо ACE конкретно відмовляє в запитуваному доступі, тоді весь запит на доступ є
невдалим
6.Перевірка обмежувальних SID:

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

Захист DAC за умовчанням
 КЗЗ забезпечує процес, який гарантує, що DACL застосовується за
умовчанням до всіх нових об'єктів
 Коли створюються нові об'єкти, створюється відповідний DACL
 Методи, що використовуються для побудови DACL для нового
об'єкта служби каталогів та для нових іменованих об'єктів ядра,
дещо відрізняються. Є дві ключові відмінності, які полягають у
наступному:
 Для об’єктів служби каталогів правила створення DACL розмежовують загальні
спадкові ACE та специфічні об’єктно-успадковувані ACE у SD батьківського
об’єкта.
 Загальні спадкові ACE можуть успадковуватися всіма типами дочірніх об’єктів.
 Об'єктно-специфічні спадкові ACE можуть успадковуватися лише за типом дочірнього
об'єкта, до якого вони застосовуються
 Визначення схеми Active Directory для об’єкта може включати SD
 Кожен клас об'єктів, визначений у схемі, має атрибут defaultSecurityDescriptor
 Якщо ні процес створення, ні успадкування від батьківського об'єкта не надають DACL для
нового об'єкта Active Directory, Windows використовує DACL у типовому SD, визначеному
схемою

Правила встановлення DACL в SD для
нових іменованих об’єктів ядра
 DACL об'єкта — це DACL із SD, визначеного процесом, що створює
 Windows об'єднує будь-які успадковувані ACE в DACL, якщо SE_DACL_PROTECTED не встановлено у
прапорах керування SD
 Потім Windows встановлює прапорець керування SE_DACL_PRESENT у SD
 Зверніть увагу, що процес створення може явно надати SD, який не включає DACL. В результаті вийде об'єкт без захистів.
Це відрізняється від не надання жодного SD
 Якщо процес, що створює, не вказує SD
 Windows будує DACL об'єкта з успадковуваних ACE в DACL батьківського об'єкта
 Якщо батьківський об'єкт не має спадкових ACE
 Windows використовує свій підкомпонент диспетчера об’єктів для надання DACL за умовчанням
 Потім Windows встановлює прапори керування SE_DACL_PRESENT та SE_DACL_DEFAULTED у SD
 Якщо менеджер об’єктів не надає DACL за умовчанням
 Windows використовує DACL за умовчанням у маркері доступу суб’єкта
 Потім Windows встановлює прапори керування SE_DACL_PRESENT та SE_DACL_DEFAULTED у SD
 Маркер доступу суб’єкта завжди має DACL за умовчанням, який встановлюється підкомпонентом LSA при
створенні маркера
 Усі маркери створюються з відповідним DACL за умовчанням, який можна застосувати до нових об’єктів за необхідності
 DACL за умовчанням є обмеженим тим, що надає доступ лише SYSTEM SID та SID користувача, який створив об'єкт
SYSTEM SID — це спеціальний SID, що представляє довірені процеси КЗЗ.

Правила встановлення DACL в SD для
нових об’єктів служби каталогів
 DACL об'єкта — це DACL із SD, визначеного процесом, що створює
 Windows об'єднує будь-які успадковувані ACE в DACL, якщо SE_DACL_PROTECTED не встановлено у
прапорах керування SD
 Якщо в процесі створення не вказано SD
 Windows перевіряє DACL батьківського об'єкта на наявність успадкованих об'єктно-залежних ACE, які
застосовуються до типу створюваного об'єкта
 Якщо батьківський об'єкт має успадковувані специфічні об'єкти власного використання для типу об'єкта,
Windows будує DACL об'єкта із спадкоємних елементів управління активами, включаючи загальні та
специфічні об'єкти управління
 Потім Windows встановлює прапор керування SE_DACL_PRESENT у SD
 Якщо батьківський об'єкт не має успадковуваних специфічних ACE для типу
створюваного об'єкта
 Windows використовує DACL за умовчанням зі схеми AD для цього типу об’єкта
 Потім встановлює прапори керування SE_DACL_PRESENT та SE_DACL_DEFAULTED у SD
 Якщо схема AD не визначає типову DACL за типом для об'єкта
 Windows використовує DACL за умовчанням у маркері доступу суб’єкта
 Потім встановлює прапори керування SE_DACL_PRESENT та SE_DACL_DEFAULTED у SD
 Маркер доступу суб’єкта завжди має DACL за умовчанням, який встановлюється підкомпонентом LSA
при створенні маркера

DAC Management
 Нижче наведено чотири методи зміни DACL:

 Власник об’єкта: має неявний доступ до WRITE_DAC
 Явний доступ до зміни DACL: користувач, якому надано
явний доступ WRITE_DAC до DACL, може змінити DACL
 Стати власником, використовуючи явний доступ:
Користувач, якому надано явний доступ WRITE_OWNER
до DACL, може отримати право власності на об’єкт, а потім
використовувати неявний доступ власника WRITE_DAC
 Стати власником, використовуючи привілей:
Користувач із привілеєм SeTakeOwner може отримати
право власності на об’єкт, а потім користуватися неявним
доступом власника до WRITE_DAC

Арбітраж посилань
(Reference Mediation)
 Доступ до об’єктів у системі в цілому заснований на отриманні
дескриптора (handle) об’єкта
 Дескриптори зазвичай отримуються в результаті відкриття або створення об'єкта
 У цих випадках КЗЗ гарантує, що проводиться перевірка доступу суб’єкта до створення
нового дескриптора
 Дескриптори також можуть бути успадковані від батьківського процесу або
безпосередньо скопійовані (з відповідним доступом) з іншого суб'єкта
 У всіх випадках перед створенням дескриптора КЗЗ гарантує, що політика безпеки
дозволяє суб'єкту мати дескриптор (і тим самим доступ) до об'єкта
 Дескриптор завжди має асоційовану маску наданого доступу
 Ця маска вказує, на основі політики безпеки, які права доступу до об'єкта були надані
суб'єкту
 Під час кожної спроби використання дескриптора КЗЗ гарантує, що запитувана дія
дозволена відповідно до наданої маски доступу
 У деяких випадках до об'єктів звертаються безпосередньо за
назвою без проміжного кроку попереднього отримання дескриптора
 У цих випадках КЗЗ безпосередньо перевіряє запит на відповідність політиці
доступу (а не перевіряє наявність наданої маски доступу)

VPN Client 1/2
 Клієнт IPsec VPN у Windows може бути налаштований
локальним адміністратором пристрою
 Адміністратор може налаштувати IPsec VPN-клієнт, щоб весь
IP-трафік проходив через тунель IPsec, за винятком:
 Трафіку IKE, що використовується для встановлення тунелю VPN
 Трафіку IPv4 ARP для визначення локальних адрес мережного рівня
та встановлення локальної адреси
 Трафіку IPv6 NDP для визначення локальних адрес мережного рівня
та встановлення локальної адреси
 IPsec VPN — це наскрізна (end-to-end) технологія
роботи в мережі Інтернет
 Сеанси VPN можуть встановлюватися над протоколами
фізичних мереж, таких як бездротова локальна мережа (Wi-Fi),
або локальних мереж

VPN Client 2/2
 Компоненти, що відповідають за маршрутизацію IP-трафіку через
VPN-клієнт:
 Мережний стек IPv4 / IPv6 у ядрі обробляє вхідний та вихідний мережний
трафік
 Служба модулів ключів (IPsec та IKE та AuthIP Keying Modules), яка
розміщує модулі ключів IKE та AuthIP (Authenticated Internet Protocol)
 Ці модулі ключів використовуються для автентифікації та обміну ключами в IPsec
 Драйвер пристрою служби віддаленого доступу в ядрі (Remote Access
Service device driver), який використовується переважно для з'єднань VPN;
відомий як "RAS IPsec VPN" або "RAS VPN"
 Служба агента політики IPsec (IPsec Policy Agent service), яка забезпечує
реалізацію політик IPsec
 Розробники Універсальних програм для Windows (Universal
Windows App) можуть реалізувати власний клієнт VPN, якщо
корпорація Майкрософт дозволить використовувати можливість
(capability) networkingVpnProvider, що включає встановлення
політики блокування мережного трафіку, як описано вище

Ідентифікація та
 Основи політики ідентифікації та
автентифікації
 Способи ідентифікації та автентифікації
 Результат ідентифікації та автентифікації
 Захист від підбирання паролів
 Перевірка (validation) та генерування
сертифікатів X.509
 Сховище сертифікатів

Основи політики ідентифікації
та автентифікації
 Кожен користувач Windows повинен бути
ідентифікований та автентифікований на основі
визначеної адміністратором політики перед виконанням
будь-яких функцій, опосередкованих КЗЗ
 Інтерактивний користувач звертається до надійного
шляху, щоб захистити свою ідентифікаційну інформацію
 Windows підтримує бази даних облікових записів,
включаючи їх ідентифікаційні дані, інформацію про
автентифікацію, асоціації з групами та асоціації привілеїв
та прав входу
 Функції політики облікового запису Windows включають
можливість визначити мінімальну довжину пароля,
кількість невдалих спроб входу, тривалість блокування
та вік пароля
Способи ідентифікації та
автентифікації 1/2
 Windows 10, Windows 10 S та Windows Server можуть автентифікувати
користувачів на основі
 імені користувача та паролю
 за допомогою PIN-коду Windows Hello, який підтримується модулем TPM
 Windows 10 і Windows Server також можуть використовувати фізичну
або віртуальну смарт-карту, таким чином підтримуючи багаторазову
автентифікацію користувачів
 Усі входи в систему по суті обробляються однаково незалежно від їх
джерела
 інтерактивний вхід,
 мережний інтерфейс,
 внутрішньо ініційований вхід до служби
і починаються з
 імені облікового запису,
 доменного імені (яке може бути NULL; із зазначенням локальної системи),
 та облікових даних, які повинні бути надані КЗЗ

Способи ідентифікації та
 Автентифікація на основі пароля для Windows успішна, коли надані
користувачем дані відповідають збереженому захищеному поданню
пароля
 Автентифікацію за допомогою пароля можна використовувати для
 інтерактивних входів,
 сервісних входів,
 входів в мережу,
 і запуску екрану "змінити пароль"
 Windows Hello та смарт-картки використовують автентифікацію на
основі PIN-коду, щоб розблокувати захищений ресурс, приватний ключ
 збережене представлення PIN-коду захищене ядром безпеки (Secure Kernel)
 PIN-код Windows Hello, фізичні та віртуальні смарт-картки можна
використовувати для інтерактивних входів
 PIN-код Windows Hello використовується для повторної автентифікації
користувача, коли користувач вирішить змінити свій PIN-код

Компоненти, що беруть участь в
ідентифікації та автентифікації

Компоненти, що беруть участь в
ідентифікації та автентифікації
Не так красиво, як у Windows Internals, але більше інформації

Результат ідентифікації та
 Коли автентифікація успішна,
 користувач увійде на свій робочий стіл,
 його екран буде розблоковано,
 або зміняться його фактори автентифікації
залежно від того, чи
 користувач увійшов на комп'ютер,
 дисплей був заблокований,
 або потрібно було змінити PIN-код або
пароль
Захист від підбирання паролів
 Локальна підсистема безпеки — Local Security Authority (LSA) у
Windows підтримує підрахунок послідовних невдалих спроб
входу в систему деякого облікового запису від їх останньої
успішної автентифікації
 Коли кількість послідовних невдалих спроб входу перевищує політику щодо
невдалих спроб входу, яка коливається від 0 (ніколи не блокувати обліковий
запис) до 999, Windows блокує обліковий запис користувача
 Windows зберігає кількість послідовних невдалих входів для користувача,
тому перезавантаження комп'ютера не скидає помилку лічильника входу
 Інтерактивні входи виконуються на захищеному робочому столі,
що не дозволяє запускати інші програми, а отже, перешкоджає
автоматичному вгадуванню пароля
 Крім того, компонент входу в систему Windows примушує
затримку в одну секунду між кожним невдалим входом із
збільшенням затримки після декількох послідовних збоїв входу

Перевірка (validation) та
генерування сертифікатів X.509 1/2
 Кожен компонент Windows, який використовує сертифікати
X.509, відповідає за перевірку сертифікатів
 Однак усі компоненти використовують загальний системний підкомпонент,
який перевіряє сертифікати, як описано в RFC 5280, включаючи всі
застосовні обмеження використання, такі як автентифікація сервера для
мережних сеансів та підписування коду під час інсталяції оновлень продукту
 Кожен компонент, який використовує сертифікати X.509, матиме
сховище публічних сертифікатів і буде вибирати сертифікат на
основі таких критеріїв, як
 назва організації для партнера по спілкуванню,
 будь-які розширені обмеження використання ключа,
 та криптографічні алгоритми, пов’язані із сертифікатом.
 Компонент Windows використовуватиме ті самі типи інформації
разом із шляхом сертифікації та списками довіри сертифікатів
як частину рішення про прийняття сертифіката

Перевірка (validation) та
генерування сертифікатів X.509 2/2
 Якщо перевірка сертифіката не вдається або якщо Windows не
може перевірити статус перевірки сертифіката, Windows не
встановить надійний мережний канал
 Він повідомить користувача та попросить його згоди перед тим, як
встановити сеанс перегляду веб-сторінок HTTPS
 Перевірка сертифікації для оновлень для Windows, мобільних застосунків та
перевірка цілісності є обов’язковою,
 ані адміністратор, ані користувач не мають можливості обходити результати невдалої
перевірки сертифіката
 Коли Windows потрібно сформувати запит на реєстрацію
сертифіката, він буде включати
 визначне ім'я,
 інформація про криптографічні алгоритми, що використовуються для запиту,
 будь-які розширення сертифікації,
 та інформація про клієнта, який запитує сертифікат.

Сховище сертифікатів
 В ОС Windows збережені сертифікати, відомі як надійні кореневі
сертифікати, містяться в сховищах сертифікатів
 Кожен користувач має власне сховище сертифікатів, а також
існує сховище сертифікатів для облікового запису комп’ютера
 доступ до сховища сертифікатів управляється дискреційною політикою
керування доступом в Windows, так що лише уповноважений адміністратор,
тобто користувач або локальний адміністратор, може додавати або
видаляти записи
 Сертифікати, які використовуються програмами, наприклад,
TLS, також розміщуються в сховищах сертифікатів для
 На додаток до стандартних процесів відкликання сертифікатів,
сертифікати програми можна завантажувати за допомогою
адміністративних інструментів, таких як certutil.exe, зміни
довірених кореневих сертифікатів можна внести за допомогою
Списків довіри сертифікатів (Certificate Trust Lists)
Захист функцій КЗЗ
 Відокремлення та ізоляція домену

 Захист бінарних файлів ОС, даних
аудиту та конфігурації
 Захист від недоліків реалізації
 Цілісність платформи Windows та
цілісність коду
 Оновлення Windows та програм

Захист функцій КЗЗ
 Windows захищає від несанкціонованого розкриття та зміни
даних за допомогою набору стандартних протоколів
Інтернету, включаючи IPsec, IKE та ISAKMP
 Windows забезпечує безпеку ізоляції процесів для всіх
процесів через приватні віртуальні адресні простори,
контекст виконання та контекст безпеки
 Структури даних Windows, що визначають адресний простір
процесу, контекст виконання, захист пам’яті та контекст
безпеки, зберігаються у захищеній пам’яті режиму ядра
 Windows містить функції самоперевірки, які забезпечують
цілісність виконуваних образів програми та її
криптографічних функцій
 Нарешті, Windows надає надійний механізм оновлення для
оновлення самих бінарних файлів Windows

Розділення та ізоляція доменів
 КЗЗ забезпечує домен безпеки для власного

захисту та забезпечує ізоляцію процесів
 Домени безпеки, які використовуються всередині
та за допомогою КЗЗ, складаються з наступного:
 Апаратне забезпечення
 Розділи віртуалізації
 Програмне забезпечення режиму ядра
 Захищені (trusted) процеси режиму користувача
 Процес адміністративних засобів (Administrative tools)
режиму користувача
 Контейнери для прикладних програм

КЗЗ: Апаратне забезпечення і
програмне забезпечення режиму ядра
 Апаратне забезпечення КЗЗ управляється програмним

забезпеченням КЗЗ режиму ядра і не може бути модифіковано
ненадійними суб’єктами
 Програмне забезпечення КЗЗ режиму ядра захищене від модифікацій
апаратним станом виконання та захистом як фізичної пам'яті, так і
пам'яті, виділеної розділу
 образ операційної системи працює в межах розділу
 Апаратне забезпечення КЗЗ надає інструкцію програмного
переривання, яка спричиняє зміну стану з режиму користувача на
режим ядра всередині розділу
 Програмне забезпечення КЗЗ режиму ядра відповідає за обробку всіх
переривань і визначає, чи дозволений виклик режиму ядра, що
здійснюється
 Крім того, функції захисту пам’яті КЗЗ гарантують, що спроби отримати доступ до
пам’яті режиму ядра з режиму користувача призводять до апаратного винятку,
гарантуючи, що програмне забезпечення, яке не виконується в режимі ядра, не
може отримати безпосередній доступ до пам’яті режиму ядра

Ізоляція процесів режиму
 КЗЗ забезпечує ізоляцію для всіх процесів режиму користувача,
застосовуючи:
 приватні віртуальні адресні простори (приватні таблиці сторінок для процесу),
 контекст виконання (регістри, програмні лічильники),
 контекст безпеки (таблиця дескрипторів та маркер доступу)
Структури даних, що визначають адресний простір процесу, контекст
виконання та контекст безпеки, зберігаються у захищеній пам’яті режиму ядра
 Як і процеси КЗЗ, процеси користувача також мають приватний адресний
простір та контекст процесу
 тому захищені один від одного
 Інструменти адміністратора режиму користувача виконуються з контекстом
безпеки процесу, який працює від імені уповноваженого адміністратора
 Процеси адміністратора, як і інші процеси в режимі користувача, захищені ізоляцією процесів
 Крім того, КЗЗ має додаткову можливість захисту сторінок пам'яті за
допомогою запобігання виконанню даних (Data Execution Prevention — DEP)
 Він позначає сторінки пам'яті в процесі як невиконувані, якщо місце розташування явно не
містить виконуваного коду
 Коли процесору пропонують виконати інструкції зі сторінки, позначеної як дані, процесор
видасть виняткову ситуацію (переривання) для обробки ОС
Контейнери прикладних
програм
 Контейнери прикладних програм ("App Containers") надають
середовище виконання для універсальних програм Windows (Universal
Windows Applications)
 це запобігає доступу універсальних програм Windows до даних, створених іншими
універсальними програмами Windows, за винятком опосередкованих (brokered) служб
операційної системи, таких як діалог вибору файлів

Криптографічний захист
 КЗЗ реалізує криптографічні механізми в межах окремого процесу режиму
користувача, де до його послуг можна отримати доступ як з компонентів ядра,
так і з режиму користувача
 Це зроблено з метою ізолювати ці функції від решти КЗЗ, щоб обмежити вплив можливих
помилок, одночасно захищаючи ці функції від потенційних спроб втручання
 Крім того, КЗЗ включає функцію перевірки цілісності коду (Code Integrity
Verification feature), також відому як підписування коду в режимі ядра (Kernel-
mode code signing — KMCS), за допомогою якої драйвери пристроїв
завантажуватимуться лише в тому випадку, якщо вони підписані цифровим
підписом або Microsoft, або надійного кореневого центру сертифікації,
визнаного Microsoft
 KMCS використовує технологію криптографії з відкритим ключем для перевірки цифрового
підпису кожного драйвера під час його завантаження
 Коли драйвер намагається завантажитись, КЗЗ розшифровує хеш, включений у драйвер, за
допомогою відкритого ключа, збереженого в сертифікаті
 Потім він перевіряє, чи хеш відповідає тому, який він обчислює на основі коду драйвера,
використовуючи криптографічні бібліотеки, сертифіковані FIPS, у КЗЗ
 Справжність сертифіката також перевіряється таким же чином, але за допомогою відкритого
ключа центру сертифікації, який повинен бути налаштований і якому Windows має довіряти

Захист бінарних файлів ОС,
даних аудиту та конфігурації
 За умовчанням операційна система Windows встановлюється в каталозі
\Windows\ першого завантажувального розділу сховища даних комп'ютера
 Логічна назва цього каталогу — %systemRoot%
 Ядро, драйвери пристрою (файли .sys), системні виконувані файли
(файли .exe) та динамічно завантажувані бібліотеки (файли .dll) зберігаються в
каталозі %systemRoot%\system32 і підкаталогах system32
 Стандартні користувачі мають дозволи на читання та виконання цих файлів, однак дозволи на
зміну та запис обмежуються обліковими записами локального адміністратора та системних
служб
 Кореневий каталог журналів аудиту — %systemRoot%\system32\winevt
 Локальний адміністратор, служба журналу подій та системний обліковий запис мають повний
контроль над файлами аудиту; стандартні користувачі не мають доступу до журналів
 Основним сховищем даних конфігурації для Windows є реєстр
 Існують окремі вулики реєстру для самого комп’ютера та кожного користувача, уповноваженого
користуватися комп’ютером
 Вулики реєстру для даних конфігурації операційної системи розташовані за адресою
%systemRoot%\system32\config; вулик реєстру для користувача знаходиться у домашньому
каталозі профілю користувача
 Файли реєстру використовують ту саму схему захисту, що і файли журналу подій

Захист від недоліків
реалізації 1/2
 Ядро Windows, програми режиму користувача та всі програми магазину
Windows реалізують рандомізацію адресного простору (Address Space
Layout Randomization — ASLR) для завантаження виконуваного коду за
непередбачуваними базовими адресами
 Базова адреса генерується за допомогою генератора псевдовипадкових чисел, який
заповнюється високоякісними джерелами ентропії, якщо вони є, що забезпечує
щонайменше 8 випадкових бітів
 Виконавча система Windows також надає можливість захисту від
переповнення буфера в стеку (stack buffer overrun protection capability),
яка припиняє процес після того, як Windows виявить потенційне
перевищення буфера у стеку потоку, перевіряючи значення “канарійок”
у прологу та епілогу функцій, а також впорядковуючи стек
 Усі бінарні файли Windows та програми магазину Windows реалізують
захист від переповнення буфера стека шляхом:
 їх компіляції з опцією /GS, та
 перевірки того, що всі програми для магазину Windows скомпільовані із захистом від
переповнення буфера, перш ніж завантажити цю програму у Магазин Windows

Захист від недоліків
реалізації 2/2
 Щоб увімкнути ці засоби захисту за допомогою
середовища розробки Microsoft Visual Studio, програми
компілюють з
 опцією /DYNAMICBASE для ASLR,
 і додатково з /HIGHENTROPYVA для 64-розрядних ASLR,
 або /NXCOMPAT:NO, щоб відмовитися від DEP, заснованого на
програмному забезпеченні,
 та /GS (увімкнено за умовчанням) для захисту від переповнення
буфера в стеку
 Програми Магазину Windows компілюються за
допомогою параметра /APPCONTAINER, який створює
виконуваний файл для запуску в контейнері програм
Windows для роботи із захистом у режимі користувача,
описаним вище
Цілісність платформи
Windows та цілісність коду
 Операційна система Windows перевіряє цілісність
програмного коду Windows, використовуючи комбінацію
можливостей безпечного завантаження (Secure Boot) та
цілісності коду (Code Integrity) у Windows
 На комп’ютерах з модулем надійної платформи (Trusted
Platform Module — TPM) перед завантаженням Windows
комп’ютер перевірить цілісність компонентів раннього
завантаження, що включає
 завантажувач (Boot Loader),
 завантажувач ОС (OS Loader),
 та бінарні файли OS Resume
 Ця можливість відома як Secure Boot
 Послідовність перевірок Secure Boot описана в
“Довідковому матеріалі до лекцій 7-8”, слайди 89-95
Підписування коду режиму
ядра
 Підписування коду режиму ядра (Kernel-mode code signing — KMCS)
запобігає завантаженню драйверів пристроїв режиму ядра, таких як
мережний драйвер TCIP/IP (tcpip.sys), якщо вони не опубліковані та
не підписані розробниками, які перевірені одним із декількох
довірених центрів сертифікації (ЦС)
 KMCS, використовуючи технології криптографії з відкритим ключем, вимагає,
щоб код режиму ядра містив цифровий підпис, створений одним із надійних
центрів сертифікації
 Коли драйвер пристрою ядра намагається завантажитись, Windows
розшифровує хеш, включений у драйвер, за допомогою відкритого ключа, що
зберігається в сертифікаті, а потім перевіряє, чи хеш відповідає тому, що
обчислений за кодом
 Справжність сертифіката перевіряється так само, але за допомогою відкритого
ключа центру сертифікації, якому довіряє Windows
 Кореневий відкритий ключ ланцюжка сертифікатів, який перевіряє підпис,
повинен відповідати одному з кореневих відкритих ключів Microsoft, що вказує на
те, що Microsoft є видавцем файлів образів Windows
 Кореневі відкриті ключі Microsoft жорстко кодуються у завантажувачі Windows

Захист файлів Windows
 Захист файлів Windows (Windows File Protection)
підтримує набір захищених файлів, які зберігаються у
кеші разом із криптографічними хешами кожного з цих
файлів
 Після ініціалізації системи Захист файлів Windows
завантажується і сканує захищені файли, щоб
переконатися, що вони мають дійсні криптографічні хеші
 Захист файлів Windows також реєструється для
отримання сповіщень у разі зміни будь-якого із
захищених файлів, щоб він міг повторно перевірити
криптографічну контрольну суму в будь-який момент,
коли система працює
 Якщо будь-яка з перевірок криптографічного хешу не
вдалася, відповідний файл буде відновлено з кешу
Оновлення Windows і
програм 1/2
 Оновлення Windows постачаються у вигляді файлів окремого пакета
оновлень Майкрософт — Microsoft Update Standalone Package files — (файли
.msu), підписані Майкрософт двома цифровими підписами:
 підпис RSA SHA1 для застарілих програм
 підпис RSA SHA-256 для сучасних програм
 Цифровий підпис підписується корпорацією Майкрософт із шляхом
сертифікації через сертифікат підписання коду Майкрософт (Microsoft Code
Signing certificate) і, зрештою, кореневий центр сертифікації Майкрософт
(Microsoft Root Certification Authority)
 Ці сертифікати перевіряються надійним інсталятором Windows (Windows Trusted Installer)
перед установкою оновлення
 Операційна система Windows перевірить, чи є сертифікат дійсним і не був
відкликаний, за допомогою стандартної PKI CRL
 Коли надійний інсталятор визначить, що пакет дійсний, він оновить Windows;
 в іншому випадку встановлення припиниться, і в журналі подій буде повідомлення про
помилку
 Зауважте, що інсталятор Windows не встановить оновлення, якщо файли в
упаковці мають менші номери версій, ніж встановлені файли

Оновлення Windows і
програм 2/2
 Цілісність сертифіката підписання коду Майкрософт (Microsoft Code
Signing certificate) на комп’ютері захищається кореневим ключем
сховища в TPM, а також перевіреною цілісністю бінарних файлів
Windows завдяки Secure Boot та Code Integrity
 Оновлення операційної системи Windows, програм Windows та
десктопних програм Майкрософт доставляються через
 Windows Update (для Windows) і
 Microsoft Update (для десктопних програм Майкрософт),
які увімкнено за замовчуванням
або користувач може перейти на http://catalog.update.microsoft.com, щоб за
власним бажанням шукати та отримувати оновлення безпеки
 Після цього користувач може перевірити правильність підпису,
переглянувши дані про цифровий підпис файлу з Windows Explorer, або
за допомогою командлета PowerShell Get-AuthenticodeSignature
 Якщо командлет Get-AuthenticodeSignature PowerShell або Windows Explorer не
вдалося перевірити підпис, статус буде позначено як недійсний
 Ця перевірка використовує ту саму функціональність, що описана вище

Програми магазину Windows
 Програми Універсальної платформи Windows (Universal
Windows Platform — UWP) можна завантажити з магазину
Майкрософт, а їх інсталяційні пакети перевірити за допомогою
цифрового підпису корпорації Майкрософт із використанням
підпису коду
 Ці програми містяться або в пакетах AppX (AppX packages), або в
наборах пакетів AppX, відомих як колекція AppX (AppX bundle)
 Пакет AppX використовує стандарт Open Packaging Conventions (OPC)
 Кожен пакет містить файл каталогу, у якому перераховані інші файли
пакета, цифровий підпис пакета, карта блоків, що представляє файли
програми, які можуть бути встановлені на цільовому комп’ютері, та самі
файли програми
 Служба розгортання AppX (AppX Deployment Service)
перевірить цифровий підпис RSA SHA-256 для карти блоків та
інших метаданих AppX на початку завантаження пакету (або
колекції) AppX

Розповсюдження оновлень
 Існує кілька каналів розповсюдження оновлень
для ОС Windows та програм Windows:
 Windows Update: Windows Update — це веб-сервіс для
доставки оновлень Windows безпосередньо споживачам
 Служби оновлення Windows Server (Windows Server
Update Services — WSUS): WSUS — це роль сервера у
Windows Server, яку ІТ-адміністратори можуть
використовувати для розповсюдження оновлень програм
серед користувачів на своєму підприємстві
 Магазин Windows (Windows Store): Магазин Windows — це
веб-сервіс для доставки оновлень до програм
універсальної платформи Windows (Universal Windows
Platform), які спочатку були встановлені з Магазину
Windows
Блокування сеансу
(Session Locking)
 Можливість заблокувати сеанс

одразу або через певний проміжок
часу
 Блокування комп’ютера після
встановленого періоду бездіяльності

Інтерактивне блокування
сеансу
 Windows надає користувачеві можливість заблокувати
свій інтерактивний сеанс входу за власним бажанням або
після визначеного користувачем тайм-ауту бездіяльності
 Коли користувач має сеанс на робочому столі, він може
викликати функцію блокування сеансу, використовуючи
ту ж комбінацію клавіш, яка використовується для
виклику довіреного шляху — Secure Attention Sequence
(Ctrl+Alt+Del)
 Ця комбінація клавіш фіксується КЗЗ і не може бути перехоплена або
змінена жодним процесом користувача
 Результатом активування цієї комбінації клавіш є меню функцій, одна
з яких — блокування робочої станції
 Користувач також може заблокувати свій робочий стіл, перейшовши
на початковий екран, вибравши ім’я для входу, а потім вибравши
опцію «Блокувати» (Lock)

Блокування за інтервалом
бездіяльності
 Windows надає адміністратору можливість вказати інтервал бездіяльності,
після якого сеанс буде заблоковано
 Ця політика застосовуватиметься або до локальної машини, або до комп’ютерів у домені з
використанням локальної політики або групової політики, відповідно
 Якщо і адміністратор, і звичайний користувач вказують тайм-аут бездіяльності, Windows
заблокує сеанс, коли закінчиться найкоротший період часу
 Windows постійно відстежує активність миші, клавіатури, сенсорного
дисплея та датчика орієнтації, щоб визначити, чи вони неактивні протягом
заданого періоду часу
 Після цього Windows заблокує робочу станцію та запустить заставку, якщо
користувач не переглядає відео, наприклад фільм
 Якщо робочу станцію не було заблоковано вручну, КЗЗ заблокує дисплей і запустить
програму заставки, якщо та коли період бездіяльності перевищиться
 Він також відображатиме будь-які сповіщення від програм, які зареєстровані для публікації
значка програми або значка з відповідним текстом сповіщення на заблокованому екрані
 Користувач має можливість не відображати жодних сповіщень або вибрати одну програму
Windows Store для відображення тексту сповіщення, а також вибрати інші програми для
відображення їх значка

Розблокування сеансу
 Після того, як комп'ютер був заблокований, щоб розблокувати сеанс,
користувач натискає клавішу або проводить пальцем по дисплею
 Користувач повинен надати комбінацію клавіш Ctrl+Alt+Del, якщо вимкнена політика
“Інтерактивний вхід: Не вимагати CTRL+ALT+DEL”
 Результатом будь-якої дії буде діалогове вікно автентифікації
 Потім користувач повинен повторно ввести свої дані автентифікації, які були
кешовані локальною системою від початкового входу, після чого дисплей
користувача буде відновлено, а сеанс відновиться
 Альтернативно, уповноважений адміністратор може ввести свій логін адміністратора та
пароль у діалоговому вікні автентифікації
 Якщо КЗЗ може успішно автентифікувати адміністратора, користувач вийде з системи, а не
повернеться до свого сеансу, залишивши робочу станцію готовою до автентифікації нового
 В рамках встановлення інтерактивного сеансу входу в систему Windows
можна налаштувати на відображення банера для входу, визначеного
адміністратором, який користувач повинен прийняти перед встановленням
сеансу
 Як описано в інструкціях для адміністраторів, авторизований адміністратор
може вказати, до яких мереж Wi-Fi (SSID) може бути підключений комп'ютер

Захищений шлях для зв'язку
(Trusted Path for Communications)
 Windows використовує протоколи

HTTPS, TLS, DTLS та EAP-TLS для
забезпечення захищеного шляху для
зв'язку

Захищені (Trusted) мережні
канали
 Windows надає захищені мережні канали для зв'язку з підтримуючою ІТ-
інфраструктурою або програмами
 Використовуючи протокол TLS (HTTPS) для реєстрації сертифікатів, перевірки CRL,
автентифікації до мережних ресурсів, таких як веб (HTTPS) та каталожні (LDAP-S) сервери, та
управління через постачальників служби конфігурації у Windows, які є локальним інтерфейсом
для обробки запитів управління мобільними пристроями (Mobile Device Management — MDM)
 Використовуючи DTLS для сервісів на основі дейтаграм та перегляду веб-сторінок за
допомогою версії DTLS, яка вказана клієнтською програмою
 Щоб встановити надійний канал, ці комунікації захищені, як описано вище
 Віддалений доступ можна здійснити за допомогою таких методів:
 Підключення до іншого комп’ютера за допомогою віддаленого робочого столу (Remote Desktop
Connection)
 Віддалений PowerShell
 Обидва методи використовують протокол TLS (1.2) для встановлення
віддаленого з'єднання
 Windows впроваджує IEEE 802.11-2012, IEEE 802.1X та EAP-TLS для
забезпечення автентифікованих сеансів бездротових мереж за запитом

Управління безпекою
(Security Management)
 Windows має кілька функцій для

управління політиками безпеки
 Управління політикою здійснюється
за допомогою поєднання керування
доступом, членства в групах
адміністраторів, та привілеїв

Управління безпекою 1/2
Адміні- Кори-
Функція управління
стратор стувач
Активувати/деактивувати блокування екрану √ √
Задати тайм-аут неактивності для блокування екрану √ √
Задати ємність локального сховища даних аудиту √
Задати мінімальну довжину пароля √
Задати мінімальну кількість спеціальних символів в паролі
Задати мінімальну кількість цифрових символів в паролі
Задати мінімальну кількість символів верхнього регістру в паролі
Задати мінімальну кількість символів нижнього регістру в паролі
Задати тайм-аут неактивності віддаленого з’єднання √
Дозволити/заборонити логін без автентифікації
Конфігурувати політику блокування для неуспішних спроб
автентифікації (тайм-аути між спробами, обмеження кількості √
спроб за певний період часу)
Конфігурувати мережний екран на хості √
Задати ім’я/адресу сервера каталогів для зв’язку з ним √
Управління безпекою 2/2
Адміні- Кори-
Функція управління
стратор стувач
Задати ім’я/адресу віддаленого сервера керування, з якого
√
отримувати налаштування управління
Задати ім’я/адресу сервера аудиту/реєстрації, на який
надсилати записи аудиту/реєстрації
Конфігурувати правила аудиту √
Задати ім’я/адресу мережного сервера часу √
Активувати/деактивувати автоматичні оновлення програмного √
Конфігурувати інтерфейс Wi-Fi √
Активувати/деактивувати інтерфейс Bluetooth √
Конфігурувати інтерфейси USB √
Активувати/деактивувати інтерфейс локальної мережі √

Безпека
систем
Лекція 10-12. Засоби захисту Linux

Вступ
 Як і для Windows, розглянемо функції безпеки Linux за документами Security
Target (ST), що готували для оцінювання окремих дистрибутивів Linux за
стандартом Common Critera
 Оцінювання (з наступною сертифікацією) проводили для різних дистрибутивів,
серед яких
 Red Hat Enterprise Linux (v.8.2)
 SUSE Linux Enterprise Server (v.15)
 Oracle Linux (v.7.6)
 Canonical Ubuntu Server (18.04.4)
 Багато підрозділів опису функцій безпеки зазначених продуктів в різних ST
повторюються дослівно, що свідчить про те, що за основу береться один
документ, розроблений для Linux взагалі, а не для окремих дистрибутивів
 Однак є суттєві відмінності, пов’язані як з відмінностями функцій
дистрибутивів, так і з комплектацією відповідних TOE
 Слайди з 3 по 55 (за виключенням 40 і 41) цієї презентації зроблені на основі ST
на відповідність профілю OSPP (EAL 4+) — Red Hat Enterprise Linux v.7 та SUSE
Enterprise Server v.12
 ST на відповідність GPOS PP (EAL 1) не містять детального опису політики безпеки

Загальний опис системи 1/2
 Об’єктом оцінювання є дистрибутив Linux версії, що вказана в ST, що
виконується на обладнанні вказаному в ST (далі будемо ОО називати
просто “Linux”)
 Кілька систем Linux можуть бути пов’язані фізично захищеною
локальною мережею (LAN)
 Кожний хост-комп’ютер надає такий самий набір локальних сервісів, таких як
управління файлами, пам’яттю, і процесами
 Кожний хост-комп’ютер також надає користувачам на інших комп’ютерах мережні
сервіси, такі як віддалені захищені командні оболонки (remote secure shells) і
передавання файлів
 Користувач заходить на певний хост-комп’ютер і запитує сервіси як з того комп’ютера,
так і з інших комп’ютерів у локальній мережі
 Програми користувача ініціюють мережні запити відсилаючи іншому
комп’ютеру повідомлення протоколів TCP (Transmission Control
Protocol) або UDP (User Datagram Protocol)
 Деякі мережні протоколи, як наприклад SSH (Secure Shell), можуть запустити
користувачеві процес командної оболонки на іншому комп’ютері, в той час як інші
обробляються довіреними серверними процесами - демонами
Див. “Довідковий матеріал”, слайди 3-5
Загальний опис системи 2/2
 Linux забезпечує механізм ідентифікації й автентифікації
користувачів, вимагаючи від кожного користувача зайти в
систему з правильним паролем на локальному комп’ютері і
на кожному віддаленому комп’ютері, де користувач може
вводити команди в командну оболонку (наприклад,
віддалені сесії SSH)
 Кожен комп’ютер забезпечує набір таких політик:
 Політика дискреційного керування доступом (DAC), заснована на бітах
доступу у стилі UNIX
 Опціонально — списки керування доступом (ACL)
 Політика мандатного керування доступом (MAC) із використанням
розширень SELinux (Security Enhanced Linux) для іменованих об’єктів,
що перебувають під його контролем.
 У системах гілки Debian (зокрема, Ubuntu) замість SELinux застосовують
AppArmor з подібною функціональністю

Структура хост-комп’ютера

Сервіси, що надає кожен
хост-комп’ютер
 Локальні сервіси користувачам, які в даний час увійшли в систему за
допомогою
 локальної консолі комп'ютера
 віртуальних консолей
 термінальних пристроїв, що підключені через фізично захищені послідовні лінії
 Локальні сервіси попереднім користувачам через відкладені завдання
 прикладом є демон cron
 Локальні сервіси користувачам, які отримали доступ до локального
хосту через мережу за допомогою протоколу, такого як SSH, який
запускає оболонку користувача на локальному хості
 Мережні сервіси для потенційно кількох користувачів або на
локальному хості, або на віддалених
 Надаються середовища віртуалізації, що дозволяють ненадійному
програмному забезпеченню виконуватись у користувацькому режимі
процесора
Див. “Довідковий матеріал”, слайд 7

Локальні та мережні сервіси,
що надає Linux 1/2
 Користувач може ввійти в систему на локальному хост-
комп’ютері та робити запити файлової системи або
запити управління пам’яттю для служб за допомогою
системних викликів до ядра локального хосту
 Усі подібні локальні послуги виконуються виключно на
локальному комп'ютері-хості та опосередковуються виключно
надійним програмним забезпеченням на цьому хості
 Мережні служби, такі як SSH або FTP, включають
архітектуру клієнт-сервер і протокол рівня мережного
сервісу
 Клієнт-серверна модель розділяє програмне забезпечення, яке
надає послугу, на клієнтську частину, яка робить запит, і серверну
частину, яка виконує запит, як правило, на іншому комп'ютері
 Сервісний протокол — це інтерфейс між клієнтом і сервером
Локальні та мережні сервіси,
що надає Linux 2/2
 Користувач A може увійти на хост 1, а
потім використати SSH для входу на
хост 2
 На хост 2 користувач А ввійшов з віддаленого
хосту
 На хості 1, коли користувач A використовує SSH
для входу на хост 2, клієнт SSH на хості 1
робить запити протоколу до процесу сервера
SSH на хості 2
 Серверний процес опосередковує запит від
імені Користувача А, виконує запитувану
послугу, якщо це можливо, і повертає
результати клієнтському процесу, що робив
запит
 Також зверніть увагу, що мережний клієнт і сервер можуть бути в одній хост-
системі
 Наприклад, коли користувач C використовує SSH для входу на хост 2, клієнтський процес
користувача відкриває з'єднання SSH із процесом сервера SSH на хості 2
 Хоча цей процес відбувається на локальному хост-комп'ютері, він відрізняється від локальних
служб, оскільки передбачає мережні протоколи

Політика безпеки
Модель загроз
Модель політики безпеки
Користувачі
Суб’єкти та Об’єкти
Керування доступом
Ідентифікація КЗЗ
Інтерфейси КЗЗ
Обмеження

Модель загроз 1/3
 T.ACCESS.TSFDATA
 Порушник (A threat agent) може читати або модифікувати дані КЗЗ без належної
авторизації коли дані зберігаються або передаються
 T.ACCESS.USERDATA
 Порушник може отримати доступ до даних користувача, які зберігаються, обробляються
або передаються системою, без належної авторизації у відповідності до політики безпеки
 T.ACCESS.TSFFUNC
 Порушник може використовувати або модифікувати функціональність КЗЗ без належних
привілеїв з метою надати собі або іншим несанкціонований доступ до даних КЗЗ або
даних користувача
 T.ACCESS.COMM
 Порушник може здійснити доступ до комунікаційного каналу, що встановлює довірені
відносини між цією системою та іншою віддаленою довіреною IT системою, або удавати з
себе іншу віддалену довірену IT систему
 T.RESTRICT.NETTRAFFIC
 Порушник може отримати доступ до інформації або передавати інформацію іншим
абонентам через мережні комунікаційні канали без належної авторизації для такої спроби
зв’язку відповідно до політики керування потоками інформації

 T.IA.MASQUERADE
 Порушник може удавати з себе авторизовану сутність, включаючи саму систему або її
частину, для здійснення несанкціонованого доступу до даних користувача, даних КЗЗ, або
ресурсів системи
 T.IA.USER
 Порушник може отримати доступ до даних користувача, даних КЗЗ, або ресурсів системи
(за виключенням загальнодоступних об’єктів) без ідентифікації та автентифікації
 T.ACCESS.COMPENV
 Порушник може використати або модифікувати середовище виконання інших екземплярів
ОС в умовах віртуалізації без належної авторизації
 T.INFOFLOW.COMP
 Порушник може отримати доступ до інформації без авторизації з боку політики керування
потоком інформації
 T.COMM.COMP
 Порушник може здійснити доступ до даних, що передаються між екземплярами ОС в
умовах віртуалізації, або між екземпляром ОС і зовнішньою сутністю, з метою читати або
модифікувати дані

 T.ROLE.SNOOP
 Порушник може отримати права, надані ролі, що були делеговані іншому
користувачу
 T.ROLE.DELEGATE
 Порушник може делегувати права, надані ролі, якою він не володіє, або
які він не має права делегувати
 T.UNOBSERVED_AUDIT
 Порушник може порушувати політики безпеки, але залишатись
непоміченим, через те, що наявні або занадто багато даних аудиту, або
занадто багато засобів аудиту в корпоративній мережі, через що
адміністратор переглядає та адмініструє ці засоби недостатньо часто
 T.ACCESS.CP.USERDATA
 Порушник може отримати доступ до даних користувача, що
зберігаються, без належної авторизації від власника, ябо під час роботи
системи, або коли КЗЗ неактивний

Модель політики безпеки 1/2
 Політика безпеки для Linux визначається функціональними

вимогами безпеки
 Далі наведено перелік суб’єктів та об’єктів, які беруть участь у
політиці
 Суб’єкти:
 Процеси, що діють від імені людини-користувача або технічної сутності
 Процеси, що діють від імені людини-користувача або технічної сутності, що
забезпечує середовище віртуальної машини
 Іменовані об'єкти:
 Об'єкти файлової системи в дозволених (підтримуваних) файлових системах
 Перелік підтримуваних файлових систем див. у Довідкових матеріалах, слайди 10-11
 Об'єкти міжпроцесової взаємодії (IPC):
 Семафори, Спільна пам’ять, Черги повідомлень, Іменовані канали, Спеціальні файли
сокетів домену UNIX

Модель політики безпеки 2/2
 Дані КЗЗ:
 Виконуваний код КЗЗ
 Метадані суб’єктів — усі дані, що використовуються для суб’єктів, крім
даних, які не інтерпретуються КЗЗ і не реалізують частини КЗЗ (ці дані
називаються даними користувача)
 Метадані іменованих об’єктів — усі дані, що використовуються для
відповідних об’єктів, крім даних, які не інтерпретуються КЗЗ і не
реалізують частини КЗЗ (ці дані називаються даними користувача)
 Облікові записи користувачів, включаючи атрибути безпеки
 Записи аудиту
 Дані користувача:
 Виконуваний код, що не належить КЗЗ, і використовується для
керування поведінкою суб'єктів
 Дані, які не інтерпретуються КЗЗ і зберігаються або передаються з
використанням іменованих об'єктів

Користувачі
 Користувач — це уповноважена особа, що має обліковий запис
 Користувачі можуть використовувати систему в один із таких способів:
 Взаємодіючи безпосередньо з системою через сеанс на консолі комп’ютера (у цьому
випадку користувач може використовувати дисплей, що надається як фізична
консоль), або
 Взаємодіючи безпосередньо з системою через сеанс на послідовному терміналі, або
 Через відкладене виконання завдань за допомогою механізму cron, або
 Використовуючи реалізовані сервіси, з програмами, які отримують доступ до цих
сервісів локально або віддалено, або
 Використовуючи середовища віртуальних машин, отримуючи доступ до цих
середовищ або локально, або віддалено.
 Користувач повинен увійти в локальну систему, щоб отримати доступ
до захищених ресурсів системи
 Після автентифікації користувача він може отримати доступ до файлів
або виконувати програми на локальному комп'ютері, або робити
мережні запити на інші комп'ютери в системі

Суб’єкти та Об’єкти
 Єдиними суб’єктами в системі є процеси
 Процес складається з адресного простору з контекстом виконання
 Процес обмежений комп’ютером; відсутній механізм диспетчеризації процесу
для віддаленого запуску (через TCP/IP) на іншому хості
 Кожен процес має ідентифікатор процесу (PID), який є унікальним на своєму
локальному комп'ютері-хості, але PID не є унікальними для всіх систем
 Як приклад, кожен хост у системі має процес init з PID 1
 Об'єкти — це пасивні сховища даних
 У Linux визначено три типи об'єктів:
 іменовані об'єкти, що є ресурсами, такі як файли та об'єкти IPC, якими можуть керувати
багато користувачів, використовуючи угоду про іменування, визначену в інтерфейсі КЗЗ;
 об'єкти зберігання, що підтримують доступ як для читання, так і для запису різними
недовіреними суб'єктами; і
 публічні об'єкти — об'єкти, які можуть публічно читати недовірені суб'єкти, але записувати
їх можуть лише довірені суб'єкти.
 Відповідно до цих визначень, усі іменовані об'єкти також класифікуються як
об'єкти зберігання, але не всі об'єкти зберігання є іменованими об'єктами

Керування доступом
 Linux застосовує політику дискреційного керування доступом для всіх
іменованих об'єктів, що знаходяться під її контролем, і політику повторного
використання об'єкта для всіх об'єктів зберігання, що знаходяться під її
контролем
 Застосовувана політика дискреційного керування різниться залежно від різних класів об’єктів, у
всіх випадках вона базується на ідентифікації користувача та членстві в групі, пов’язаній з
ідентифікацією користувача
 На додаток до політики дискреційного керування, Linux також застосовує
політику мандатного керування доступом для всіх іменованих об'єктів, що
знаходяться під її контролем
 Спочатку застосовується політика дискреційного керування, тоді як мандатне керування
доступом застосовується лише в тому випадку, якщо дискреційне керування дозволяє операцію
 Політика мандатного керування доступом не є авторитетною; тобто заборона згідно політики
дискреційного керування не може бути скасована політикою мандатного керування
 Застосовувана політика мандатного керування доступом відрізняється залежно від класів
об’єктів, у всіх випадках вона базується на домені користувача та типі об’єкта
 Для забезпечення дотримання правил керування доступом усі користувачі
повинні бути ідентифіковані та їх ідентифікаційні дані повинні бути
автентифіковані

 Linux використовує як апаратні, так і програмні механізми захисту
 Апаратні механізми, що використовуються Linux для забезпечення захищеного домену для
власного виконання, включають процесор з підтримкою режимів виконання, захист сегментів
пам'яті та захист сторінок пам'яті
 Програмне забезпечення Linux покладається на ці апаратні механізми для реалізації ізоляції КЗЗ,
неможливості обійти функції КЗЗ, та поділ адресного простору
 Користувач може ввійти в систему на консолі, на інших безпосередньо
підключених терміналах або через мережне підключення
 Автентифікація базується на введеному користувачем паролі та даних
автентифікації, що зберігаються у захищеному файлі, або через інші типи
облікових даних, наприклад, криптографічні ключі при використанні SSH
 Користувачі повинні увійти на хост, перш ніж вони зможуть отримати доступ до будь-яких
іменованих об'єктів на цьому хості
 Деякі служби, такі як SSH, для отримання запиту оболонки на іншому хості або ftp для передачі
файлів між хостами в розподіленій системі вимагають від користувача повторного введення
даних автентифікації на віддалений хост
 Linux дозволяє користувачеві змінювати паролі (за умови дотримання діючих правил щодо
паролів), змінювати ідентичність, подавати пакетні завдання на відкладене виконання та
виходити з системи
 Архітектура системи забезпечує механізми самозахисту КЗЗ та ізоляції процесів

Ідентифікація КЗЗ
(З яких причин пакети або окремі файли відносять до
КЗЗ)
 Він містить код, такий як ядро, модуль ядра та драйвери пристроїв, що працює у
привілейованому режимі процесора
 Він забезпечує політику безпеки системи
 Він дозволяє SUID або SGID до привілейованого користувача (наприклад, root) або групи
 Йому надані можливості (capabilities) файлової системи, що передбачають підвищення
привілеїв під час виконання
 Він надає одну або кілька можливостей подолати обмеження, пов’язані з безпекою, які
застосовуються системою для користувача, що його викликає
 Він був запущений як демон, що виконується з правами root або з системним UID/GID
 Це програмне забезпечення, яке повинно функціонувати належним чином для підтримки
механізмів безпеки системи
 Він потрібен для системного адміністрування
 Він складається з даних КЗЗ або файлів конфігурації
 Він складається з бібліотек, пов'язаних з програмами КЗЗ
 Він був запущений як програма з іншими привілеями, ніж той, що його викликав
 Найпомітнішими прикладами є init, modprobe та v86d, використовувані драйвером uvesafb
 Він надає користувачеві, який його викликає, одну або кілька можливостей подолання
багаторівневої безпеки (MLS)

Програмні компоненти КЗЗ Linux
 Ядро Linux, що включає

 Базове ядро
 Окремо-завантажувані модулі ядра і драйвери пристроїв
 Ядро реалізує інтерфейс системних викликів Linux
 Програмне забезпечення КЗЗ, що не входить до ядра, включає
програми, що працюють з адміністративними привілеями, такі як
демони sshd та systemd
 КЗЗ також включає конфігураційні файли, які визначають
 авторизованих користувачів,
 групи користувачів,
 послуги, що надаються системою,
 та інші дані конфігурації
 Не входять до складу КЗЗ
 оболонки, що використовуються адміністраторами,
 та стандартні утиліти, що викликаються адміністраторами

Інтерфейси КЗЗ 1/2
 Інтерфейси КЗЗ включають будь-який інтерфейс, який можливий між недовіреним

програмним забезпеченням та КЗЗ
 Інтерфейси КЗЗ включають:
 локальні інтерфейси, що надаються кожним хост-комп'ютером
 мережні інтерфейси клієнт-сервер, що забезпечуються парами хост-комп'ютерів
 Локальні інтерфейси, що надаються хост-комп’ютером, включають такі надані ядром
інтерфейси:
 Системні виклики довірених та недовірених програм до привілейованого програмного забезпечення
режиму ядра
 Наступні інтерфейси ядра слід розглядати як незалежні інтерфейси під час аналізу безпеки (незважаючи
на те, що вони є семантичним розширенням системних викликів open, ioctl або пов’язаних з сокетами):
 Файли пристроїв
 Віртуальні файлові системи
 Мережні сокети, що використовують протокол AF_NETLINK або PF_KEY або AF_ALG
 Будь-який аналізатор/парсер мережних протоколів, реалізований ядром:
 Ethernet
 ARP
 Сімейства протоколів TCP/IP
 IPSec
 Помічена комунікація з використанням протоколів IPSec

Інтерфейси КЗЗ 2/2
 Наступні інтерфейси реалізовані довіреними процесами в просторі

користувача:
 Мережні інтерфейси, що надаються парами хост-комп’ютерів:
 SSHv2 (RFC 4252)
 IKEv1 та IKEv2: (IKE — RFC 2409 та RFC 5996, доступні групи Діффі-Хеллмана - RFC 2409, RFC
3526, RFC 5114)
 TLS v1.1 та TLS v1.2: (RFC 4346 та RFC 5246)
 Масиви символів argv та envp, які є аргументами системного виклику execve
 Ці два масиви можуть бути оцінені виконуваною прикладною програмою
 Ряд змінних середовища, які можуть бути надані envp, реалізуються бібліотеками, які зазвичай
завантажуються більшістю, якщо не всіма програмами (наприклад, C-бібліотекою)
 Файли, які є частиною бази даних КЗЗ, що визначають параметри конфігурації, що
використовуються функціями захисту
 Інтерфейси взаємодії між процесами, експортовані прикладною програмою
 Тип міжпроцесового інтерфейсу зв'язку включає підтримку DBus
 DBus — це протокол, який працює на основі механізмів міжпроцесового зв'язку, що надаються ядром
 Виклики гіпервізора та емуляція та моделювання інструкцій, реалізовані ядром Linux для
підтримки середовища віртуалізації KVM
 Це включає моделювання та емуляцію апаратного забезпечення, що постачається з ядром Linux

Інтерфейси, що не входять
до КЗЗ 1/2
 Інтерфейси між процесами, що не належать до КЗЗ, та базовим обладнанням
 Як правило, користувацькі процеси не взаємодіють безпосередньо з апаратним
забезпеченням; винятки становлять
 процесор,
 USB,
 з'єднання через паралельний порт,
 з'єднання через послідовний порт,
 та графічне обладнання
 Непривілейовані інструкції процесора не реалізують жодних функцій безпеки, і процесор

обмежує ці інструкції межами, визначеними процесором
 Крім того, решта перелічених апаратних компонентів не є частиною Linux, оскільки вони є
периферійними пристроями
 Інтерфейси між різними частинами КЗЗ, які невидимі для звичайних
користувачів (наприклад, між підпрограмами всередині ядра)
 Інтерфейс є внутрішнім для довіреної частини Linux і не може бути викликаний поза цими
частинами
 Прошивка, хоча і є частиною Linux, не розглядається як така, що забезпечує
інтерфейси КЗЗ
 тому що вони не допускають прямих непривілейованих операцій до них

Інтерфейси, що не входять
до КЗЗ 2/2
 Винятки процесорів, що передають прошивці, не вважаються інтерфейсами TSF
 Вони не стосуються безпеки, оскільки надають доступ до прошивки, яка не реалізує жодних
функцій безпеки
 У випадку, якщо ІТ-середовище забезпечує середовище віртуалізації, таке як
 Хост-системи KVM,
 z/VM або PR/SM на системах s390x,
 POWER LPAR на системах IBM POWER,
 архітектурні інтерфейси гіпервізора середовища віртуалізації (як-то виклики
гіпервізора) не вважаються інтерфейсом TSF
 оскільки він не доступний непривілейованим процесам у стані проблеми та не забезпечує жодних
функцій безпеки
 Зверніть увагу, що про функціонал гіпервізора, реалізований ядром Linux та його
інтерфейсами, тут мова не йде
 Стан SMM процесорів на базі Intel не стосується безпеки, оскільки програмне
забезпечення, що виконується в цьому стані, не реалізує жодних функцій
безпеки
 Більше того, непривілейований код не може отримати доступ або змінити програмне
забезпечення, що виконується в цьому стані процесора

Що не дозволено
(політикою безпеки)
 Існує різниця між програмним забезпеченням режиму користувача, що не є
частиною КЗЗ, яке можна завантажувати та запускати в системі, та
програмним забезпеченням, яке повинно бути виключене із системи
 Наступні методи використовуються для того, щоб гарантувати, що виключене
програмне забезпечення не можна буде використовувати для порушення
політики безпеки системи:
 Додавання модулів ядра не дозволяється
 Програмне забезпечення для інсталяції може змінити конфігурацію (наприклад, біти режиму),
так що програма не зможе порушити політику безпеки
 Додавання програм із увімкненим бітом SUID, якими володіє UID root або системний UID,
заборонено
 Додавання програм із увімкненим бітом SGID, якими володіє GID root або системний GID,
заборонено
 Додавання ввімкнених бітів можливостей (capabilities) програм не дозволяється
 Додавання демонів, що виконуються з UID/GID root або системним, не дозволяється
 Зміни набору правил фреймворків, які дозволяють появу процесів з різними привілеями,
такими як udev або PolicyKit, не дозволяються
 Додавання програм із увімкненими можливостями (capabilities) подолання обмежень MLS не
дозволяється

Архітектура програмного
Апаратні привілеї
Рівні привілеїв x86, PowerPC, SystemZ
Віртуалізація
Програмні привілеї
DAC, SELinux LSM MAC, Capabilities, AppArmor
Програми з програмними привілеями
Структура програмного забезпечення

КЗЗ
Ядро, Апаратна частина, Прошивка

Апаратні привілеї —
Рівень привілеїв x86
 Концепція привілею реалізується шляхом присвоєння
значення від 0 до 3 ключовим об'єктам, які розпізнає процесор
 Це значення називається рівнем привілеїв.
 Наступні об'єкти, які розпізнає процесор, містять рівні
привілеїв:
 Дескриптори містять поле, яке називається рівнем привілеїв
дескриптора (descriptor privilege level — DPL)
 Селектори містять поле, яке називається рівнем привілеїв запитувача
(requestor’s privilege level — RPL)
 RPL призначений для представлення рівня привілеїв процедури, яка ініціює
селектор
 Внутрішній регістр процесора записує поточний рівень привілеїв (current
privilege level — CPL)
 Зазвичай CPL дорівнює DPL сегмента, який зараз виконує процесор
 CPL змінюється, коли керування передають сегментам з різними DPL

Рівні привілеїв, трактовані як
рівні захисту
 Центр призначений для
сегментів, що містять найбільш
критичне програмне
забезпечення, як правило, ядро
 Зовнішні шари призначені для
сегментів менш критичного
програмного забезпечення
 Ядро Linux, як і більшість інших
UNIX-подібних ядер,
використовує лише два з цих
режимів виконання
 Найвищий, з рівнем привілеїв
процесора 0, відповідає режиму ядра
 Найнижчий, із рівнем привілеїв
процесора 3, відповідає режиму

Реалізація апаратного
привілею
 Коли процесор перебуває в режимі ядра, програма має апаратний привілей, оскільки вона
може:
 отримувати доступ та змінювати будь-які адресовані ресурси, такі як пам’ять, таблиці сторінок, адресний простір
вводу-виводу та регістри управління пам’яттю, що неможливо в режимі користувача
 виконувати певні привілейовані інструкції, недоступні в режимі користувача
Таким чином, будь-який код, який працює в режимі ядра, виконується з апаратними
привілеями
 Програмне забезпечення, що працює з апаратними привілеями, включає:
 Базове ядро Linux
 Це становить велику частину програмного забезпечення, яке виконує введення-виведення файлів, управління пам’яттю та
управління процесами
 Окремо завантажені модулі ядра, такі як багато модулів драйверів пристроїв
 Модуль ядра - це об’єктний файл, код якого може бути пов’язаний із ядром та від’єднаний від нього під час виконання
 Код модуля ядра виконується в ядрі, як і будь-яка інша статично пов'язана функція ядра
 Усе інше програмне забезпечення в системі зазвичай працює в режимі користувача, без
апаратних привілеїв, включаючи процеси користувача, такі як оболонки, мережне клієнтське
програмне забезпечення та редактори
 Процеси в режимі користувача виконуються з апаратними привілеями, коли вони ініціюють
системний виклик
 Виконання системних викликів або виняткових ситуацій процесора (таких як помилки сторінок), спричинених
програмами користувацького простору, перемикає режим із користувацького в режим ядра і продовжує роботу
за вказаною адресою в ядрі, де знаходиться код обробника системного виклику або обробника виняткової
ситуації

Рівні привілеїв
PowerPC та SystemZ
 Рівень привілеїв PowerPC
 Ця архітектура процесора забезпечує три режими виконання,
ідентифіковані бітом PR (біт 49) та бітом HV (біт 3) Регістру стану
машини (Machine State Register — MSR) процесора
 Значення 0 для бітів PR та HV вказують на режим гіпервізора
 Значення біта HV 1 і значення біта PR 0 означають режим супервізора або
ядра
 Значення біта HV 1 і значення біта PR 1 вказують на режим користувача
 Рівень привілеїв SystemZ
 Системи SystemZ забезпечують два режими виконання, визначені
бітом стану проблеми (або задачі) — Problem State bit (біт 15)
слова стану програми (Program Status Word — PSW) процесора
 Значення 0 вказує на режим супервізора або ядра
 Значення 1 вказує на режим стану проблеми або користувача

Розгляд питання віртуалізації
 Коли Linux використовується як хост-система для віртуалізації KVM, на додаток до двох
згаданих вище використовується третій стан привілеїв: режим гіпервізора
 Режим гіпервізора використовує додаткову апаратну підтримку, що надається процесором
 У режимі гіпервізора доступні регістри процесора, які недоступні через інші два стани
 Використовуючи ці регістри, реалізовано ще один рівень трансляції адрес пам'яті
 Крім того, використовується віртуалізація адресного простору введення/виведення, якщо така є
 Ядро Linux використовує цей режим, коли активована віртуалізація KVM

 У цьому випадку все ядро Linux працює в режимі гіпервізора
 Звичайні процеси все ще працюють в режимі користувача
 Щодо процесів користувацького режиму, ядро Linux поводиться так само, як якщо б ядро працювало в
режимі супервізора (ядра)
 Крім того, процеси можуть також використовувати режим супервізора за допомогою KVM для реалізації
гостьової операційної системи
 З точки зору ядра Linux, гостьова система — це не що інше, як звичайний процес, де частини цього процесу
виконуються шляхом використання функціональності віртуалізації процесора
 Для реалізації стану гіпервізора використовуються такі механізми процесора:
 На базі Intel: VT-x
 На базі AMD: SVM
 SystemZ: інструкція SIE
 Ядро Linux не забезпечує підтримку віртуалізації для інших процесорів, окрім названих

Програмні привілеї
 Привілеї програмного забезпечення в Linux передбачають можливість
подолати механізми керування доступом ядра
 Linux реалізує такі моделі керування доступом:
 Дискреційне керування доступом (Discretionary Access Control — DAC), що
застосовується до об’єктів зберігання
 Перевірки безпеки на основі можливостей (Capability-based security checks) для
обмеження виконання системних викликів або функціональних підмножин системних викликів
для програм, що мають відповідні можливості
 Перевірка доступу модуля безпеки Linux (Linux Security Module — LSM) — мандатні
політики керування доступом (Mandatory Access Control — MAC), реалізовані за
допомогою LSM
 При доступі до іменованих об'єктів спочатку застосовується дискреційне
керування доступом, а перевірка доступу LSM застосовується тоді і тільки
тоді, коли DAC надає доступ
 Ядро реалізує програмні привілеї для політики DAC
 Крім того, модуль LSM SELinux може реалізовувати програмні привілеї з додатково
завантаженою багаторівневою політикою (Multi-level Security — MLS)
 Окрім програмних привілеїв керування доступом, можливості (Capabilities) —
це ще один програмний привілей, який може надаватися програмам

доступом 1/2
 Модель DAC дозволяє власнику об’єкта вирішувати, хто і
яким чином може отримати доступ до цього об’єкта
 Як і будь-яка інша модель керування доступом, реалізація DAC може
бути описана такими специфікаціями:
 які суб'єкти та об'єкти перебувають під керуванням моделі
 атрибути безпеки, які використовує модель
 правила керування доступом та правила передачі атрибутів
 механізм подолання (програмні привілеї) для обходу цих правил
 Суб'єкти та об'єкти
 Суб’єктами в Linux є регулярні процеси та потоки ядра
 Вони обидва представлені структурою task_struct
 Потоки ядра виконуються лише в режимі ядра і не обмежуються політикою DAC
 Усі об'єкти зберігання, такі як звичайні файли, символьні та блокові
файли пристроїв, каталоги, сокети, об'єкти IPC та кільця ключів ядра
знаходяться під контролем політики DAC

доступом 2/2
 Атрибути
 Атрибутами суб’єкта, що використовуються для забезпечення політики DAC, є UID
процесу, GID, додаткові групи та можливості процесу
 Ці атрибути зберігаються в структурі task_struct процесу і на них впливають системні виклики
 Атрибутами об’єкта, що використовуються для забезпечення політики DAC, є власник,
група-власник, біти дозволів та списки керування доступом (Access Control Lists —
ACL) POSIX.1e для об’єктів файлової системи
 Ці атрибути зберігаються в ядрі, а для відповідних дискових файлових систем — в inode (індексному
дескрипторі) на диску
 Правила керування доступом
 Правила керування доступом DAC визначають, як певний процес із відповідними
атрибутами DAC може отримати доступ до об'єкта з набором атрибутів захисту DAC
 Крім того, правила керування доступом DAC також визначають, як атрибути захисту
суб'єкта та об'єкта переходять на нові значення та за яких умов
 Програмні привілеї
 Привілеї програмного забезпечення для політики DAC засновані на можливостях
CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, які можна призначити процесу
 Процес, що має ці можливості, отримує програмний привілей щодо DAC, оскільки він може
обійти політику керування доступом системи

Мандатне керування доступом
SELinux LSM
 При Мандатному керуванні доступом (Mandatory Access Control — MAC),
реалізованому за допомогою модуля безпеки Linux (Linux Security
Module — LSM) SELinux (Security Enhanced Linux), саме політика безпеки
системи (на відміну від власника в DAC) контролює, кому повинен бути
наданий доступ до якої інформації
 Політика MAC, що надається SELinux, базується на двох типах політик:
 Застосування типу (Type Enforcement — TE), яке використовується для реалізації
керування доступом на основі ролей
 Багаторівнева безпека (Multi-Level Security — MLS) із ієрархічною політикою
маркування у стилі Белла-ЛаПадула
 Суб'єкти та об'єкти
 Суб'єкти в MAC — це звичайні процеси та потоки ядра (такі ж, як у DAC)
 Потоки ядра виконуються лише в режимі ядра і не обмежуються політикою MAC
 Усі іменовані об'єкти, такі як звичайні файли, символьні та блокові файли пристроїв,
каталоги, сокети та об'єкти IPC, перебувають під контролем політики MAC
 На додаток до іменованих об'єктів, політика MAC може також керувати доступом до
певних структур даних ядра, таких як дескриптори файлів, повідомлення IPC та
файлові системи, щоб дозволити детальний вираз системної політики безпеки

Атрибути SELinux
 Атрибути безпеки
суб’єкта та об'єкта,
також звані
контекстом безпеки
SELinux, мають
однаковий формат
 У зручній для читання та зовнішній формі контекстом безпеки є рядок ASCII
 Ядро з міркувань продуктивності перетворює рядок у 32-розрядне ціле число під час
виконання
 Атрибути SELinux зберігаються:
 у структурі процесу task_struct для суб’єктів,
 у структурі даних inode в ядрі і на диску для об’єктів файлової системи,
 у структурі даних kern_ipc_perm для об'єктів System V IPC,
 у структурі даних sock для сокетів,
 у структурі xfrm_state для сокетів netlink,
 у структурі даних key для ключів.

Контексти безпеки SELinux
 Контекст безпеки складається з чотирьох розділених
двокрапкою компонентів
 User (Користувач): ім'я користувача SELinux
 Role (Роль): роль SELinux, що відповідає суб'єкту чи об'єкту
 Для суб'єктів роль використовується для здійснення керування доступом на основі
ролей, дозволяючи ролі контролювати доступ до доменів
 Для об'єктів компонент ролі не використовується, і це завжди object_r
 Type (Тип): домен суб’єкта або тип об’єкта
 Домени та типи — це еквівалентні класи для процесів та ресурсів відповідно
 Рішення щодо доступу в ядрі приймаються на основі домену суб’єкта та типу
об’єкта
 MLS label range (Діапазон міток MLS): дві повні мітки MLS.
 Кожна мітка MLS складається з двох компонентів, рівня ієрархічної класифікації
(або рівня чутливості) та неієрархічного набору категорій
 SELinux записує недійсні контексти як
system_u:object_r:unlabeled_t:s0

Мітки MLS
 Кожна мітка MLS складається з двох компонентів
 ієрархічний рівень класифікації (або рівень чутливості)
 неієрархічний набір категорій
 Діапазон міток MLS містить дві повні мітки MLS
 Вони розташовані з нижньою міткою ліворуч і верхньою міткою, що домінує над нижньою
міткою, праворуч. Дві мітки розділені тире
 Для суб’єктів
 Нижня мітка діапазону відповідає ефективній мітці MLS суб'єкта
 Верхня мітка відповідає “допуску” (clearance) суб’єкта (максимальному рівню дозволу для
цього суб’єкта)
 Допуск суб'єкта відображує допуск користувача, від імені якого суб'єкт діє
 Для таких об'єктів, як звичайні файли, політика безпеки наказує, що нижня
мітка та верхня мітка рівні
 Такі об'єкти, як каталоги, пристрої та сокети, можуть мати верхню мітку, яка не
дорівнює нижній мітці
 Ці об'єкти є багаторівневими, і їхній діапазон міток MLS вимагає, щоб рівень чутливості будь-
якої інформації, яка проходить через них, домінував над нижньою міткою, а над ним
домінувала верхня мітка

Правила керування доступом
 Реалізація керування доступом MAC базується на застосуванні типу
(TE)
 TE забезпечує детальне керування доступом для суб’єктів та об'єктів
 Правила TE та MLS визначаються політикою SELinux
 Правила TE визначаються як перевірки керування доступом, тоді як політика MLS
виражається як обмеження поверх TE
 Отже, загальна перевірка керування доступом відбувається в три
логічні етапи, наступним чином:
 Перевірка DAC за допомогою атрибутів DAC
 Перевірка TE з використанням доменів і типів контексту безпеки SELinux
 Перевірка політики MLS з використанням діапазону MLS контексту безпеки SELinux
 Кожна перевірка є неавторитетною, тобто дозволи лише
зменшуються на кожному етапі
 заборона DAC не може бути скасована TE,
 і заборона TE не може бути скасована MLS.

Програмні привілеї для MAC
 Програмні привілеї для політики MAC реалізуються з доменом процесу та
правилами політики безпеки, пов’язаними з цим доменом
 Наприклад, процесам, що виконуються в домені init_t, дозволено читати об'єкти, мітка чутливості
яких домінує над міткою чутливості процесу
 Це подолання загальної політики досягається атрибутами домену
 Правило політики описує доступ домену до типу з перевизначенням
(подоланням) загальних правил, пов’язаним з атрибутом домену
 Наприклад, наступне правило політики може бути використано, щоб дозволити процесу
перевизначити обмеження моделі багаторівневої безпеки "не читати зверху" при спробі прочитати
звичайний файл:
mlsconstrain {file} {read} ((l1 dom l2) or (t1 == mlsfileread));
 Вищезазначений оператор встановлює політику безпеки, згідно з якою мітка l1 (що належить
суб’єкту) повинна домінувати над міткою l2 (що належить об’єкту) для успішного виконання
операції зчитування, або для цього домен процесу повинен мати атрибут mlsfileread
 Політика безпеки системи для різних типів суб’єктів та об'єктів описується з
функціональним описом цих суб'єктів та об'єктів
 На додаток до атрибутів процесу, які можуть надавати права перевизначення, ядру Linux відома
така можливість (capability): CAP_MAC_OVERRIDE
 Якщо процес володіє цією можливістю, процес може обійти все застосування політики SELinux

Можливості — Capabilities 1/2
 Ядро Linux має фреймворк для забезпечення привілеїв

програмного забезпечення для багатьох різних функцій, що
надаються ядром Linux за допомогою можливостей (Capabilities)
 Ці можливості дозволяють розділити привілей програмного забезпечення
ядра, пов'язаний з нульовим ідентифікатором користувача (UID = 0), на
набір дискретних привілеїв на основі операцій, які намагаються здійснити
 Можливості інтегруються з ідентифікаторами користувачів (UID)
наступним чином:
 Якщо виконується SUID програма з ідентифікатором власника root, для
цього процесу увімкнені усі можливості
 Якщо використовується сімейство системних викликів set*uid для зміни UID
процесу, що викликає, на ідентифікатор, що не дорівнює 0, усі можливості
цього процесу видаляються
 Процеси, породжені користувачем root, спочатку мають усі можливості
 Процеси, породжені користувачами, що не є root, спочатку не мають
увімкнених можливостей

Можливості — Capabilities 2/2
 Програмний привілей
 Ядро обмежує використання багатьох системних викликів або
функціональних областей, що викликаються системними викликами, до
процесів, що мають певні можливості
 Якщо процес виклику не має необхідних можливостей, виконання зачепленої
області коду не дозволяється, а процесу, що викликає, повертається
помилка EPERM
 Наприклад, якщо процес намагається створити спеціальний файл пристрою,
викликаючи системний виклик mknod, ядро перевіряє, чи здатний процес створювати
спеціальні файли пристрою, перевіряючи, чи має процес можливість CAP_MKNOD
 За відсутності спеціальних модулів ядра, які визначають і використовують
можливості, перевірка можливостей повертається назад до надання
привілеїв програмного забезпечення ядра на основі UID процесу
 Можливості засновані на проекті POSIX.1e плюс ряд додаткових
можливостей
 Повний перелік усіх можливостей, включаючи їх значення, повністю
описаний у файлі вихідного коду ядра Linux include/linux/capability.h

Особливості AppArmor
(Ubuntu)
 В той час, коли дистрибутиви Linux гілки Red Hat (RHEL, SUSE) для
реалізації MAC використовують SELinux, Ubuntu та інші дистрибутиви гілки
Debian використовують AppArmor
 AppArmor — це також LSM
 AppArmor абсолютно несумісний з SELinux
 для успішного функціонування AppArmor повинен бути єдиним завантаженим модулем LSM
 спроба встановити SELinux на систему з наявним в ядрі модулем AppArmor як правило призводить до
краху системи
 AppArmor також несумісний з Capabilities, бо фактично цей модуль підтримує власну
систему Capabilities
 На відміну від SELinux, AppArmor не надає політику багаторівневої безпеки,
але надає повноцінний аналог застосуванню доменів/типів
 Політика AppArmor формується у вигляді профілів для кожного
виконуваного файлу
 Профіль — це текстовий файл, який можна створювати вручну або з допомогою
інструментів AppArmor
 У профілі, зокрема, прописуються можливості (capabilities) цієї програми, а також права
доступу (дозволи) до усіх доменів (каталогів, окремих файлів), до яких ця програма може
мати доступ

Застосування AppArmor для
реалізації MAC в Ubuntu
 Ubuntu підтримує мандатне керування доступом на основі
такої концепції:
 Для розділення віртуальних машин та їхніх ресурсів під час виконання,
застосовуються правила AppArmor, визначені політиками AppArmor
 Фреймворк управління віртуальними машинами (virtual machine
management framework) призначає кожній віртуальній машині
унікальну мітку (label)
 Згідно цієї політики, кожному ресурсу, призначеному цій віртуальній
машині, призначають ту саму мітку
 Політика AppArmor на основі цих міток гарантує, що віртуальна
машина може отримати доступ лише до своїх власних ресурсів
 Ресурси інших віртуальних машин, операційної системи хосту, і ресурси інших
користувачів є недосяжними
 Фреймворк управління віртуальними машинами
застосовує AppArmor прозоро для адміністратора

Програми з програмними
привілеями
 Прикладами програм, що працюють із програмним привілеєм, є:
 Програми, які запускаються системою, такі як демони cron і init
 Програми, які запускаються довіреними адміністраторами для виконання системного адміністрування
 Програми, які працюють із правами привілейованого користувача шляхом виконання програмних
файлів SUID/SGID можливостями файлової системи
 Програми, що виконуються довіреними супердемонами. Присутні такі супердемони з можливістю
породження прикладних програм з різними привілеями від імені користувачів, що їх викликають:
 systemd: Системний фреймворк завантаження та управління системою, що надається systemd, дозволяє
користувачам спілкуватися з ним через канали DBus. Оскільки systemd працює від імені користувача root, це
дозволяє ненадійним користувачам виконувати дії, які в іншому випадку для таких користувачів були б неможливі
 PolKit: Фреймворк авторизації простору користувача реалізований демоном PolKit. Цей демон пропонує свої
послуги через DBus, що надає можливість породжувати програми, як налаштовано його політикою, через допоміжну
SUID програму
 Все програмне забезпечення (ПЗ), яке працює з апаратними або програмними
привілеями, є частиною КЗЗ
 У системі, яку адмініструють належним чином:
 Непривілейоване ПЗ підпорядковується політиці безпеки системи і не має жодних засобів обходу цих
механізмів — це називається недовіреним (або ненадійним) ПЗ
 Довірені процеси, які не реалізують жодної функції безпеки, повинні бути захищені від
несанкціонованого втручання за допомогою функцій безпеки Linux, щоби гарантувати, що вони не
виконують жодної функції, яка порушує політику безпеки Linux

Ядро як компонент КЗЗ
 Ядро є центральною частиною операційної системи. Воно:
 Взаємодіє безпосередньо з апаратним забезпеченням,
 Здійснює спільний доступ до ресурсів, надання загальних послуг програмам та
 Забороняє програмам отримувати безпосередній доступ до апаратно-залежних функцій
 Ядро Linux — це повністю витісняльне (preemptible) ядро
 У невитісняльних ядрах код ядра працює до завершення
 Тобто планувальник не здатний перепланувати завдання, поки воно знаходиться в ядрі
 Більше того, код ядра планується кооперативно (погоджувально), а не витісняльно, і він
виконується до завершення та повернення до простору користувача, або явно блокує
 У витісняльних ядрах можна витіснити завдання в будь-який момент, якщо ядро
перебуває у стані, в якому безпечно перепланувати його
 Сервіси, що надаються ядром, включають наступне:
 Керування виконанням процесів, дозволяючи їх створення, завершення або
призупинення, а також зв’язок
 Виділення основної пам'яті для виконуваного процесу
 Обслуговування віртуальних машин протягом життєвого циклу
 Обслуговування файлової системи

Сервіси, що надаються ядром 1/2
 Керування виконанням процесів, дозволяючи їх створення, завершення або

призупинення, а також зв’язок. До них належать:
 Справедливе планування процесів для виконання на ЦП
 Надання процесам центрального процесору за принципом розділення часу
 Виконання процесором процесу
 Тимчасова зупинка ядра, коли завершується його квант часу
 Планування ядром виконання іншого процесу
 Пізніше перепланування ядром призупиненого процесу
 Управління метаданими, пов'язаними з безпекою процесу, такими як UID, GID, мітки
SELinux, можливості
 Виділення основної пам'яті для виконуваного процесу. До них належать:
 Дозвіл ядра процесам обмінюватися частинами їх адресного простору за певних умов, але
захист приватного адресного простору процесу від сторонніх втручань
 Якщо в системі залишається недостатньо вільної пам'яті, ядро звільняє пам'ять, тимчасово
записуючи процес у додаткову пам'ять або на пристрій обміну
 Координація з апаратним забезпеченням машини для встановлення перетворення
віртуальних адрес у фізичні адреси, яке відображає адреси, створені компілятором, до їх
фізичних адрес

Сервіси, що надаються ядром 2/2
 Обслуговування віртуальних машин протягом їх життєвого циклу, що

включає:
 Застосування обмежень ресурсів, налаштованих програмою емуляції, що застосовується
до віртуальної машини
 Запуск коду віртуальної машини
 Обробка виходу з віртуальних машин або виконанням інструкції, або перенесенням
виконання інструкції до програми емуляції простору користувача
 Обслуговування файлової системи. До них належать:
 Виділення вторинної пам'яті для ефективного зберігання та отримання даних користувача
 Виділення вторинного сховища для користувацьких файлів
 Відновлення невикористаного сховища
 Зрозуміле структурування файлової системи
 Захист файлів користувачів від незаконного доступу
 Дозвіл контрольованого доступу процесів до периферійних пристроїв, таких як термінали,
стрічкові накопичувачі, дисководи та мережні пристрої
 Посередництво у доступі між суб'єктами та об'єктами, дозволяючи контрольований доступ
на основі політики DAC та будь-якої політики, що забезпечується завантаженим LSM

Логічні компоненти ядра 1/3
 Файлова підсистема та підсистема вводу-виводу:
 Ця підсистема реалізує функції, пов'язані з об'єктами файлової системи
 Реалізовані функції включають функції, які дозволяють процесу створювати,
підтримувати, взаємодіяти та видаляти об'єкти файлової системи
 Ці об’єкти включають звичайні файли, каталоги, символічні посилання, жорсткі
посилання, спеціальні файли для пристроїв, іменовані канали та сокети
 Підсистема керування процесами:
 Ця підсистема реалізує функції, пов’язані з управлінням процесами та потоками
 Реалізовані функції включають функції, що дозволяють створювати, планувати,
виконувати та видаляти процеси та потоки
 Підсистема керування пам'яттю:
 Ця підсистема реалізує функції, пов'язані з управлінням ресурсами пам'яті системи
 Реалізовані функції включають функції, що створюють віртуальну пам’ять та керують
нею, включаючи управління таблицями сторінок та алгоритмами підкачки
 Мережна підсистема:
 Ця підсистема реалізує сокети доменів UNIX та Інтернету, а також алгоритми
планування мережних пакетів

 Підсистема IPC:
 Ця підсистема реалізує функції, пов'язані з механізмами IPC
 Реалізовані функції включають функції, що полегшують контрольований обмін
інформацією між процесами, дозволяючи їм обмінюватися даними та
синхронізувати їх виконання, щоб взаємодіяти із загальним ресурсом
 Підсистема фреймворку ядра:
 Ця підсистема реалізує інфраструктуру для підтримки ядром різних механізмів
 Ця підсистема включає такі функції, серед інших:
 Підтримка завантажуваних модулів: реалізовані функції включають функції завантаження,
ініціалізації та вивантаження модулів ядра
 Обробка винятків, таких як перемикання контексту, завантаження системних викликів тощо
 Аудит:
 Підсистема аудиту реалізує функції, пов’язані із записом критично важливих подій
в системі
 Реалізовані функції включають функції, які фіксують кожен системний виклик для
запису критично важливих подій та функції, що реалізують збір та запис даних
аудиту

 Розширення безпеки Linux:
 Розширення безпеки Linux (Linux Security Extensions) реалізують різні аспекти, пов'язані з
безпекою, які надаються всьому ядру, включаючи фреймворк модуля безпеки Linux (Linux
Security Module — LSM)
 Фреймворк LSM забезпечує агностичну основу для модулів для реалізації різних політик безпеки,
включаючи SELinux
 SELinux є важливою логічною підсистемою
 Ця підсистема реалізує функції мандатного керування доступом для опосередкування доступу між усіма
суб’єктами та об’єктами
 Підсистема драйверів пристроїв:
 Ця підсистема реалізує підтримку різних апаратних та програмних пристроїв через загальний,
незалежний від пристроїв інтерфейс
 Підсистема KVM:
 Ця підсистема реалізує підтримку життєвого циклу віртуальної машини
 Вона включає виконання інструкцій для інструкцій, що вимагають лише невеликих перевірок
 Для виконання будь-яких інших інструкцій KVM викликає компонент простору користувача QEMU
 Крипто API:
 Ця підсистема забезпечує внутрішню криптографічну бібліотеку ядра для всіх компонентів ядра
 Вона надає криптографічні примітиви

Виконувані компоненти ядра 1/2
 Базове ядро
 Базове ядро включає код, який виконується для надання сервісу,
наприклад, обслуговування системного виклику користувача або
обслуговування події переривання або винятку
 Більшість компільованого коду ядра підпадає під цю категорію
 Потоки ядра
 Для виконання певних рутинних завдань, таких як очищення кеш-
пам’яті диска або відновлення пам’яті шляхом заміни
невикористаних фреймів, ядро створює внутрішні процеси або
потоки
 Потоки ядра плануються так само, як і звичайні процеси, але вони
не мають контексту в режимі користувача
 Потоки ядра знаходяться в просторі ядра і працюють лише в
режимі ядра

Виконувані компоненти ядра 2/2
 Модулі ядра та драйвери пристроїв

 Модулі ядра — це фрагменти коду, які можна завантажувати в
ядро та вивантажувати та з нього за запитом
 Вони розширюють функціональність ядра без необхідності
перезавантаження системи
 Після завантаження об'єктний код модуля ядра може отримати доступ
до іншого коду ядра та даних таким же чином, як і статично пов'язаний
об'єктний код ядра
 Драйвер пристрою — це особливий тип модуля ядра, який
дозволяє ядру отримувати доступ до апаратного забезпечення,
підключеного до системи
 Такими пристроями можуть бути жорсткі диски, монітори або мережні
інтерфейси
 Драйвер взаємодіє з рештою частиною ядра за допомогою певного
інтерфейсу, що дозволяє ядру мати рівномірну роботу з усіма
пристроями, незалежно від їх базових реалізацій

Неядерне ПЗ і бази даних КЗЗ
 Неядерне ПЗ КЗЗ складається з довірених програм, які використовуються для
реалізації функцій безпеки
Зверніть увагу, що спільні бібліотеки, включаючи модулі PAM, в деяких випадках
використовуються довіреними програмами. Однак немає жодного випадку, коли спільна
бібліотека сама по собі вважається довіреною сутністю
 Довірені команди можна згрупувати наступним чином
 Ініціалізація системи
 Ідентифікація та автентифікація
 Мережні програми
 Пакетна обробка
 Управління системою
 Аудит рівня користувача
 Криптографічна підтримка
 Підтримка віртуальної машини
 Обробка авторизації в користувальницькому просторі
 Бази даних КЗЗ — це файли конфігурації довірених програм
 Жодна з цих баз даних не може бути змінена користувачем, крім адміністративного користувача
 Керування доступом здійснюється компонентом файлової системи ядра Linux

Апаратне забезпечення та
прошивка
 Апаратне забезпечення
 Апаратне забезпечення складається з фізичних ресурсів, таких як
 ЦП,
 основна пам'ять,
 регістри,
 кеші,
 та пристрої, які ефективно складають комп’ютерну систему
 Вбудоване програмне забезпечення (прошивка, firmware)
 Прошивка складається з програмного забезпечення, що знаходиться в
апаратному забезпеченні, яке запускається, коли система переходить
у режим скидання живлення
 На додаток до ініціалізації апаратного забезпечення та запуску
операційної системи, на платформах, що підтримують логічне
розділення (partitioning), прошивка забезпечує також підтримку
логічного розділення

Функціональність безпеки Linux
Аудит (Auditing)
Криптографічна підтримка (Cryptographic support)
Пакетний фільтр (Packet filter)
Ідентифікація та автентифікація
(Identification and Authentication)
Дискреційне керування доступом
(Discretionary Access Control)
Авторитетне керування доступом
(Authoritative Access Control)
Середовища віртуальних машин
(Virtual machine environments)
Управління безпекою (Security Management)

Аудит
 Легка система аудиту (Lightweight Audit Framework — LAF) розроблена для
того, щоб бути системою аудиту для Linux, яка відповідає вимогам Загальних
критеріїв
 LAF може перехоплювати всі системні виклики, а також отримувати записи журналу аудиту з
привілейованих програм простору користувача
 Підсистема дозволяє конфігурувати події, які фактично будуть підлягати аудиту, з набору всіх
подій, які можна піддати аудиту
 Ці події конфігуруються у певному конфігураційному файлі, а потім ядро отримує
повідомлення про створення власної внутрішньої структури для подій, які підлягають аудиту
 auditd — це компонент простору користувача системи аудиту Linux
 Він відповідає за запис записів аудиту на диск.
 Перегляд журналів здійснюється за допомогою утиліт ausearch або aureport
 Налаштування системи аудиту або правил завантаження здійснюється за допомогою утиліти
auditctl
 Під час запуску auditctl читає правила в /etc/audit/audit.rules і завантажує їх в ядро
 Крім того, існує також програма augenrules, яка читає правила, розташовані в /etc/audit/rules.d/, та
компілює їх у файл audit.rules
 Сам демон аудиту має деякі параметри конфігурації, які адміністратор, можливо, захоче
налаштувати. Вони знаходяться у файлі auditd.conf

Функціональність аудиту 1/3
 Ядро Linux реалізує основу функціональності LAF
 Воно збирає всі події, що підлягають аудиту, аналізує ці події на основі правил аудиту та
пересилає ті події, які вимагається піддати аудиту, до демона аудиту, що виконується в
просторі користувача
 Події аудиту генеруються в різних місцях ядра
 Програма простору користувача може створювати записи аудиту, які потрібно подавати
в ядро для подальшої обробки
 Функціональність аудиту ядра Linux налаштовується програмами
простору користувача, які взаємодіють з ядром за допомогою
спеціального каналу зв'язку netlink
 Цей канал зв’язку також повинен використовуватись програмами, які хочуть надіслати
подію аудиту до ядра
 Інтерфейс ядра netlink використовується лише програмами, що мають
такі можливості:
 CAP_AUDIT_CONTROL: Виконання операцій управління, таких як додавання або
видалення правил аудиту, встановлення або отримання параметрів аудиту;
 CAP_AUDIT_WRITE: Надсилання записів аудиту до ядра, яке, в свою чергу, пересилає
записи аудиту до демона аудиту.

 Виходячи з правил аудиту, ядро вирішує, чи подія аудиту ігнорується, чи вона
надсилається до демона аудиту простору користувача для збереження її в
протоколі аудиту
 Ядро знову відправляє повідомлення демону аудиту за допомогою згаданого
вище каналу зв'язку netlink
 Демон аудиту записує записи аудиту в протокол аудиту
 Для цього використовується внутрішній механізм черги
 Коли в черзі недостатньо місця для зберігання запису аудиту, Linux перемикається в
однокористувацький режим, зупиняється, або демон аудиту виконує дію сповіщення, вказану
адміністратором, залежно від конфігурації демона аудиту
 Доступ до даних аудиту звичайним користувачам заборонений функцією DAC
 Доступ до журналу аудиту та файлів конфігурації аудиту дозволений лише системному
адміністратору
 Системний адміністратор може визначити події, що підлягають аудиту,
використовуючи прості вирази фільтру
 Системний адміністратор також може визначити набір ідентифікаторів користувачів, для яких
аудит активний, або ж набір ідентифікаторів користувачів, аудит яких не ведеться
 Окремі файли можна налаштувати для перевірки, додавши їх до списку спостереження, який
завантажується в ядро

 Правила аудиту можна вказати для формування аудиторських даних на
основі великої кількості різних атрибутів, включаючи:
 Ідентифікатори суб’єкта або користувача
 Результат операції (успіх / невдача)
 Ідентифікація об’єкта
 Операція, що виконується на об'єкті
 Номер системного виклику
 Компоненти міток SELinux
 Система аудиту може бути налаштована на дії, якщо протокол аудиту
заповнений або досягає заданого обсягу дискового простору
 Дії, які можна налаштувати, включають зупинку роботи системи, запобігання подальшим
контрольованим діям, сповіщення адміністратору чи виконання налаштованої команди
 Linux надає програму управління, яка використовує згаданий інтерфейс
netlink
 Ця програма використовується під час завантаження системи для завантаження правил
аудиту з конфігураційного файлу /etc/audit/audit.rules
 Правила аудиту можуть бути змінені під час роботи системи

Протокол аудиту
(Audit trail) 1/2
 Запис аудиту складається з одного або декількох рядків тексту, що
містять поля у форматі з тегами «ключове_слово=значення»
 Наступна інформація міститься в усіх рядках записів аудиту:
 Type (Тип): вказує джерело події, наприклад SYSCALL, PATH, USER_LOGIN або
LOGIN
 Timestamp (Мітка часу): Дата та час створення аудиторського запису
 Audit ID: унікальний числовий ідентифікатор події
 Login ID: Ідентифікатор користувача, автентифікований системою ("auid") —
незалежно від того, чи змінив користувач свій реальний та/або ефективний
ідентифікатор згодом
 Effective user and group ID: ефективний ідентифікатор користувача та групи
процесу на момент створення події аудиту
 Успіх або невдача (де це доречно)
 Ідентифікатор процесу суб’єкта, що спричинив подію (PID)
 Ім'я хосту або термінал, який суб’єкт використав для виконання операції
 Інформація про заплановану операцію

Протокол аудиту
(Audit trail) 2/2
 Зазначена вище інформація супроводжується даними, специфічними
для конкретної події
 У деяких випадках, таких як записи подій SYSCALL, що включають
об'єкти файлової системи, для однієї події буде сформовано кілька
текстових рядків, всі вони мають однакову мітку часу та ідентифікатор
аудиту, щоб забезпечити легку кореляцію
 Протокол аудиту зберігається у вигляді тексту ASCII
 TOE надає інструменти для управління файлами ASCII, які можна використовувати
для подальшої обробки даних аудиту
 Програма ausearch дозволяє вибірково витягувати записи із протоколу аудиту,
використовуючи визначені критерії відбору
 Протокол аудиту зберігається у файлах, доступ до яких має лише
адміністратор
 Якщо протокол заповнюється і досягає порогу попередження, адміністратор отримує
повідомлення про досягнення налаштованого рівня
 Якщо протокол заповнений, демон auditd відхиляє отримання нових записів аудиту
з ядра, щоб зберегти їх у файлі

Фреймворк аудиту

Питання, що не включені до
цієї лекції
(рекомендується ознайомитись з документацією)
 Інтерфейс ядро-користувацький простір
 Розширення структури завдань для аудиту
 Аудит системних викликів
 Формування записів аудиту викликів сокета та IPC
 Аудит файлової системи
 Аудит інших дій ядра
 Ініціалізація аудиту ядра
 Формат запису аудиту
 Підтримка аудиту IPTables
 Підтримка аудиту OpenSSH
 Підтримка міток часу
auditd vs rsyslogd
 Пряме порівняння знаходиться не в документації, а на форумах. Основні ідеї
такі:
 Syslog (rsyslog, syslog-ng) та Audit мають різні цілі
 syslogd — це загальний демон протоколювання, доступний для будь-якої програми або системи
для використання з будь-яких причин
 Завдання демона auditd — відстежувати конкретні дії чи події, щоб визначити, хто що і коли
зробив
 Щоби переконатися, що у системі, де працюють обидва, вони не роблять одне і
те саме, можна перевірити конфігураційні файли кожного:
 /etc/audit/auditd.conf — файл конфігурації для auditd
 /etc/audit/audit.rules — правила аудиту для auditd, завантажені під час запуску
 /etc/rsyslog.conf — файл конфігурації для rsyslogd
 Взагалі, є сенс мати обидва демони в роботі
 rsyslogd можна використовувати локально та віддалено для реєстрації, він працює через сокети
Інтернету та Unix
 auditd має налаштовані правила, які запускаються під час запуску та завантажуються в ядро
 Якщо видалити rsyslogd, ведення журналу не буде працювати
 Якщо видалити auditd, не будуть реєструватись повідомлення ядра (зазвичай — у
/var/log/messages та(або) /var/log/audit)

Криптографічні сервіси 1/2
 Linux забезпечує криптографічно захищені мережні канали зв'язку,
що дозволяє віддаленим користувачам взаємодіяти з системою
 Користуючись одним із наступних криптографічно захищених
мережних каналів, користувач може запитувати такі сервіси:
 OpenSSH:
 Програма OpenSSH забезпечує доступ до інтерфейсу командного рядка Linux
 Користувачі можуть використовувати OpenSSH для інтерактивних сесій, а також для
неінтерактивних сесій
 Консоль, що надається через OpenSSH, забезпечує те саме середовище, що і локальна
консоль
 OpenSSH реалізує протокол SSHv2
 libvirtd:
 Демон libvirtd — це засіб управління, що дозволяє віддаленим користувачам
налаштовувати віртуальні машини
 Конфігурація охоплює всі аспекти, такі як призначення ресурсів, запуск або зупинка
віртуальних машин
 libvirtd безпосередньо взаємодіє з віртуальними машинами
 Цей інтерфейс захищений за допомогою OpenSSH

Криптографічні сервіси 2/2
 VNC:
 Інтерфейс VNC забезпечує механізм доступу для взаємодії користувачів із
консоллю віртуальної машини
 З'єднання VNC тунелюють через OpenSSH
 IPSec:
 Набір програм strongSwan реалізує сімейство протоколів IKEv1 та IKEv2 для
узгодження ISAKMP SA, а також IPSEC SA для надійного встановлення
сеансових ключів, що використовуються для мережного протоколу IPSec
 Встановлені ключі сеансу передаються в ядро, яке реалізує генерацію, а також
обробку пакетів ESP та AH як частину функціонування IPSec
 На додаток до криптографічно захищених каналів зв'язку,
Linux також забезпечує криптографічні алгоритми для
загального користування
 Криптографічні примітиви для реалізації вищезазначених
протоколів криптографічного зв'язку забезпечуються
OpenSSL

Протокол SSHv2
 Linux підтримує такі функції безпеки протоколу SSH v2.0:
 Встановлення захищеного каналу зв'язку за допомогою наступних криптографічних функцій,
передбачених протоколом SSH v2.0:
 Шифрування, як визначено в розділі 4.3 RFC4253 — ключі генеруються за допомогою генератора
випадкових чисел базової криптографічної бібліотеки;
 Обмін ключами Діффі-Хеллмана, як визначено у розділі 6.1 RFC4253;
 Хеш-функція з ключем для захисту цілісності, як визначено у розділі 4.4 RFC4253.
 Виконання автентифікації користувача за допомогою стандартного методу автентифікації на

основі пароля, який Linux забезпечує для користувачів (метод автентифікації за паролем, як
визначено у главі 5 RFC4252)
 Виконання автентифікації користувача за допомогою методу автентифікації на основі ключів
RSA, DSA або ECDSA (метод автентифікації з відкритим ключем, як визначено в главі 5
RFC4252)
 Перевірка цілісності повідомлень, якими обмінюються, та переривання з'єднання у випадку
виявлення помилки цілісності
 Застосунки OpenSSH sshd, ssh та ssh-keygen використовують генератор
випадкових чисел OpenSSL, ініціалізований /dev/random або /dev/urandom,
для створення криптографічних ключів
 OpenSSL забезпечує різні DRNG (цифрові генератори випадкових чисел), залежно від того,
чи в системі ввімкнено режим FIPS 140-2

Сімейство протоколів IPSEC та
IKEv2 1/2
 Linux реалізує сімейство протоколів IPSEC та IKE
 Ядро Linux проводить обробку ESP/AH, а користувацька
програма strongSwan охоплює обробку набору протоколів IKE
наступним чином:
 Обмін ключами в Інтернеті (Internet Key Exchange — IKE):
 Протокол IKE встановлює спільний сеансовий ключ, який використовується для
шифрування зв'язку
 Крім того, як частина протоколу IKE виконується ключова угода для ISAKMP SA, яка
захищає всю комунікацію IKE
 Протокол IKEv2 (описаний у RFC5996) реалізований демоном charon і забезпечений
виключно кодом простору користувача
 Криптографічні примітиви, необхідні для IKE, надаються OpenSSL
 IPSec:
 Після обміну або узгодження ключів для IPSEC SA, шифрування та дешифрування
фактичних даних, що передаються мережею, забезпечуються протоколами IPSec ESP,
що потенційно підтримується AH
 У Linux ядро реалізує виключно протоколи IPSec, використовуючи ключі, встановлені з
протоколом IKE

Сімейство протоколів IPSEC та
IKEv2 2/2
 Демон charon реалізує протокол IKEv2 (відповідно до RFC5996)
 Реалізація IPSec ядра підтримує і транспортний, і тунельний
режими
 Це дозволяє конфігурувати сценарії взаємодії користувач-користувач,
користувач-мережа та мережа-мережа
 Для реалізації сімейства протоколів IPSec підтримуються такі RFC:
 RFC4301, RFC4303: Визначення SPD/SAD, SA, ESP
 RFC4306, RFC4307: IKEv2 з ISAKMP, група Діффі-Хеллмана
 RFC3526, RFC5114, RFC6954: Групи Діффі-Хеллмана
 RFC4106: Режим AES GCM для IPSec
 RFC4303, RFC4307: Різні типи шифру для IPSec
 RFC4309: Режим AES CCM для IPSec
 RFC5996: IKEv2
 Криптографічні реалізації забезпечують належне обнуління
конфіденційних даних перед звільненням пов'язаної пам'яті

Сховище даних із захистом
конфіденційності 1/2
 Об'єкти файлової системи зберігаються на блокових пристроях, таких як
розділи на жорсткому диску
 Операційні системи Linux пропонують використання додаткового рівня між
файловими системами та фізичним блоковим пристроєм для шифрування та
дешифрування будь-яких даних, що передаються між файловою системою та
блоковим пристроєм
 Функціонал dm_crypt використовує перетворювач (mapper) пристроїв Linux для
забезпечення такої операції шифрування та дешифрування, яка є прозорою
для файлової системи, а отже і для користувача
 Перш ніж монтувати блоковий пристрій, який захищений схемою шифрування
dm_crypt, власник зашифрованого блокового пристрою повинен надати
парольну фразу
 Як тільки захищений пристрій dm_crypt розблоковано та змонтовано, він стане доступним як і
будь-яка інша файлова система
 Коли він відключений і заблокований (тобто ядру повідомляється про те, щоб зробити ключ
розділу недійсним), всі дані на пристрої будуть недоступні
 Якщо адміністратор отримує прямий доступ до обладнання, на якому
розміщений блоковий пристрій, можна буде прочитати лише зашифровані дані

Сховище даних із захистом
конфіденційності 2/2
 Операція шифрування та дешифрування пристрою реалізована ядром
 Щоб розблокувати зашифрований ключ розділу, що зберігається на захищеному
блоковому пристрої, програма cryptsetup виконує такі дії:
1.отримує пароль користувача
2.застосовує механізм отримання ключів LUKS до парольної фрази
3.зчитує зашифрований ключ розділу з пристрою
4.розшифровує ключ розділу за допомогою ключа, отриманого з парольної фрази користувача
5.вводить в ядро розшифрований ключ розділу та налаштовує відображення між блоковим пристроєм та
ключем розділу
 Використовуючи інструмент cryptsetup, ключ розділу можна також передати,
зашифрувавши його за допомогою іншої парольної фрази, яка може бути надана іншому
користувачеві
 Аналогічно, інструмент cryptsetup можна використовувати для стирання місця зберігання одного
зашифрованого ключа розділу
 Ключовий матеріал, який використовується cryptsetup для механізму шифрування диска,
походить з /dev/urandom та XORing 13 байт з /dev/random у генератор випадкових чисел
стану
 У режимі FIPS 140-2 для генерації ключів використовується libgcrypt DRBG, ініціалізований
/dev/urandom XORing 13 байт з /dev/random
 Інсталятор, за винятком IBM System Z, дозволяє конфігурувати схему шифрування всього
диска, де весь диск захищений, крім розділу /boot

Пакетний фільтр
 Реалізація мережного стеку ядра Linux відповідає
структурі рівнів мережних протоколів
 Реалізовано код для обробки канального (data link, 2) і
мережного (network, 3) рівнів
 Для цих рівнів передбачений незалежний механізм
фільтрації:
 Канальний рівень: ebtables реалізує механізм фільтрації для
мостів
 Мережний рівень: netfilter/iptables реалізує механізм фільтрації
для інтерфейсів, що не є мостами
 Правила фільтрації пакетів можуть бути введені в
ядро Linux для примусового застосування процесами,
що мають можливість CAP_NET_ADMIN
Фільтрація мережного рівня —
Netfilter
 Netfilter — це фреймворк для керування пакетами, реалізований
у мережному стеку ядра Linux, який обробляє мережний рівень
 Структура netfilter складається з наступних частин:
 Стек IP визначає п’ять хуків, які є чітко визначеними точками на шляху
проходження мережним пакетом стека протоколу IP
 На кожному з хуків, мережний стек буде викликати фреймворк netfilter, дозволяючи
йому працювати на цілому пакеті
 Фреймворк netfilter забезпечує реєстрацію функцій для інших частин ядра
для прослуховування різних хуків
 Коли пакет проходить один із хуків і передається в фреймворк netfilter, він викликає
кожну зареєстровану частину ядра
 Потім ці частини ядра можуть перевірити пакет і, можливо, змінити його
 В рамках перевірки ці частини ядра можуть доручити фреймворку netfilter відкинути
пакет, дозволити йому пройти, або поставити його в чергу до простору користувача
 Коли пакет позначений для черги до простору користувача, фреймворк
netfilter обробляє асинхронний зв'язок з користувацьким простором

П’ять хуків фреймворку
Netfilter
1.Коли пакет входить в мережний рівень реалізації стеку
протоколів і після застосування деяких перевірок
коректності, але перед тим, як звернутися до таблиці
маршрутизації, спрацьовує хук NF_IP_PRE_ROUTING
2.Коли пакет генерується локально, хук NF_IP_LOCAL_OUT
спрацьовує перед зверненням до таблиці маршрутизації
3.Після проходження таблиці маршрутизації, якщо код
маршрутизації позначає, що пакет буде спрямовано на
інший хост, спрацьовує хук NF_IP_FORWARD
4.Після проходження таблиці маршрутизації, якщо код
маршрутизації позначає, що пакет буде спрямовано в
локальну систему, спрацьовує хук NF_IP_LOCAL_IN
5.Коли пакет пройшов весь мережний стек і готовий до
відправлення, спрацьовує хук NF_IP_POST_ROUTING

Фільтрація мережного рівня —
IPTables
 Усім зв’язком на мережному рівні може керувати фреймворк IPTables
 Поєднання IPTables та netfilter реалізує фільтр пакетів, який
забезпечує stateful- і stateless- фільтрування пакетів шляхом
перевірки IP-заголовка, заголовка TCP, заголовка UDP та/або заголовка
ICMP кожного мережного пакету, що проходить через мережний стек
 Система відбору пакетів під назвою IPTables використовує фреймворк
netfilter для реалізації фактичної логіки фільтрації пакетів на
мережному рівні для сімейства протоколів TCP/IP
 Примітка: IPTables може виконувати трансляцію мережних адрес (NAT), а також
трансляцію адрес портів (PAT) як для простих, так і для більш складних протоколів
 Крім того, за допомогою IPTables надається підтримка маніпуляцій з пакетами
 IPTables реєструє всі хуки, надані фреймворком netfilter
 Механізм NAT/PAT використовує хуки pre-routing та post-routing
 Можливість фільтрації пакетів застосовується на хуках local-in, local-out та
forwarding

Архітектура IPTables
 IPTables складається з наступних двох компонентів:
1.Застосування пакетного фільтру в ядрі:
 Компонент ядра IPTables використовує фреймворк netfilter
 Механізмом ядра забезпечуються три списки правил фільтрації пакетів: один
для кожного хуку фреймворку netfilter, що застосовується для фільтрації
пакетів
 Кожен список містить нуль або більше правил, які перевіряються послідовно
 Правило складається з частини відповідності (також званої "розширенням
відповідності") та частини дії (також званої "розширенням цілі")
2.Програма конфігурації простору користувача:
 Програма користувацького простору iptables дозволяє конфігурувати
компоненти ядра IPTables
 Програма дозволяє вказувати одне правило для кожного виклику, де
правило містить згадані вище частину відповідності та частину дії
 Цей інструмент також дозволяє змінювати або видаляти правила, що
існують, а також конфігурувати дію за замовчуванням

Фільтрація канального рівня —
ланцюжки ebtables
 Код канального рівня, що обробляє функціональність мосту, реалізує
ланцюжки, які використовуються ebtables для застосування фільтрації
 Для реалізації ланцюжків ebtables використовується фреймворк netfilter у
наступних точках логіки проходження пакетів:
 Коли пакет потрапляє на канальний рівень Linux і після застосування деяких перевірок
коректності, але до прийняття рішення мосту, запускається ланцюжок BROUTING
 Після проходження ланцюжка BROUTING, але все ще до прийняття рішення мосту,
спрацьовує ланцюг PREROUTING
 Коли код мосту вирішує, що кадр не призначений для мосту, він пересилається на
мережний рівень і обробка на канальному рівні припиняється
 Після прийняття рішення мостової маршрутизації, якщо код маршрутизації позначає
пакет, як призначений для іншого хоста, запускається ланцюжок FORWARD
 Після прийняття рішення мостової маршрутизації, якщо код маршрутизації позначає
пакет, як спрямований до локальної системи, спрацьовує ланцюжок INPUT
 Якщо пакет генерується локально, і кадр позначено, як призначений для мосту,
спрацьовує ланцюжок OUTPUT
 Коли пакет пройшов всю логіку моста і готовий до відправлення, спрацьовує ланцюжок
POSTROUTING

Фільтрація канального рівня —
правила фільтрації ebtables
 Система вибору пакетів під назвою ebtables використовує мережний фільтр
netfilter для реалізації фактичної логіки фільтрації пакетів для кадрів
Ethernet, що проходять через мости
 Мостові мережні комунікації видно лише на канальному рівні
 Оскільки хост використовує мости для підключення віртуальних машин до навколишнього
середовища, для керування потоком трафіку можна використовувати лише ebtables
 Дані, інкапсульовані в кадрах Ethernet, не передаються через мережний стек хост-системи,
а тому не можуть бути проаналізовані та контрольовані вищеописаною структурою
IPTables
 Незважаючи на те, що мережний стек хост-системи не аналізує мостові кадри Ethernet,
фреймворк ebtables приймає весь кадр і йому дозволено працювати на цьому кадрі
 Отже, ebtables може аналізувати протокол усередині кадру Ethernet.
 Фреймворк ebtables може застосовувати фільтри на основі таких концепцій:
 Відповідність кадру/пакету: Збіги базуються на протоколах Ethernet або MAC-адресах
джерела та/або призначення
 Дія, яку потрібно виконати на обраних кадрах: Подібно до IPTables, ebtables має бути
налаштований для виконання дії з відповідним фреймом
 Дія може полягати як у відхиленні пакету, так і в його прийнятті

Ідентифікація та
 Механізми ідентифікації та
автентифікації на основі PAM
 Зміна ідентифікатору користувача
 Управління даними автентифікації
 Автентифікація на основі ключів SSH

Механізми ідентифікації та
автентифікації на основі PAM 1/2
 Linux використовує набір бібліотек під назвою "Змінні модулі
автентифікації" (Pluggable Authentication Modules — PAM), які
дозволяють адміністративному користувачеві вибирати, як
програми з підтримкою PAM автентифікують користувачів
 Linux надає модулі PAM, які реалізують усі функції безпеки для:
 Забезпечення контролю входу та встановлення всіх UID, GID та
ідентифікатора входу для суб’єкта
 Забезпечення якості паролів
 Застосування обмеження для облікових записів (наприклад, кількість
максимально допустимих одночасних сеансів для користувача)
 Застосування зміни паролів через налаштований час, включаючи контроль
якості паролів
 Примусового блокування облікових записів після невдалих спроб входу
 Обмеження використання облікового запису root для певних терміналів
 Обмеження використання команд su та sudo

Механізми ідентифікації та
автентифікації на основі PAM 2/2
 Обробка входу встановлює реальний UID, UID файлової системи,
ефективний UID і UID для входу, а також реальний GID, ефективний GID,
GID файлової системи та набір додаткових GID суб’єкта, що створюється
 Клієнтська програма, яку зазвичай надає віддалена система, повинна
правильно захистити введення користувачем пароля (наприклад,
надавати лише приховану інформацію, як-то символи на екрані)
 Після успішної ідентифікації та автентифікації, Linux ініціює сеанс для
користувача та створює початкову оболонку входу як перший процес, з
яким користувач може взаємодіяти
 Linux забезпечує механізм блокування сеансу або автоматично після
настроюваного періоду бездіяльності для цього сеансу, або за запитом
 Облікові записи користувачів зберігаються у файлах конфігурації
(/etc/passwd та /etc/shadow)
 Обидва вони доступні для запису лише для користувача root
 Крім того, /etc/shadow доступний для зчитування лише користувачу root
 Редагування обох файлів виконується за допомогою набору адміністративних програм

Підсистема ідентифікації та
автентифікації (що було до PAM)
 Облікові записи: файл /etc/passwd
 login_name:*:UID:GID:user_info:home:shell
 iv13:*:1013:1013:Ivan Ivanenko:/usr/home/iv13:/usr/bin/bash
 Хеш-образи паролів (DES, MD5, SHA1, SHA2): /etc/shadow
 Автентифікація
 Вхід в систему: утиліта login
 Перехід в інший обліковий запис: утиліта su
 Зміна пароля: утиліта passwd
 Авторизація: запуск програми, що вказана у файлі
/etc/passwd, від імені користувача
 Додавання користувачів: adduser (або useradd)
 Редагування облікових записів: vipw

Змінний модуль
 PAM відповідає за підсистему ідентифікації та автентифікації
 PAM забезпечує централізований механізм автентифікації всіх служб
 PAM дозволяє обмежувати доступ до програм та альтернативні
методи автентифікації, що налаштовуються
 Для отримання більш детальної інформації про PAM див. Веб-сайт проекту PAM за
адресою http://www.kernel.org/pub/linux/libs/pam
 PAM складається з набору спільних бібліотечних модулів, які надають
програмам відповідні сервіси автентифікації та аудиту
 Програми оновлюються, щоб передати їх код автентифікації та аудиту в PAM, що
дозволяє системі застосовувати послідовну політику ідентифікації та автентифікації,
а також створювати відповідні записи аудиту
 Наступні програми удосконалені для використання PAM:
 login  sshd
 passwd  chage
 su, sudo  chfn
 useradd, usermod, userdel  chsh
 groupadd, groupmod, groupdel  newrole

Компоненти PAM
 PAM складається з бібліотек-модулів, які знаходяться у каталозі /lib/security/
 Кожний модуль реалізує певний механізм автентифікації
 Для кожної з програм, що використовує PAM, є її специфічний сценарій
 Ці сценарії розміщені у каталозі /etc/pam.d
 Ім'я кожного сценарію в цьому каталозі (як правило) збігається з ім'ям програми,
для якої він призначений
 Наприклад, сценарій для login має адресу /etc/pam.d/login
 Для деяких модулів є специфічні файли конфігурації, які знаходяться у каталозі /etc/security
 Якщо немає каталогу /etc/pam.d (у сучасних системах він є), то налаштування PAM
здійснюється за допомогою файлу /etc/pam.conf
 Модулі PAM класифікують за типами. Кожний модуль повинен виконувати функції
хоча б одного з чотирьох типів:
 auth — модуль автентифікації, використовується для автентифікації користувачів або створення і
вилучення облікових даних
 account — модуль керування обліковими записами, виконує дії, що пов'язані з доступом, терміном
придатності облікових даних чи записів, правилами і обмеженнями для паролів тощо
 session — модуль керування сеансами, використовується для створення і завершення сеансів
 password — модуль керування паролями, виконує дії, що пов'язані зі змінами і оновленнями
паролів

Автентифікація з PAM 1/2
1.Програма із підтримкою PAM здійснює виклик до PAM для
ініціалізації певних структур даних
 З ініціалізацією програма, що здійснює виклик, надає PAM ім’я, яке в кінцевому
підсумку використовується для пошуку файлу конфігурації стека автентифікації в
/etc/pam.d/
 Зазвичай це ім’я дорівнює імені програми
2.Модуль PAM знаходить файл конфігурації для цієї програми з
/etc/pam.d/application_name і отримує список модулів PAM,
необхідних для обслуговування цієї програми
 Якщо він не може знайти файл конфігурації для певної програми, він
використовує /etc/pam.d/other
3.Залежно від порядку, зазначеного у файлі конфігурації, PAM
завантажує відповідні модулі для операції PAM, яку вимагає
програма, що викликає
 PAM забезпечує один зворотний виклик для кожного типу модуля — тип модуля
узгоджується з розділами “auth”, “session”, "password" та "account" у файлах
конфігурації PAM

Автентифікація з PAM 2/2
4.Код модуля автентифікації виконує запитувану операцію
залежно від типу модуля
 Модуль може вимагати введення від користувача
 Модуль може виконувати операції, які навряд чи мають щось спільне з
автентифікацією, але дії яких необхідні для налаштування середовища
5.Кожен модуль автентифікації виконує свою дію і передає
результат назад програмі
6.Бібліотека PAM модифікована для створення запису аудиту
типу USER_AUTH, щоб занотувати успіх або невдачу модуля
7.Програма здійснює відповідні дії на основі сукупних
результатів усіх модулів автентифікації

Приклади модулів PAM
 pam_access забезпечує керування входом в систему у вигляді служби,
що протоколюється, за допомогою імені користувача і домену в
залежності від правил, заданих у файлі /etc/security/access.conf
 pam_cracklib перевіряє паролі на відповідність правилам для паролів
 pam_env sets/unsets встановлює і скидає змінні середовища з файлу
/etc/security/pam_env_conf
 pam_debug виконує зневадження PAM
 pam_deny блокує модулі PAM
 pam_echo виводить повідомлення
 pam_exec виконує зовнішню команду
 pam_ftp модуль для анонімного доступу
 pam_localuser перевіряє наявність імені користувача у файлі /etc/passwd
 pam_unix виконує звичайну автентифікацію на основі пароля з файлу
/etc/passwd

Приклад /etc/pam.d/login
#%PAM-1.0
auth requisite /lib/security/pam_unix.so nullok
#set_secrpc
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_env.so
auth required /lib/security/pam_mail.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so strict=false
session required /lib/security/pam_unix.so none #
debug or trace
session required /lib/security/pam_limits.so

Зміна ідентифікатора
користувача — команда su
 Команда su призначена для переключення на інший ідентифікатор, який встановлює
новий сеанс входу та створює нову оболонку з новим ідентифікатором
 При виклику su, користувач повинен надати облікові дані, пов'язані з цільовою
ідентифікацією — тобто, коли користувач хоче перейти на інший ідентифікатор
користувача, він повинен надати пароль, що захищає обліковий запис цільового
 Основне використання команди su в Linux полягає у наданні належним чином
уповноваженим особам можливості приймати ідентифікатор root для виконання
адміністративних дій
 Можливість входу в систему з ідентифікатором root обмежена лише визначеними терміналами
 Використання команди su для переходу в root дозволено лише користувачам, що належать до спеціальної
групи
 Користувачі, які не мають доступу до терміналу, де дозволено вхід в систему як root, і не є членами цієї
спеціальної групи, не зможуть переключити свої ідентифікатори користувача (UID) — реальний, файлової
системи та ефективний — на ідентифікатор root, навіть якщо вони знатимуть автентифікаційну інформацію
для root
 Зауважте, що коли користувач виконує програму, у якій встановлений біт suid, лише
ефективний ідентифікатор користувача та ідентифікатор файлової системи змінюються на
ідентифікатор власника файлу, що містить програму, тоді як реальний ідентифікатор
користувача залишається ідентифікатором того, хто викликає програму
 Ідентифікатор входу (login ID) не змінюється ні командою su, ні виконанням програми, яка
має біт suid або sgid, оскільки він використовується для аудиту

Зміна ідентифікатора
користувача — команда sudo
 Команда sudo призначена для надання користувачам дозволів на
виконання команд з іншим ідентифікатором користувача
 При виклику sudo користувач повинен пройти автентифікацію за
допомогою власних облікових даних
 sudo пов’язано зі складним набором правил, який можна задіяти,
щоб вказати, який:
 початковий ідентифікатор користувача
 що походить з якого хосту
 може отримати доступ до команди, команди з певними прапорами конфігурації
або до всіх команд у каталозі
 з яким новим ідентифікатором користувача.
 При перемиканні ідентифікаторів, реальний, файлової системи та
ефективний ідентифікатори користувача, а також реальний,
файлової системи та ефективний ідентифікатори групи змінюються
на ті, що відповідають користувачу, зазначеному в команді (після
успішної автентифікації)

Управління даними
 Кожен екземпляр Linux підтримує власний набір користувачів із їхніми
паролями та атрибутами
 Незважаючи на те, що один і той самий користувач може мати облікові записи на
різних серверах, взаємопов'язаних мережею, що працюють під керуванням
екземпляру Linux, ці облікові записи та їх параметри не синхронізуються в різних
екземплярах Linux
 Як результат, один і той же користувач може мати різні імена користувачів, різні
ідентифікатори користувачів, різні паролі та різні атрибути на різних машинах у
мережному середовищі
 Кожен екземпляр Linux в мережі підтримує власну адміністративну базу
даних, вносячи всі адміністративні зміни в локальний екземпляр Linux
 Файл /etc/passwd містить для кожного користувача ім'я користувача, ідентифікатор
користувача, індикатор, чи дійсний пароль користувача, ідентифікатор основної групи
користувача та іншу (не пов'язану з безпекою) інформацію
 Файл /etc/shadow містить для кожного користувача хеш пароля
користувача, ідентифікатор користувача, час останньої зміни пароля,
час закінчення терміну дії, а також термін дії пароля та деяку іншу
інформацію

 Користувачам дозволено змінювати свої паролі за
допомогою команди passwd
 Ця програма може читати та змінювати вміст /etc/shadow для введення
пароля користувача, який, як правило, буде недоступним для
непривілейованого процесу користувача
 Користувачів також попереджають про необхідність зміни їх паролів під
час входу, якщо термін дії пароля скоро закінчиться, і забороняють
входити в систему, якщо термін дії пароля закінчився
 Час останнього успішного входу реєструється в каталозі
/var/log/tallylog, де зберігається один файл на користувача
 TOE відображає користувачам інформативні банери до або
під час входу в систему
 Банери можна визначити у файлах /etc/issue для входів через
фізичну консоль або /etc/issue.net для віддалених входів,
наприклад через SSH

 SSSD — це системний демон з основною функцією забезпечення доступу до
віддаленого ресурсу ідентифікації та автентифікації через загальний фреймворк,
який може забезпечити кешування та автономну підтримку системи
 Він забезпечує модулі PAM та NSS
 Він також забезпечує кращу базу даних для зберігання локальних користувачів, а також розширених
даних користувачів
 SSSD можна налаштувати на використання власного домену LDAP (тобто
постачальника ідентифікатора LDAP з автентифікацією LDAP) або постачальника
ідентифікатора LDAP з автентифікацією Kerberos
 Однією з основних переваг SSSD є автономна автентифікація
 Це розв’язує випадок, коли користувачі мають окремий корпоративний обліковий запис та
локальний обліковий запис машини через загальну вимогу щодо впровадження віртуальної
приватної мережі (VPN)
 SSSD може кешувати віддалені ідентифікатори та облікові дані автентифікації
 Це означає, що користувач все ще може автентифікуватися за допомогою цих віддалених
ідентифікаційних даних, навіть коли машина перебуває в режимі офлайн
 У системі SSSD користувачеві потрібно керувати лише одним обліковим записом
 SSSD інтегрується з фреймворками PAM та NSS і тому може використовуватися
разом із модулями PAM для локальних сховищ облікових даних

Автентифікація на основі
ключів SSH
 На додаток до автентифікації на основі PAM, сервер OpenSSH може виконувати
автентифікацію на основі ключів
 Коли користувач хоче увійти, замість введення пароля, користувач застосовує свій ключ SSH
 Після успішної перевірки сервер OpenSSH вважає користувача автентифікованим та виконує операції
на основі PAM
 Щоб встановити автентифікацію на основі ключа, користувач спочатку має
сформувати пару ключів RSA або ECDSA
 Приватна частина пари ключів залишається на стороні клієнта
 Відкрита частина копіюється на сервер у файл ~/.ssh/authorized_keys, який знаходиться в домашньому
каталозі користувача, в якості якого він бажає увійти
 Коли виконується операція входу, протокол SSHv2 намагається виконати
автентифікацію "publickey", використовуючи приватний ключ на стороні клієнта та
відкритий ключ, знайдений на стороні сервера
 Операції, що виконуються під час автентифікації за допомогою відкритих ключів, визначені в главі 7
RFC4252
 Користувачі повинні захищати частину свого приватного ключа так само, як захищати
пароль
 Необхідні відповідні налаштування дозволу для файлу, що містить приватний ключ
 Для посилення захисту приватного ключа користувач може зашифрувати ключ там, де
пароль служить ключем для операції шифрування

Блокування сеансу
 Linux використовує програму screen(1), яка
блокує поточний сеанс користувача або
після встановленого адміністратором часу
бездіяльності, або за запитом користувача
 Щоб розблокувати сеанс, користувач
повинен надати свій пароль
 screen використовує PAM для перевірки
пароля і дозволяє користувачеві отримати
доступ до його сеансу після успішної
перевірки

Захист від використання
вразливостей коду — ASLR
 Linux застосовує технологію випадкового розташування
програми в адресному просторі (Address Space Layout
Randomization, ASLR)
 Успіх атак, подібних до переповнення стеку, заснований на знанні
зловмисником взаємного розташування різних модулів програми, яку атакують
 Тому випадкова перестановка цих модулів (яка, зрозуміло, повинна не
порушувати цілісність і функціональність самої програми) зробить більшість
таких атак марними
 У найгіршому випадку зловмисник зможе викликати аварійне завершення процесу, але
не зможе отримати контроль над ним
 Крім того, «падіння» процесу внаслідок атаки, ймовірно, притягне більше уваги
системного адміністратора, ніж успішне і непомітне впровадження коду
 Технологія ASLR впроваджена у ядро Linux, починаючи з версії
2.6.12 (2005 рік — значно раніше, ніж у Windows)
 Для рандомізованого розміщення у пам'яті образу виконуваного
файлу він має бути скомпільований у режимі Position-independent
executable

Основні недоліки традиційної
моделі безпеки Linux (і Unix)
 Недостатня вибірковість системи розмежування доступу
 Дуже часто права доступу надаються за принципом «або усім, або лише
одному». Це стосується як користувачів, так і інших агентів системи
 Внаслідок цього користувач часто змушений приймати права root (або через
suid-біт, або командою su), з усіма повноваженнями суперкористувача, для
виконання завдань, що насправді вимагають значно менших прав
 Надання усіх можливих прав і привілеїв одному обліковому
запису суперкористувача
 Користувач, що несанкціоновано отримав доступ до прав root, одержує
повний контроль над системою
 Відсутність розмежування прав доступу до деяких важливих
об’єктів системи
 Наприклад, з будь-якого сеансу користувача можна запустити сервер TCP/IP
(якщо тільки порт вже не зайнятий іншим застосунком)
 Для більшості користувачів така функціональність є зайвою і може мати
наслідком порушення безпеки

Безпека
систем
Лекції 13-14. Архітектура безпеки і механізми захисту
Android

ОС мобільних пристроїв:
специфічні вимоги
 Мобільні пристрої мають обмежені ресурси: обчислювальна
потужність, пам’ять, обсяг сховища даних, ємність батареї
 Мобільні пристрої мають різні форм-фактори і можливості:
розміри і роздільну здатність екранів, клавіатури (або їх
відсутність взагалі), різні бездротові інтерфейси, інтегровані
і зовнішні периферійні пристрої, різні архітектури процесорів
(ARM, x86) тощо
 ОС має бути орієнтована на непрофесійного користувача:
має бути легкою в користуванні, інтуїтивно зрозумілою, не
вимагати значних зусиль в обслуговуванні, але
забезпечувати достатню безпеку, зокрема протидію
шкідливим програмам
 Ринок вимагає позитивних перших вражень, швидкого
розвитку, і не пробачає помилок

Принципи, виведені з вимог
 Ядро ОС має бути компактним і вимагати мінімальний обсяг ресурсів
 ОС не буде застосовувати витіснення коду і даних з оперативної
пам’яті на зовнішній пристрій і повинна працювати і керувати
прикладними програмами у фіксованому обсязі ОП
 Повинні бути надані API і механізми, що дозволять пристрою “спати”
будь-коли це можливо для економії батареї
 Прикладні програми мають бути абстраговані від ОС і апаратури
 Прикладні програми мають виконуватись у пісочниці для мінімізації
впливу шкідливих програм
 Стандартні компоненти, що існують, повинні застосовуватись
максимально
 Необхідно надати можливість стороннім розробникам створювати
безліч прикладних програм
 Треба створити власний магазин прикладних програм (App store) і
зробити його привабливим для розробників

Реалізація принципів в ОС
Android 1/2
1.Основою платформи Android є модифіковане ядро Linux
 Linux є надійною масштабованою технологією, працює на мільйонах
вбудованих пристроїв, має потужну підтримку різноманітної апаратури і
розвинені засоби безпеки
 Завдяки своїй історії постійного дослідження, атак та виправлень з боку тисяч
розробників, Linux перетворився на стабільне та безпечне ядро, якому
довіряють багато корпорацій та фахівців з безпеки
 Плюс, це ядро з відкритим кодом
2.Java для прикладних програм
 Java є доведеною технологією популярною у розробників: Enterprise (JSP),
Mobile (J2ME) та інші
 Програми Java виконуються у віртуальній машині, тобто можуть бути
незалежними від ОС і обладнання
 Для мінімізації вимог до процесору і пам’яті бібліотеки Java і середовище
виконання Java (VM/runtime) були суттєво перероблені, тому “Android Java” не є
100% еквівалентною “Sun/Oracle Java”

Реалізація принципів в ОС
Android 2/2
3.Оптимізована Java VM в якості середовища виконання
 Розробники Android написали власну “легку” Java VM і середовище виконання,
оптимізоване для мобільних пристроїв
 Перша версія, що застосовувалась до Android 4.4, називалась Dalvik
 Нова версія середовища виконання називається ART (Android RunTime)
 Оптимізована архітектура VM включає специфічні для мобільних пристроїв риси, такі
як поділювана пам’ять, швидкий старт, а також втрачає найбільш “важкі” вимоги Java
VM (на жаль, це включає і суттєву частину безпеки)
4.Пісочниці
 Програми, що працюють на Android, підписуються та ізолюються в пісочницях,
пов’язаних із їх підписом
 Пісочниця визначає привілеї, доступні для програми
 Програми, як правило, побудовані для виконання в середовищі виконання Android та
взаємодії з операційною системою через фреймворк, що описує системні служби,
інтерфейси програмування платформи (API) та формати повідомлень
 Різноманітні мови високого та нижчого рівня, такі як Java, Kotlin та C/C ++, дозволені
та працюють в одній і тій же пісочниці

Програмний стек Android
Джерело: Android Enterprise Security Whitepaper 2019

Безпека за дизайном (огляд) 1/2
 Android використовує апаратні та програмні засоби захисту для

досягнення надійного захисту
 Безпека починається на апаратному рівні, де користувач
автентифікується за допомогою облікових даних блокування екрана
 Перевірене завантаження (Verified Boot) гарантує, що системне
програмне забезпечення не було підроблено, а апаратне шифрування
та обробка ключів допомагають захистити дані при передачі та в
стані зберігання
 Захист, вбудований на програмному рівні, є надзвичайно важливим
для забезпечення безпеки пристроїв Android
 Google Play Protect — це найпоширеніша у світі служба виявлення
загроз, яка щодня активно сканує понад 50 мільярдів програм на
пристроях для відстеження шкідливої поведінки
 Play Protect сканує всі програми, включаючи загальнодоступні програми від Google
Play, системні програми, оновлені виробниками та постачальниками, і програми зі
сторонніх джерел

Безпека за дизайном (огляд) 2/2
 Пісочниця ізолює та захищає програми Android,

перешкоджаючи доступу шкідливих програм до приватної
 Android також захищає доступ до внутрішніх компонентів
операційної системи, щоб запобігти експлуатації вразливостей
 Обов’язкове постійне шифрування допомагає захистити дані,
навіть якщо пристрої потрапляють у чужі руки
 Шифрування захищено ключами Keystore, які зберігають криптографічні
ключі в контейнері, що ускладнює вилучення з пристрою
 Розробники можуть безпечно та легко використовувати Android KeyStore із
Jetpack Security
 Adiantum надає можливості шифрування для пристроїв з меншим рівнем
потужності, які не мають апаратної реалізації інструкцій Advanced
Encryption Standard (AES) у процесорі, що потенційно дозволяє компаніям
використовувати дешевші пристрої без втрати криптографічної безпеки

Апаратно-забезпечена
безпека
 Перевірене завантаження (Verified Boot)
 Довірене середовище виконання (Trusted Execution Environment)
 Система зберігання ключів (KeyStore) Android
 Атестація ключів KeyStore
 “Брелок” (KeyChain)
 Jetpack Security
 Розшифровка ключа на розблокованих пристроях
 Прив'язка версії (Version Binding)
 Підтримка обладнання, що захищає від втручання (Tamper-resistant)
 Біометрія
 Автентифікація за відбитками пальців
 Автентифікація обличчя
 Додаткові методи автентифікації
 Захищене підтвердження (Protected Confirmation)

Verified Boot 1/2
 Підтверджене завантаження (Verified Boot) — це безпечний процес
завантаження Android, який перевіряє системне програмне
забезпечення перед його запуском
 Це ускладнює збереження програмних атак при перезавантаженні та забезпечує
користувачам безпечніший стан під час завантаження
 Кожен етап перевіреного завантаження має криптографічний підпис
 Кожна фаза процесу завантаження перевіряє цілісність наступної фази перед
виконанням цього коду
 Починаючи з Android 7.0, повне завантаження сумісного пристрою із заблокованим
завантажувачем триває, лише якщо ОС задовольняє перевірку цілісності
 Стан перевіреного завантаження використовується як вхід у процесі
отримання ключів шифрування диска
 Якщо стан перевіреного завантаження змінюється (наприклад, користувач
розблоковує завантажувач), захищене обладнання забороняє доступ до даних, що
використовуються для отримання ключів шифрування диска, які
використовувались, коли завантажувач був заблокований

Verified Boot 2/2
 Підтверджене завантаження на сумісних пристроях
під управлінням Android 9.0 і новіших версій
вимагає захисту від відкату (rollback)
 Це означає, що компрометація ядра (або фізична атака) не
може помістити стару, більш уразливу версію ОС в систему
та завантажити її
 Крім того, стан захисту від відкату зберігається в
захищеному сховищі (tamper-evident storage)
 Підприємства можуть перевірити стан
перевіреного завантаження за допомогою атестації
ключів KeyStore
 Атестація ключів KeyStore потрібна для сумісних пристроїв,
що постачаються з Android 8.0 і новішими версіями

Trusted Execution
Environment
 Пристрої Android, які підтримують екран блокування, мають вторинне,
ізольоване середовище, яке називається Trusted Execution Environment (TEE)
 Це дозволяє подальше відокремлення від будь-якого ненадійного коду
 Можливості, як правило, реалізуються з використанням безпечного обладнання, такого як
технологія ARM TrustZone ®
 TEE відповідає за деякі операції на пристрої, найкритичніші з міркувань безпеки,
включаючи:
1.Перевірка коду блокування екрана: доступна на пристроях, які підтримують захищений екран
блокування та поставляються з Android 7.0 і новішими версіями. Перевірка блокованого екрану
надається TEE, якщо немає ще більш безпечного середовища
2.Відповідність шаблону відбитків пальців: доступна на пристроях, які мають датчик відбитків
пальців і постачаються з Android Marshmallow 6.0 і вище
3.Захист та керування ключами KeyStore: доступно на пристроях, що підтримують захищений
екран блокування і постачаються з Android 7.0 і вище
4.Захищене підтвердження: використовує захищений апаратним забезпеченням
користувальницький інтерфейс, який називається Trusted UI, щоб забезпечити високу надійність
критичних транзакцій, доступних на пристроях під управлінням Android 9.0 і новіших версій
5.Управління цифровими правами (DRM): розширюваний фреймворк, що дозволяє програмам
керувати контентом, захищеним правами, відповідно до ліцензійних обмежень, пов’язаних із
контентом

Android Keystore System 1/2
 Система Android KeyStore є основою захисту даних на пристроях
 Зберігає криптографічні ключі в контейнері, що ускладнює вилучення їх із пристрою
 Змушує програми визначати дозволене використання своїх ключів, а потім
застосовує ці обмеження поза процесами цих програм
 Це зменшує можливість несанкціонованого використання ключових матеріалів на пристрої
Android
 Починаючи з Android 7.0 — атестація ключів (Keymaster 2)
 дозволяє службам поза пристроєм перевіряти, що ключі, що використовуються в
програмах, зберігаються в сховищі ключів, що підтримується апаратним
забезпеченням
 Починаючи з Android 8.0 — атестація ідентифікаторів (Keymaster 3)
 дозволяє пристрою надати підтвердження своїх апаратних ідентифікаторів, таких
як серійний номер або IMEI
 Пристрої з Android 9.0 і новіших версій використовують апаратно
підтримуваний Keymaster 4
 пропонує додатковий захист від фальсифікації

Android Keystore System 2/2
 KeyStore підтримує
 симетричні криптографічні примітиви:
 AES (Advanced Encryption Standard)
 HMAC (Keyed-Hash Message Authentication Code)
 асиметричні криптографічні алгоритми
 Елементи керування доступом визначаються під час генерації
ключів і застосовуються протягом усього терміну дії ключа
 Ключі можуть бути обмежені:
 для використання лише після автентифікації користувача
 лише для визначених цілей
 або із зазначеними криптографічними параметрами
 Для пристроїв, які підтримують захищений екран блокування та
постачаються з Android 7.0 або новішою версією, KeyStore
повинен бути реалізований у захищеному обладнанні
 Це гарантує, що навіть у випадку компрометації ядра ключі KeyStore не можна
витягти із захищеного обладнання

Атестація ключів KeyStore
 Атестація ключів надає серверу можливість отримати
впевненість у властивостях ключів
 Атестацію ключів підтримують сумісні пристрої, що постачаються з
Android 8.0 і вище
 Пристрої, що підтримують Google Play, оснащують на
заводі ключем атестації, згенерованим Google
 Захищене обладнання на таких пристроях може підписувати за
допомогою ключа атестації специфікації, що засвідчують
властивості ключів, захищених захищеним обладнанням
 наприклад, те, що ключ створено і не може залишити захищене обладнання
 Атестація ключів краще захищає розташування важливих
властивостей пристрою, таких як версія ОС, рівень
виправлення та проходження перевіреного завантаження
(Verified Boot)

KeyChain (“Брелок”)
 Клас KeyChain забезпечує доступ до приватних ключів та відповідних
ланцюжків сертифікатів у сховищі облікових даних
 KeyChain часто використовується Chrome, віртуальними приватними
мережами (VPN) та корпоративними програмами для доступу до
ключів, імпортованих користувачем або програмою управління
мобільними пристроями
 KeyStore призначений для неподілюваних ключів для конкретних
програм, KeyChain — для ключів, які призначені для спільного
використання в профілі
 Наприклад, агент управління мобільними пристроями може імпортувати ключ, який
Chrome використовуватиме для корпоративного веб-сайту
 Android 10 представляє кілька вдосконалень API KeyChain
 Коли програма викликає KeyChain.choosePrivateKeyAlias, пристрої тепер
фільтрують список сертифікатів, які користувач може вибрати на основі емітентів та
ключових алгоритмів, зазначених у дзвінку
 KeyChain більше не вимагає від пристрою блокування екрана перед тим, як
імпортувати ключі або сертифікати центру сертифікації (CA)

Jetpack Security
 Розробники можуть використовувати Android KeyStore за
допомогою Jetpack Security
 MasterKeys дозволяє розробникам створювати безпечний
ключ AES 256 GCM нестандартно або для випадків
розширеного використання, які визначають параметри для
контролю авторизації ключа
 Jetpack Security також забезпечує криптографічні абстракції
вищого рівня для шифрування файлів (EncryptedFile) та
SharedPreferences (EncryptedSharedPreferences)
 Рекомендується використовувати Jetpack Security усіма
контролерами Device Policy (DPC), які контролюють
локальні політики пристроїв та системні програми на
пристроях, корпоративні програми, загальнодоступні та
приватні програми

Розшифрування ключів на
розблокованих пристроях
 Android 9.0 впровадив прапор
unlockedDeviceRequired
 Цей параметр визначає, чи вимагає KeyStore розблокування
екрану перед тим, як дозволити використання зазначеного
ключа
 Ці типи ключів добре підходять для шифрування
конфіденційних даних для зберігання на диску,
таких як дані про стан здоров'я або дані
підприємства
 Прапор надає користувачам більшу впевненість у
тому, що дані не можна розшифрувати, коли
пристрій заблоковано у разі втрати або викрадення
телефону
Прив'язка версії
(Version Binding)
 У Keymaster 2 і 3 всі ключі також прив'язані до операційної
системи та рівня виправлення образу системи
 Це гарантує, що зловмисник, який виявив слабкі місця у
старій версії системи або програмного забезпечення TEE, не
зможе повернути пристрій до вразливої версії та
використовувати ключі, створені з новою версією
 Крім того, коли на пристрої, який оновлено до нової версії
або рівня виправлення, використовується ключ із заданою
версією та рівнем виправлення, ключ модернізується перед
тим, як його можна буде використовувати, а попередня
версія ключа втрачає силу
 Таким чином, у міру оновлення пристрою, ключі будуть просуватись
вперед разом із пристроєм, але будь-яке повернення пристрою до
попереднього випуску призведе до того, що ключі стануть
непридатними

Підтримка обладнання,
що захищає від втручання
Tamper-resistant hardware support
 Починаючи з Android 8.0, сумісні пристрої

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

Біометрія 1/2
 В Android 9.0 і вище система BiometricPrompt API надає діалоги
біометричної автентифікації, що можуть використовуватися від
імені програми
 Це створює відповідний вигляд, відчуття та розміщення діалогового вікна та
надає користувачам більшої впевненості у їх автентифікації за допомогою
біометричних даних за допомогою надійного відстежувача облікових даних
 Цей API використовується разом із системою Android Keystore
 Захист біометричних даних здійснюється за допомогою апаратного модуля
захисту Strongbox Keymaster, який надійно зберігає та обробляє
криптографічні ключі на пристрої
 Пристрої можуть використовувати біометричну автентифікацію
для захисту приватної інформації та важливих корпоративних
даних, доступних через пристрої, що використовуються в
корпоративних умовах
 BiometricPrompt API доступний розробникам для інтеграції
біометричної автентифікації у свої програми

Біометрія 2/2
 Фреймворк Android включає біометричну автентифікацію обличчя та
відбитків пальців
 Android можна налаштувати для підтримки інших форм біометричної аутентифікації, таких
як Iris
 Усі біометричні реалізації повинні відповідати вимогам безпеки та мати
високий рейтинг, щоб брати участь у класі BiometricPrompt
 Методи розблокування на основі біометрії, як правило, оцінюються на
основі коефіцієнта помилкового прийняття (False Accept Rate — FAR)
 Android використовує дві додаткові метрики, щоб допомогти виробникам пристроїв оцінити
свою безпеку: коефіцієнт прийняття самозванця (Imposter Accept Rate — IAR) та
коефіцієнт прийняття підроблених даних (Spoof Accept Rate — SAR)
 Крім того, виробники пристроїв Android можуть отримати доступ до
рекомендацій щодо найкращих практик системної безпеки щодо
використання біометричної автентифікації
 Біометричні датчики класифікуються на основі рівня їх прийняття та
підміни, а також безпеки біометричного конвеєра
 Доступна методологія тестування, яка допоможе виміряти реалізацію цих
методів розблокування

Методи біометричної
Автентифікація за відбитками пальців
 На пристроях із датчиком відбитків пальців користувачі можуть
зареєструвати один або кілька відбитків пальців і використовувати ці
відбитки пальців для розблокування пристрою та виконання інших
завдань
 Android використовує мову визначення інтерфейсу апаратного
забезпечення відбитків пальців (Hardware Interface Definition Language
— HIDL) для підключення до бібліотеки та обладнання конкретного
постачальника, наприклад датчика відбитків пальців
 Android підтримує Gatekeeper для автентифікації за відбитками пальців
та PIN/шаблоном/паролем
 Підсистема Gatekeeper виконує цю автентифікацію у довіреному середовищі
виконання, реєструючи та перевіряючи паролі за допомогою коду автентифікації
повідомлень на основі хеш-коду (Hash-Based Message Authentication Code —
HMAC) за допомогою апаратно-захищеного секретного ключа
 Документ визначення сумісності Android визначає вимоги щодо
впровадження біометричної безпеки

Методи біометричної
Автентифікація обличчя
 Автентифікація обличчя дозволяє користувачам розблокувати свій пристрій,
просто подивившись на передню частину пристрою
 Android 10 додає підтримку нового стека автентифікації обличчя, який може
безпечно обробляти кадри камери, зберігаючи безпеку та конфіденційність під час
автентифікації обличчя на підтримуваному обладнанні
 Android 10 також пропонує метод для реалізації, що відповідає безпеці, щоб
забезпечити інтеграцію у програми для транзакцій, такі як Інтернет-банкінг або інші
послуги
Додаткові методи автентифікації
 Android підтримує фреймворк Trust Agent для розблокування пристрою
 Google SmartLock використовує цей фреймворк, щоб дозволити пристрою
залишатися розблокованим до тих пір, поки він залишатиметься з користувачем,
що визначається певною присутністю користувача чи іншими сигналами
 Однак SmartLock не відповідає такому рівню надійності, як інші методи розблокування на Android, і
йому не дозволено розблоковувати ключі KeyStore, пов’язані з автентифікацією
 Організації можуть вимкнути довірчих агентів, використовуючи прапор
KEYGUARD_DISABLE_TRUST_AGENTS у політиках EMM

Захищене підтвердження
(Protected Confirmation)
 Android Protected Confirmation використовує апаратно захищений
користувальницький інтерфейс (Trusted UI) для здійснення критичних
транзакцій поза операційною системою на пристроях з ОС Android 9.0 або
новішої версії
 Це захищає операції від шахрайських програм або скомпрометованої операційної
системи
 Коли програма викликає захищене підтвердження, керування
передається довіреному інтерфейсу, де відображаються дані транзакцій
та отримується підтвердження користувачем правильності даних
 Після підтвердження намір криптографічно підтверджується та
захищається від фальсифікації, коли його передають надійній стороні
 Загалом транзакція має вищий захист та безпеку порівняно з іншими
формами вторинної автентифікації
 Існує кілька прикладів використання (use cases) захищеного
підтвердження Android, такі як грошові перекази від особи до особи,
автентифікація користувача чи інновації, такі як підтвердження
правильних ін’єкцій інсулінової помпи

Безпека операційної системи
(Operating System Security)
 Android використовує багатошаровий захист операційної системи
 З кожною версією Android операційна система додатково зміцнюється, щоб
мати належний захист від постійних загроз, з якими стикаються підприємства
Цілісність пристрою (Device Integrity)

 Функції цілісності пристрою захищають мобільний пристрій від
скомпрометованої та(або) несанкціоновано модифікованої
 Android приймає кілька заходів для гарантування цілісності
пристрою, включаючи:
 Пісочницю (sandboxing)
 SELinux
 Seccomp
 Права доступу Unix
 Рівень апаратної абстракції (Hardware Abstraction Layer – HAL)

Sandboxing
 Android запускає всі програми всередині пісочниць, щоб
запобігти зловмисному або помилковому коду програм, не
порушуючи інші програми або компоненти системи
 Оскільки пісочниця програми застосована в ядрі, вона
охоплює всю програму незалежно від конкретного
середовища розробки, API або використовуваної мови
програмування
 За замовчуванням програми не можуть взаємодіяти між
собою та мають обмежений доступ до операційної системи
 Подібним чином, системні компоненти працюють у найменш
привілейованих пісочницях, щоб запобігти впливу
компрометації в одному компоненті на інші
 Наприклад, віддалено доступні компоненти, такі як медіа-
сервер та WebView, ізольовані у власній обмеженій пісочниці

SELinux
 Android використовує Security-Enhanced Linux (SELinux) для забезпечення
мандатного керування доступом (MAC) над усіма процесами, включаючи ті, що
мають права root/суперкористувача
 SELinux дозволяє Android краще захищати та обмежувати системні служби,
контролювати доступ до даних програм та системних журналів, зменшувати вплив
шкідливого програмного забезпечення та захищати користувачів від потенційних
вад коду на мобільних пристроях
 SELinux працює за принципом відмовлення за умовчанням: все, що явно не
дозволено, забороняється
 Android включає SELinux та відповідну політику безпеки для компонентів в AOSP
 Заборонені дії запобігаються, а всі спроби порушень реєструються за допомогою
інструментів Linux: dmesg друкує буфер повідомлень ядра, а logcat — це
інструмент командного рядка, який вивантажує журнал системних повідомлень
 З архітектурою системи Android, SELinux використовується для забезпечення
розділення між фреймворком Android та компонентами постачальника,
специфічними для пристрою, так що вони працюють у різних процесах і
взаємодіють між собою через набір дозволених інтерфейсів постачальників,
реалізованих як шари абстракції апаратури (HAL)

Фільтр Seccomp
 У поєднанні з SELinux Android використовує
Seccomp для подальшого обмеження доступу до
ядра, блокуючи доступ до певних системних
викликів
 Починаючи з Android 7.0, Seccomp застосовувався до
процесів у медіа-фреймворках
 Починаючи з Android 8.0, фільтр Seccomp застосовується
до всіх програм, застосовуючи білий список дозволених
системних викликів
 Програми можуть додатково забезпечити власний
фільтр seccomp для подальшого зменшення
набору дозволених системних викликів

Права доступу Unix
 Android використовує права доступу
Linux/Unix для подальшої ізоляції ресурсів
програм
 Android призначає унікальний ідентифікатор
користувача (UID) кожній програмі та
запускає кожного користувача в окремому
процесі
 За замовчуванням програми не можуть
отримувати доступ до файлів або ресурсів
одна одної так само, як різні користувачі в
Linux ізольовані один від одного
Anti-exploitation
 Android пропонує захист від експлуатації, такий
як Control Flow Integrity і Integer Overflow
Sanitization
 На основі компілятора були додані нові
зменшення загроз, щоб ускладнити
використання помилок та запобігти
перетворенню певних класів помилок у
вразливості
 Це розширює зменшення загроз, що існують,
компілятором, який спрямовує операції часу
виконання на безпечне переривання процесів,
коли виникає невизначена поведінка
Конфіденційність користувачів
та даних 1/2
 Захист конфіденційності користувачів є фундаментальним для Android
 В ОС Android 9.0 основні аспекти конфіденційності включили:
 обмеження доступу фонових програм до сенсорів пристроїв,
 обмеження інформації, отриманої при скануванні Wi-Fi,
 нові правила дозволів та групи дозволів, пов’язані з телефонними дзвінками, станом
телефону та сканування Wi-Fi
Ці зміни стосуються всіх програм, що працюють на Android 9, незалежно
від цільової версії SDK
 Android 10 розширює конфіденційність та засоби керування, які
користувачі мають над даними та можливостями програм
 Загалом вони надають користувачам та ІТ-адміністраторам кращу ясність щодо того, як
можна отримати доступ до даних та розташування користувачів
 Розробникам рекомендується забезпечити, щоб їх програми відповідали
останнім змінам конфіденційності
 Android 10 встановлює обмеження на доступ до даних та ідентифікаторів
системи, доступ до інформації про камери та мережі та вносить кілька змін
до моделі дозволів

Конфіденційність користувачів
та даних 2/2
 Робочий профіль створює окремий автономний профіль на
пристроях Android, який ізолює корпоративні дані від
особистих програм та даних
 Це можна додати до персональних пристроїв у налаштуваннях BYOD або
на корпоративному пристрої, що використовується як для роботи, так і для
особистих цілей
 За допомогою цього окремого профілю особисті програми та дані
користувача не підпадають під контроль ІТ
 Для забезпечення чіткої видимості користувача, коли робочий профіль
застосовується до пристрою, DPC представляє умови використання та
деталізує дані, які фіксуються та записуються
 Користувач повинен переглянути та прийняти ліцензійну угоду
користувача для налаштування робочого профілю
 Користувачі можуть переглянути налаштування робочого
профілю через Налаштування --> Облікові записи (Settings -->
Accounts)

Обмеження доступу до
ідентифікаторів пристрою
 Пристрої, що працюють під управлінням Android
8.0 і новіших версій, використовують випадкові
MAC-адреси при зондуванні нових мереж, якщо в
даний час вони не пов’язані з мережею
 На Android 9.0 пристрій може використовувати
рандомізовану MAC-адресу під час підключення
до мережі Wi-Fi, якщо це дозволено опцією
розробника
 В Android 10 система передає рандомізовані MAC-
адреси за умовчанням
 Крім того, доступ до IMEI пристрою та серійних
номерів неможливий
Location control
 Програми можуть надавати відповідну інформацію користувачеві,
використовуючи API розташування
 Наприклад, якщо програма допомагає користувачеві орієнтуватися на маршруті доставки, їй
потрібно постійно отримувати доступ до місця розташування пристрою, щоб надати потрібну
допомогу
 Розташування корисно в багатьох сценаріях — Android надає розробникам
інструменти для запиту необхідних дозволів, одночасно надаючи
користувачам можливість вибору, що саме вони дозволяють
 Програми, які використовують служби локації, повинні запитувати дозволи на
отримання розташування, щоб користувач мав видимість і контроль над цим
доступом
 В Android 10 користувачі бачать діалогове вікно, що повідомляє їх про те, що
програма бажає отримати доступ до їх розташування
 Цей запит може бути на доступ лише під час використання програми або постійно
 Користувач може дозволити програмі постійний доступ до місця розташування пристрою
 Коли програма звертається до місця розташування пристрою у фоновому режимі вперше після
того, як користувач зробив такий вибір, система планує надіслати користувачеві повідомлення
 Це сповіщення нагадує користувачеві, що він дозволив програмі постійно отримувати доступ до
місцезнаходження пристрою

Доступ до зовнішнього
сховища
 Щоб надати користувачам більше контролю над своїми
файлами та обмежити захаращення файлами, програмам,
орієнтованим на Android 10 і новіших версій, за
замовчуванням надається обмежений доступ до
зовнішнього пристрою зберігання даних
 Такі програми можуть бачити лише свій каталог для конкретної
програми, доступ до якого здійснюється за допомогою
Context.getExternalFilesDir(), а також певні типи носіїв
 Розробникам рекомендується використовувати такий
доступ як найкращу практику
 Адміністратори EMM можуть не дозволяти користувачам
своєї організації отримувати доступ до зовнішнього
сховища, такого як SD-карта, підключена до їх пристрою,
щоб додатково зменшити потенціал будь-якої втрати даних

Обмежений доступ до
фонових сенсорів
 Android 9.0 обмежує можливість фонових програм
отримувати доступ до даних користувача та даних
сенсора
 Якщо програма працює у фоновому режимі на пристрої
під управлінням Android 9.0 і новіших версій, система
застосовує до програми такі обмеження:
 Програма не може отримати доступ до мікрофона або камери
 Сенсори, які використовують режим безперервної звітності, такі як
акселерометри та гіроскопи, не отримують подій
 Сенсори, які використовують режими звітності "за зміни" або "один
знімок", не отримують подій
 Якщо програмі потрібно виявляти події сенсорів на
пристроях з ОС Android 9.0, вона повинна
використовувати службу переднього плану (foreground)
Режим блокування
(Lockdown mode)
 Користувач може ввімкнути функцію блокування, щоб
додатково обмежити доступ до пристрою
 Цей режим демонструє опцію кнопки живлення, яка
вимикає Smart Lock, біометричне розблокування та
сповіщення на екрані блокування
 Його можна ввімкнути через Налаштування -->
Налаштування екрану блокування --> Режим
блокування (Settings --> Lock screen preferences -->
Lockdown mode)
 Адміністратори підприємства можуть віддалено
заблокувати робочий профіль і вилучити ключ
шифрування з пам'яті на корпоративних пристроях,
використовуючи цю можливість
Безпека мережі
 На додаток до захисту даних у стані спокою — захисту
інформації, що зберігається на пристрої — Android забезпечує
мережну безпеку для захисту даних під час передачі даних,
що надсилаються на пристрої Android та з них
 Android забезпечує безпечний обмін через Інтернет для
перегляду веб-сторінок, електронної пошти, обміну миттєвими
повідомленнями та інших Інтернет-програм, підтримуючи
безпеку транспортного рівня (Transport Layer Security — TLS)
 DNS over TLS (Android 9.0 та вище)
 TLS за умовчанням
 Wi-Fi
 VPN
 Обробка сертифікатів

DNS over TLS
 Android 9.0 і вище включає
вбудовану підтримку DNS через
TLS
 Користувачі або адміністратори можуть
увімкнути режим приватного DNS у
налаштуваннях мережі та Інтернету
 Android 10 розширює можливості
адміністраторів для запобігання
змінам налаштувань DNS
користувачами, запобігаючи
витоку запитів DNS
 Пристрої автоматично
переходять на DNS через TLS,
якщо настроєний DNS-сервер
підтримує його, але користувачі
можуть вимкнути його, якщо
захочуть

TLS за умовчанням
 Android допомагає захистити дані, захищаючи мережний трафік, який надходить
або виходить із пристрою, підтримуючи безпеку транспортного рівня (Transport
Layer Security — TLS)
 В ОС Android 9.0 і новіших версій Конфігурація безпеки мережі за умовчанням
блокує весь трафік з відкритим текстом (незашифрований HTTP)
 Розробники повинні явно ввімкнути певні домени, щоб використовувати трафік з відкритим
текстом у своїх програмах
 Android Studio також попереджає розробників, коли їхня програма містить потенційно небезпечну
конфігурацію безпеки мережі
 Щоб запобігти випадковому незашифрованому з'єднанню, атрибут маніфесту
android: usesCleartextTraffic дозволяє програмам вказувати, що вони не мають
наміру надсилати мережний трафік без шифрування
 Android 10 використовує TLS 1.3 за умовчанням для всіх з'єднань TLS
 TLS 1.3 — це суттєвий перегляд стандарту TLS з перевагами продуктивності та підвищеною
безпекою
 TLS 1.3 також є більш конфіденційним, оскільки він шифрує більшу частину процесу
рукостискання та пропонує посилену безпеку, більше не підтримуючи сертифікати, підписані за
допомогою SHA 1
 Тестування швидкодії свідчать, що за допомогою TLS 1.3 захищені з'єднання можна встановити
на 40 відсотків швидше порівняно з TLS 1.2

Wi-Fi 1/2
 Android 10 підтримує стандарти Wi-Fi Alliance Wi-Fi Protected
Access версії 3 (WPA3) та Wi-Fi Enhanced Open
 WPA3 та Wi-Fi Enhanced Open покращують загальну безпеку Wi-Fi,
забезпечуючи кращу конфіденційність та стійкість (robustness) проти
відомих атак
 WPA3 — це новий стандарт безпеки WFA для персональних та
корпоративних мереж, що використовує сучасні алгоритми
безпеки та надійніші набори шифрів
 WPA3 має дві частини: персональну та корпоративну
 WPA3-Enterprise пропонує більш ефективні методи автентифікації та
шифрування на канальному рівні та додатковий 192-розрядний режим
безпеки для чутливих середовищ безпеки
 WPA3-Personal використовує одночасну автентифікацію рівних
(Simultaneous Authentication of Equals — SAE) замість спільного ключа
(Pre-shared Key — PSK), забезпечуючи користувачам більш надійний
захист від таких атак, як offline атаки за словником, відновлення ключів та
підробка повідомлень
Wi-Fi 2/2
 Wi-Fi Enhanced Open — це новий стандарт безпеки WFA для
загальнодоступних мереж, заснований на “опортуністичному” бездротовому
шифруванні (Opportunistic Wireless Encryption — OWE)
 Він забезпечує шифрування та конфіденційність у відкритих мережах, не захищених паролем,
у таких місцях як кафе, готелі, ресторани та бібліотеки
 Enhanced Open не забезпечує автентифікацію
 Android також підтримує протокол WPA2-Enterprise (802.11i), розроблений для
корпоративних мереж, і може бути інтегрований у широкий спектр серверів
автентифікації служби віддаленої автентифікації (Remote Authentication Dial-In
User Service — RADIUS)
 Підтримка протоколу WPA2-Enterprise використовує шифрування з автентифікацією AES-
128-CCM
 В Android 10 QR-коди та дані NFC, що використовуються для авторизації
пристрою, можуть містити конфігурацію та облікові дані розширеного
протоколу автентифікації (Extensible Authentication Protocol — EAP),
включаючи сертифікати
 Коли особа сканує QR-код або натискає тег NFC, пристрій автоматично автентифікується у
локальній мережі Wi-Fi за допомогою EAP і запускає процес авторизації без додаткового
введення вручну

VPN 1/2
 Android підтримує безпечне підключення до корпоративної мережі
за допомогою VPN: Always-on VPN, Per User VPN, Per Application VPN
 Постійно ввімкнена VPN (Always-on VPN) — VPN можна налаштувати
так, щоб програми не мали доступу до мережі, доки не буде
встановлено VPN-з'єднання, що перешкоджає програмам надсилати
дані через інші мережі
 В ОС Android 7.0 і вище, Always-on VPN підтримує клієнтів VPN, які реалізують
VpnService. Система автоматично запускає VPN після завантаження пристрою
 Завжди ввімкнену VPN можна активувати для програм у корпоративному
середовищі за допомогою DevicePolicyManager#setAlwaysOnVpnPackage
 Власники пристроїв та власники профілів можуть вимагати, щоб робочі програми
завжди підключалися через зазначену VPN
 Крім того, користувачі можуть вручну налаштувати постійні клієнти VPN, які
реалізують методи VpnService, використовуючи Settings --> More --> VPN
 Можливість увімкнути Always-on VPN у налаштуваннях доступна, лише якщо
клієнт VPN націлений на рівень API 24 або вище

VPN 2/2
 VPN для кожного користувача (Per User VPN) — на
багатокористувацьких пристроях VPN застосовуються для кожного
користувача Android, тому весь мережний трафік маршрутизується
через VPN, не зачіпаючи інших користувачів пристрою
 VPN застосовуються до кожного робочого профілю, що дозволяє ІТ-адміністратору
вказати, що через корпоративну мережу VPN-профілю проходить лише їхній
мережний трафік підприємства, а не особистий мережний трафік користувача
 VPN для кожної програми (Per Application VPN) — Android 5.0
впровадила підтримку для забезпечення VPN-з'єднань у дозволених
програмах та для запобігання VPN-з'єднанням у заборонених
програмах
 В Android 10 програми VPN можуть встановлювати проксі HTTP для
свого VPN-з'єднання
 Перед викликом VpnService.Builder.setHttpProxy() програма VPN має
налаштувати екземпляр ProxyInfo з хостом і портом
 Система та багато мережних бібліотек використовують ці налаштування проксі-
сервера, але система не змушує програми надсилати через проксі запити HTTP

Режими сервісу VPN
 Тепер програми VPN також можуть виявити, чи сервіс працює через
постійно ввімкнену VPN та чи активний режим блокування (Lockdown
mode)
 Нові методи, додані в Android 10, можуть допомогти розробникам
налаштувати інтерфейс користувача
 Наприклад, розробники можуть вимкнути кнопку відключення з’єднання в програмі
VPN, коли постійно ввімкнена VPN контролює життєвий цикл сервісу
Режими блокування VPN

 Режими блокування дозволяють адміністраторам блокувати
мережний трафік, який не використовує VPN, і звільняти програму,
що дозволяє їй використовувати будь-яку доступну мережу, якщо
мережа VPN відключена або недоступна
 Адміністратори також можуть явно заборонити доступ до всіх мереж для
програми, і це дозволяє лише спілкуватися через VPN

Користування сертифікатами
 Починаючи з ОС Android 7.0, усі нові пристрої мають поставлятися з одним і
тим самим сховищем центру сертифікації (ЦС)
 Центри сертифікації є важливою складовою інфраструктури відкритих ключів,
яка використовується для створення безпечних сеансів зв'язку за допомогою
TLS
 Визначення надійних центрів сертифікації, а зрештою, які цифрові сертифікати, підписані
певним ЦС, є надійними — має вирішальне значення для безпечного спілкування через мережу
 Цей захист додатково покращується шляхом запобігання програмам, націленим
на Android 9.0, дозволяти незашифровані з'єднання за умовчанням
 Це слідує за різними змінами, зробленими роками для кращого захисту користувачів Android
 В ОС Android 7.0 та вище сумісні пристрої довіряють лише стандартизованим
системним ЦС, що підтримуються в AOSP
 Прикладні програми також можуть довіряти ЦС, доданим користувачами або адміністраторами
 Довіру можна призначити всій програмі або лише для підключення до певних доменів
 Коли потрібні центри сертифікації для конкретного пристрою, наприклад,
програма-оператор, якій потрібен безпечний доступ до компонентів
інфраструктури оператора (наприклад, шлюзи SMS/MMS), ці програми можуть
включати приватні центри сертифікації до самих компонентів/програм

Безпека прикладних
програм
 Прикладні програми є невід’ємною частиною будь-якої мобільної
платформи, і користувачі все більше покладаються на мобільні прикладні
програми для вирішення основних завдань продуктивності та спілкування
 Android надає декілька рівнів захисту програм, що дозволяє користувачам
завантажувати програми для роботи чи особистого користування на свої
пристрої, не забуваючи, що вони отримують високий рівень захисту від
шкідливого програмного забезпечення, експлойтів та атак
 Підписування програм — Android вимагає, щоб перед встановленням усі програми мали
цифровий підпис ключем розробника
 Дозволи для програм — центральний момент проектування архітектури безпеки Android
полягає в тому, що жодна програма за умовчанням не має дозволу виконувати будь-які
операції, які негативно впливають на інші програми, операційну систему або користувача
 Google Play Protect — Постійно активна служба вбудована в усі пристрої, які мають
Google Play, і захищає понад 2,5 мільярда пристроїв
 Перевірка програм Google Play — перед тим, як програми стануть доступними в Google
Play, вони проходять процес розгляду програм (review), щоб підтвердити їх відповідність
політиці Google Play
 SafetyNet — набір служб та API, які розробники можуть використовувати для захисту
програм від загроз безпеці

Підписування програм
 Android вимагає, щоб перед встановленням усі програми мали цифровий
підпис ключем розробника
 Ротація ключів APK, що підтримується в Android 9.0, дає програмам можливість
змінювати ключ підпису в рамках оновлення APK
 Для підтримки ротації ключів схему підпису APK оновлено з v2 до v3, щоб дозволити
використовувати старі та нові ключі
 Android використовує відповідний сертифікат для ідентифікації автора
програми
 Коли система встановлює оновлення для програми, вона порівнює сертифікат у новій
версії з сертифікатом у версії, що встановлена, та дозволяє оновлення, якщо сертифікат
відповідає
 Android дозволяє програмам, підписаним тим самим ключем, працювати
в одному процесі, якщо програми цього вимагають, так що система
розглядає їх як єдину програму
 Android забезпечує застосування дозволів на основі підписів, щоб програма могла
відкрити функціональність іншій програмі, підписаній тим самим ключем
 Підписуючи кілька програм одним і тим же ключем і використовуючи дозволи на основі
підписів, програма може безпечно ділитися кодом та даними

Дозволи для програм 1/2
 Дозволи захищають конфіденційність користувачів Android і
забезпечують прозорість щодо того, до яких ресурсів чи
інформації програми хочуть отримати доступ
 Щоб програми мали доступ до системних функцій, таких як камера та
Інтернет, або до даних користувача, таких як контакти та SMS, програма
Android має явно запитувати дозвіл
 Ці запити на дозвіл розроблені таким чином, щоб користувач мав чітке
розуміння запиту та можливість його схвалити або відхилити
 Центральним моментом архітектури безпеки Android є те, що
жодна програма за умовчанням не має дозволу на виконання
будь-яких операцій, які негативно впливають на інші
програми, операційну систему чи користувача
 Це включає читання або записування особистих даних користувача
(наприклад, контактів чи електронних листів), читання або записування
файлів іншої програми, виконання доступу до мережі, утримання
пристрою від режиму сну та ін.

Дозволи для програм 2/2
 Програми, націлені на рівень API 23 (Android 6.0) і вище, використовують
дозволи під час виконання
 Ці діалогові вікна вимагають від користувача надання доступу до зазначеного дозволу
 Цей підхід спрощує процес встановлення та оновлення програми, оскільки користувачеві не
потрібно надавати дозволи під час встановлення або оновлення програми
 Це також дає користувачеві більший контроль над функціональністю програми; наприклад,
користувач міг би надати програмі камери доступ до камери, але не до розташування
пристрою
 Користувачі можуть відкликати дозволи в будь-який час, навіть якщо програма націлена на
нижчий рівень API
 Android 8.0 і вище також включають вдосконалення, що дають користувачам
кращий контроль над використанням ідентифікаторів
 Стійкі ідентифікатори пристроїв, які впливають на конфіденційність, або більше недоступні,
або закриті за дозволом під час виконання
 Наприклад, API, які мають доступ до MAC-адреси Wi-Fi, були видалені, за винятком повністю
керованих пристроїв
 На корпоративних пристроях програми керування пристроями (DPC) можуть
відмовляти у дозволах від імені користувача за допомогою
setPermissionPolicy API, функції керованої Google Play

Google Play Protect
 Google Play Protect (Захист Google Play) — це потужна служба
виявлення загроз, яка активно контролює пристрій для захисту
його, його даних та програм від шкідливого програмного
 Постійно активна служба вбудована в усі пристрої, які мають Google Play, і
захищає понад 2,5 мільярда пристроїв
 Служба Google Play Protect Verify Apps раз на день перевіряє
пристрої на наявність шкідливої поведінки або ризиків для
безпеки
 Якщо ця служба виявляє програму, що містить шкідливе програмне
забезпечення, вона сповіщає користувача
 Google Play Protect також може автоматично видаляти або вимикати шкідливі
програми в рамках своєї ініціативи запобігання та використовувати зібрану
інформацію для покращення виявлення потенційно шкідливих програм
(Potentially Harmful Applications — PHA)
 Крім того, користувач може вибрати опцію, щоб невідомі програми надсилалися
в Google для аналізу

Перевірка програм
Google Play 1/2
 Play Store має політику щодо захисту користувачів від зловмисників, які
намагаються поширювати PHA
 Розробників перевіряють у два етапи
 Вони вперше перевіряються, коли вони створюють свій обліковий запис розробника
на основі їхнього профілю та кредитних карт
 Потім розробники перевіряються з використанням додаткових сигналів після
надсилання програми
 Перш ніж програми стануть доступними в Google Play, вони проходять
процедуру перевірки (review), щоб підтвердити їх відповідність політиці
Google Play
 Google розробила автоматизований аналізатор ризиків програм, який виконує
статичний та динамічний аналіз файлів .apk для виявлення потенційно шкідливої
поведінки програм
 Коли аналізатор ризиків у програмах (Google’s application risk analyzer) виявляє
щось підозріле, він позначає програму, яка порушує правила, і передає її аналітику з
питань безпеки для перевірки вручну
 Google призупиняє облікові записи розробників, які порушують програмну політику
розробників

Перевірка програм
Google Play 2/2
 Розробника негайно повідомляють, якщо його програму відмічено через
проблему безпеки
 Вони отримують подробиці про те, як покращити програму, і посилання на деталі сторінки
підтримки для отримання додаткових вказівок
 Це сповіщення зазвичай містить терміни доставки покращення
 У деяких випадках необхідно покращити безпеку програм, перш ніж розробник зможе
публікувати будь-які подальші оновлення
 Ще одним ключовим елементом мінімізації ризику є використання
оновлених API
 Заохочення розробників використовувати найновіші API підтримує підтримку найновіших
функцій, створюючи оптимальну безпеку та продуктивність
 Щоб відповідати вимогам API, нові програми та їх оновлення мають бути націлені
принаймні на Android 9.0 або на рівень API 28
 Кожна нова версія Android вносить зміни, які приносять значні поліпшення
безпеки та продуктивності — та покращують загальний досвід користування
Android
 Деякі з цих змін стосуються лише програм, які явно заявляють про підтримку через атрибут
маніфесту targetSdkVersion, також відомий як цільовий рівень API (target API level)

SafetyNet 1/2
 SafetyNet — це набір служб та API, які розробники можуть використовувати для
захисту програм від загроз безпеці
 Вони можуть пом'якшити втручання в пристрої, неправильні URL-адреси, PHA та підроблених
 SafetyNet Attestation API — це API проти зловживань, який дозволяє розробникам
програм оцінювати пристрій Android, на якому працює їхня програма
 Цей API забезпечує криптографічно підписану атестацію, що оцінює цілісність пристрою
 Щоб створити атестацію, API вивчає програмне та апаратне середовище пристрою, шукає проблеми
цілісності та порівнює їх із довідковими даними для затверджених пристроїв Android
 Згенерована атестація пов'язана з нонсом, який програма надає
 Атестація також містить позначку часу генерації та метадані про програму, що атестацію запросила
 SafetyNet Safe Browsing API пропонує послуги для визначення того, чи URL-адреса
була позначена Google як відома загроза
 SafetyNet реалізує клієнта для Мережного протоколу безпечного перегляду v4 (Safe Browsing Network
Protocol v4), розробленого Google
 І клієнтський код, і мережний протокол v4 були розроблені для збереження конфіденційності
користувачів та мінімізації споживання акумулятора та пропускної здатності
 Розробники можуть використовувати цей API, щоб у повній мірі скористатися перевагами служби
безпечного перегляду Google на Android найбільш оптимізованим для ресурсів способом і без
реалізації мережного протоколу

SafetyNet 2/2
 Сервіс SafetyNet також містить SafetyNet reCAPTCHA API, який
захищає програми від шкідливого трафіку
 Цей API використовує вдосконалений механізм аналізу ризиків для захисту
програм від спаму та інших образливих дій
 Якщо служба підозрює, що користувач, який взаємодіє з програмою, може
бути ботом, а не людиною, він надає CAPTCHA, яку людина повинна
вирішити, перш ніж програма зможе продовжувати виконання
 SafetyNet Verify Apps API дозволяє програмі взаємодіяти
програмно з Google Play Protect, щоб перевірити, чи не
встановлені відомі потенційно шкідливі програми
 Якщо програма обробляє конфіденційні дані користувача, наприклад
фінансову інформацію, розробники повинні підтвердити, що поточний пристрій
захищений від шкідливих програм і вільний від програм, які можуть видавати
себе за нього або виконувати інші шкідливі дії
 Якщо безпека пристрою не відповідає мінімальній позиції безпеки, розробники
можуть вимкнути функціональні можливості програми, щоб зменшити
небезпеку для користувача

Захист даних
 Android використовує провідні в галузі функції безпеки для захисту
 Платформа надає інструменти та послуги для розробників, які
допомагають забезпечити конфіденційність, цілісність та доступність
 Шифрування
 Шифрування на основі файлів — Дозволяє шифрувати області зберігання різними ключами
та доступна для використання на пристроях починаючи з Android 7.0
 Повне дискове шифрування — Пристрої з ОС Android 5.0 до 9.0 можуть використовувати
шифрування повного диска замість шифрування на основі файлів
 Шифрування резервних копій — Пристрої під управлінням Android 9.0 і новіших версій
тепер можуть підтримувати покращене шифрування резервних копій
 Оновлення безпеки Android
 Оновлення партнерів OEM
 Оновлення системи Google Play
 Conscrypt — модуль Conscrypt прискорює покращення безпеки
 Adiantum — метод шифрування, призначений для пристроїв з ОС Android 9.0 і
вище, процесори яких не мають інструкцій AES

Підсумок щодо безпеки
операційних систем
Основні функції безпеки сучасних
 Криптографічні функції (FIPS — approved)
 Цілісність комплексу засобів захисту
 Безпечне завантаження системи
 Перевірка цілісності і підпису коду усіх компонентів під час
завантаження
 Власний домен КЗЗ
 Контроль цілісності (автоматичне відновлення) важливих
 Програмні та апаратні привілеї, засновані на можливостях
процесора
 Підтримка рівня виконання (щонайменше режим ядра та режим
користувача)
 Апаратна підтримка віртуалізації

 Ідентифікація та автентифікація
 Захист даних користувача
 Дискреційне керування доступом
 Біти дозволів
 Списки керування доступом
 Можливості (capabilities) програм
 Мандатне керування доступом
 Відповідність типів і доменів
 Багаторівнева безпека (MLS)
 Клієнти VPN
 Шифрування файлів та(або) дисків
 Безпека прикладних програм
 Власний домен і контекст виконання
 Sandboxing, Контейнеризація, Віртуалізація
 Перевірка програм та їх оновлень, поширення через
магазин прикладних програм
 Виявлення потенційно шкідливих програм
(вбудований антивірус, постійний мережний сервіс)
 Шкідливого коду
 Підозрілої поведінки
 Безпека оновлень
 Захищений інсталятор
 Захист від уразливостей програмного коду
 Рандомізація адресного простору (ASLR)
 Захист від виконання даних (DEP)
 Захист від переповнення буферу в стеку
 Безпека мережі
 Крипто-захищений обмін (TLS, SSH, IPSec)
 Захист роботи в Інтернеті
 Захищений DNS
 HTTPS over TLS
 Чорні та білі списки URL
 Система реєстрації та аудиту

Безпека
систем
Лекція 15-16. Підтримка засобів захисту операційних систем
процесорами x86

Завдання апаратного
забезпечення засобів захисту
 За усталеною термінологією склад АЗЗЗ
визначається не за ознакою апаратної реалізації, а за
колом завдань, що вирішуються:
 підтримка керування пам’яттю;
 підтримка керування процесами (завданнями);
 підтримка взаємодії між процесами.
 АЗЗЗ не забезпечують виконання завдання повністю,
а лише надають необхідну підтримку
 Як правило, АЗЗЗ виконують такі функції, як доступ
до об’єктів, перевірки, переключення, а реалізація
складних алгоритмів, які здійснюють планування
таких функцій, виноситься за межі апаратних засобів
Безпека ОС - Лекція 15-16 2/41

Підтримка керування
процесами (завданнями)
 У сучасних ОС до завдань керування процесами входять такі:
 створення і знищення процесів;
 забезпечення процесів необхідними ресурсами;
 планування і диспетчеризація процесів (розподіл процесорного часу між
процесами);
 підтримка взаємодії між процесами.
 Створення, знищення і планування процесів реалізується
програмно, а диспетчеризація процесів – з інтенсивним
застосуванням апаратних засобів
 Функції захисту, які реалізуються безпосередньо засобами
планування і диспетчеризації процесів:
 контроль виділення процесам процесорного часу з метою запобігання
перевищення квот або монополізації процесору;
 контроль за викликами одними процесами інших з метою забезпечення
встановлених правил доступу.

Контроль за викликами процесів:
дискреційне керування доступом
 Дискреційне керування:
 У дескрипторі процесу повинна бути передбачена область
даних, яка визначає права доступу інших процесів на запуск,
зміну стану, зміну пріоритету, знищення цього процесу, або інші
дії, які можуть бути виконані над дескриптором процесу в той
час, коли сам процес не знаходиться у стані виконання
 Права доступу можуть визначатись списком керування доступу
 Список керування доступом є порівняно великою структурою, і
роботу з ним важко організувати на апаратному рівні
 Процесори, у тому числі архітектури Intel x86, не
реалізовують підтримку дискреційного керування
доступом
 Ці функції реалізуються ОС програмно

Контроль за викликами процесів:
мандатне керування доступом
 Реалізація мандатного керування доступом у цьому випадку є значно
простішою і ефективнішою, і легко досягається апаратними засобами
 Кожному процесу надається деякий рівень виконання, який визначається цілим
числом
 Таким чином утворюються так звані кільця захисту
 У найпростішому випадку процеси з нижчим рівнем виконання не мають доступу до
виклику програмного коду, якому присвоєний вищий рівень виконання, а також до
пов’язаних з таким кодом структур даних
 Якщо кільця захисту реалізуються апаратно, то максимальна їх кількість
визначається архітектурою центрального процесора
 Більшість RISC процесорів підтримує лише два рівня виконання процесів, тобто
два кільця захисту:
 рівень ядра (kernel mode)
 рівень користувача (user mode), або рівень прикладних програм
 Процесори Intel x86 (починаючи з 80286) підтримують чотири кільця
захисту, і існують деякі ОС, що повністю використовують цю
можливість

Регістри сегментів
процесорів х86
Позна- Назва Особливості використання
чення
сегмент коду адресує сегмент коду, який виконується процесором

(Code Для переходу в інший сегмент коду необхідно завантажити
cs Segment нове значення в регістр cs, причому явних команд для цього
register) не існує: це здійснюється автоматично при виконанні
процесором команд jmp або call.
сегмент стека адресує сегмент стека, з яким в даний момент працює

(Stack процесор
ss Segment Для організації іншого стека необхідно завантажити в ss нове
register) значення, при цьому необхідно зберегти поточне значення
ss, щоби мати змогу повернутись назад.
сегмент даних адресує дані в оперативній пам’яті, з якими працює
ds (Data Segment процесор
register) Сегмент ds є основним, і адресується неявно.
додаткові
es, сегменти адресують дані в оперативній пам’яті, з якими працює
gs, даних процесор
fs (Extension Ці сегменти даних вимагають явної адресації за допомогою
Data Segment спеціальних префіксів в командах.
register)
Регістри системних адрес
Позна- Назва Особливості використання
чення
регістр глобальної має 48 розрядів

таблиці
gdtr дескрипторів (Global 32 адресу
старших розряди представляють лінійну базову
глобальної таблиці дескрипторів у пам’яті
Descriptor Table 16 молодших розрядів задають розмір таблиці
Register)
регістр локальної 16-розрядний регістр, що містить селектор, який
таблиці вказує на дескриптор в глобальній таблиці, який
ldtr дескрипторів описує спеціальний сегмент – локальну таблицю
(Local Descriptor дескрипторів процесу, який виконується в даний
Table Register) момент
регістр таблиці
дескрипторів 48-розрядний регістр, за будовою аналогічний регістру
idtr переривань gdtr
(Interrupt Descriptor
Table Register)
16-розрядний регістр, що містить селектор, який
регістр задачі вказує на дескриптор в глобальній таблиці, який
tr (Task Register) описує спеціальний сегмент – сегмент стану
завдання (TSS), який містить контекст поточного
процесу
Регістри керування
містить прапорці, які суттєво впливають на роботу процесора і
відображають глобальні (незалежні від конкретної задачі) ознаки його
функціонування
cr0 Деякі важливі системні прапорці з цього регістру:
pe (Protect Enable), біт 0 – вмикає захищений режим роботи процесора;
cd (Cache Disable), біт 30 – вмикає використання внутрішньої кеш-пам’яті (кеш
першого рівня);
pg (Paging), біт 31 – вмикає сторінкову трансляцію адрес.
призначений для роботи сторінкового механізму віртуальної пам’яті

Містить лінійну віртуальну адресу команди, яка викликала виняткову ситуацію
cr2 14 – відсутність сторінки у пам’яті
Обробник цієї виняткової ситуації після завантаження необхідної сторінки у
пам’ять має змогу відновити нормальну роботу програми, передавши
керування на адресу з cr2
cr3 призначений для роботи сторінкового механізму віртуальної пам’яті

Містить фізичну базову адресу каталогу сторінок
містить прапорці-ознаки підтримки різних архітектурних елементів, що

cr4 впроваджувались у різних моделях процесорів
Наприклад, підтримка 36-розрядної адресації, підтримка 4-мегабайтних
сторінок тощо
Реалізація кілець захисту в
процесорах x86
 Кільця захисту реалізуються через рівень привілеїв виконуваного
коду, а також даних і стеку
 Рівень привілеїв призначається шляхом присвоювання значення від 0 до 3
певним об’єктам, що визнаються процесором
 Для цього у цих об’єктах мають бути виділені по два біти
 Нижчезазначені об’єкти, які визнає процесор, містять рівні
привілеїв:
 Дескриптори [сегментів пам’яті] містять поле, що називається рівень
привілеїв дескриптора — descriptor privilege level (DPL)
 Селектори (об’єкти, які завантажують у сегментні регістри процесора, і які
вказують на певний дескриптор) містять поле, що називається рівень
привілеїв запитувача — requestor’s privilege level (RPL)
 RPL має представляти рівень привілеїв процедури, з якої походить селектор
 Внутрішній регістр процесора зберігає поточний рівень привілеїв — current
privilege level (CPL)
 Типово, CPL дорівнює DPL сегмента коду, який процесор виконує у поточний момент
 CPL змінюється тоді, коли керування передається сегментам коду з іншим DPL

Структура селектора
(32-розрядна архітектура)
15 3 2 1 0
Індекс TI RPL
13 1 2
 Селектор сегмента (16 розрядів)

 13 старших розрядів селектора є індексом в таблиці
дескрипторів
 Таким чином, кожна таблиця може містити 213=8192 дескрипторів
 Один розряд селектора (біт 2), вказує в якій з таблиць
знаходиться дескриптор:
 TI=0 —> GDT, TI=1 —> LDT
 2 розряди селектора (біти 1,0) відведені для задавання рівня
привілеїв запитувача (Requestor’s Privilege Level, RPL)

Структура дескриптора
(32-розрядна архітектура)
63 56 55 54 53 52 51 48 47 40 39 32
base_3 (31-24) G D O U limit_2 байт AR base_2 (23-16)
31 16 15 0
base_1 (15-0) limit_1 (15-0)
 Дескриптор сегмента (64 розряди)

 Головні поля дескриптора:
 32-розрядна базова адресу (base)
 20-розрядна межа сегмента (limit)
7 (47) 6 (46) 5 (45) 4 (44) 3 (43) 2 (42) 1 (41) 0 (40)

P DPL S E C/ED R/W A
type_seg
 Байт захисту (AR), що, зокрема, містить DPL

Керування завданнями у
процесорах Intel x86
 Процесори i386 надають засоби для підтримки виклику процедур і
виклику завдань
 Виклик процедури – це виклик коду в межах одного процесу (потоку)
 При цьому відбувається переключення на інший сегмент коду, але зберігаються
структури, які керують адресним простором процесу (таблиця LDT, таблиця сторінок)
 Виклик завдання – це створення нового процесу з усіма відповідними
структурами (що є здебільшого роботою ОС) і переключення на цей
процес
 Виклик завдання також відбувається у багатозадачній ОС при
переключенні між процесами
 У цьому випадку необхідні структури вже створені, але необхідно здійснити
переключення на них, забезпечивши збереження відповідних структур поточного
процесу
 В усіх способах викликів використовується захист, що оснований на
рівнях привілеїв

Виклик процедур
 Під час роботи будь-якого програмного коду у сучасних ОС постійно виникає
необхідність виклику процедур, код яких знаходиться в інших сегментах, що
можуть належати
 іншому програмному модулю тієї ж програми,
 бібліотеці,
 іншій прикладній програмі,
 ОС.
 Процесори i386 пропонують кілька способів виклику процедур з інших
сегментів:
 прямий виклик процедури з непідпорядкованого сегмента;
 прямий виклик процедури з підпорядкованого сегмента;
 непрямий виклик процедури через шлюз.
 Правила розмежування доступу на підставі привілеїв враховують:
 Рівні привілеїв CPL, RPL і DPL
 Підпорядкованість сегмента, що містить код процедури
 Підпорядкованість сегмента задається прапорцем C в байті захисту дескриптора сегмента
коду:
 С = 1 – підпорядкований сегмент,
 С = 0 – непідпорядкований сегмент.

Прямий виклик процедури з
непідпорядкованого сегмента
 Такий спосіб полягає у розміщенні в полі команди JMP або CALL селектора,
який вказує на дескриптор нового кодового сегмента
 Початкова адреса (точка входу) процедури визначається з базової адреси
сегмента, яка знаходиться у дескрипторі, і зміщення, безпосередньо
заданого у команді JMP або CALL
 Для такого виклику встановлені жорсткі правила захисту: якщо сегмент,
який викликають, є непідпорядкованим, то виклик дозволено тоді і лише
тоді, коли рівень привілеїв сегмента, з якого робиться виклик, дорівнює
рівню привілеїв сегмента, який викликають, тобто CPL = DPL
 Виклик процедури у випадку CPL > DPL (тобто, код, що виконується, має нижчий рівень
привілеїв за код, який намагаються викликати) заборонений з очевидних міркувань захисту
критичного коду з більшими привілеями від виклику з процедур, що мають менші привілеї
 Наприклад, для захисту процедур ОС від безконтрольного виклику з процедур користувача
(безконтрольного – тому що при такому виклику можна задати будь-яку точку входу і передати через
стек будь-які параметри: контроль не передбачений)
 Виклик у випадку CPL < DPL (тобто, код, що виконується, має вищий рівень привілеїв за
код, який намагаються викликати), також забороненний
 Це обмеження введено з міркувань того, що у загальному випадку привілейований код не може
користуватись процедурами з низькими привілеями, оскільки останні вважаються ненадійними

Прямий виклик процедури з
підпорядкованого сегмента
 Виклик підпорядкованих сегментів – це один із способів, який дає змогу
програмам з низьким рівнем привілеїв використовувати код, що має високий
рівень привілеїв
 Наприклад, це може бути корисним при використанні програмами користувача системних
бібліотек або виконанні системних викликів
 Код процедури розміщається у підпорядкованому сегменті
 Виклик здійснюється аналогічно виклику процедур з непідпорядкованих
сегментів, і точки входу так само можна задавати довільно
 Дозволяється виклик при співвідношенні рівнів привілеїв CPL ≥ DPL, тобто код,
що викликає, має привілеї не вищі за той код, який викликають
 Підпорядкований сегмент має особливу властивість: код з підпорядкованого
сегмента наслідує рівень привілеїв коду, який його викликав
 В процесі виклику CPL не зміниться, яким би не був DPL підпорядкованого сегмента
 Наприклад, код системної бібліотеки, який міститься в сегменті з DPL = 0 буде виконуватись з
CPL = 0, якщо його було викликано з ядра ОС, і з CPL = 3, якщо його було викликано з програми
 Можливості, які надаються при виклику процедур з підпорядкованого сегмента, недостатні для
реалізації більшості системних викликів, оскільки при цьому часто необхідно не лише виконувати
визначений код, але й звертатись до системних даних, що вимагає відповідного рівня CPL

Непрямий виклик процедури
через шлюз
 За допомогою шлюзів реалізується механізм контрольованого
виклику процедур, які будуть виконуватись із своїм рівнем привілеїв,
можливо, вищим за той, що мав код, який здійснив виклик
 Шлюзом називається системний дескриптор спеціального виду
 Шлюз може знаходитись і в таблиці GDT, і в таблиці LDT
 Кожний шлюз призначений для виклику не сегмента коду, а окремої процедури із
сегменту
 Для виклику цієї процедури шлюз містить в собі адресу її точки входу – селектор сегмента і
зміщення
 Виклик здійснюється шляхом розміщення в полі команди JMP або CALL селектора,
який вказує на шлюз, при цьому вказане в команді зміщення не враховується
 Шлюз має свій власний DPL, який визначає можливість доступу коду до шлюзу:
повинна виконуватись умова CPL ≤ DPL, тобто привілеї коду повинні бути не
нижчими за привілеї шлюзу
 Рівень DPL сегмента того коду, який викликається через шлюз, з рівнем CPL не порівнюється,
а порівнюється із RPL селектора, що міститься у шлюзі
 В разі успішного виклику код буде виконуватись із своїм CPL, який задається DPL
сегмента

Формат шлюзу виклику
процедури і байту захисту шлюзу
63 48 47 40 39 37 36 32
offset_2 (31-16) байт AR 000 WC
31 16 15 0
selector offset_1 (15-0)
7 (47) 6 (46) 5 (45) 4 (44) 3 (43) ... 0 (40)

P DPL S=0 type
Номер байту Ширина Символічне

Призначення і вміст полів
в шлюзі поля, розр. позначення
0...1 16 offset_1 Молодші 16 розрядів зміщення точки входу
2...3 16 selector Селектор сегмента, який містить код процедури
4 біти 0...4 5 WC Лічильник параметрів
біти 5...7 3 Заповнення нулями
5 біти 0...3 4 Type Тип: С (386) або 4 (286)
біт 4 1 S =0 – “системний”
біти 5...6 2 DPL Рівень привілеїв шлюзу
=1 – шлюз відкритий
біт 7 1 P =0 – шлюз закритий
6...7 16 offset_1 Старші 16 розрядів зміщення точки входу

Керування за допомогою
шлюзів
 Шлюзом можна керувати: біт P в байті захисту шлюзу
використовується для його “відкривання” або “закривання”
 Виклик через шлюз надає можливість контрольованої
передачі параметрів через стек
 У кожному процесі передбачено існування різних (до трьох) стеків,
кожний з яких відповідає певному рівню привілеїв
 Під час виклику через шлюз процедури, яка має рівень привілеїв,
відмінний від CPL, процесор створює новий стек шляхом завантаження
в регістр ss селектора, що відповідає потрібному рівню привілеїв
 цей селектор міститься в контексті процесу – TSS
 В новий стек з поточного стека копіюється стільки 32-розрядних слів
(параметрів виклику процедури), скільки указано в полі WC шлюзу
 Також в новий стек копіюється селектор старого стека, який дає змогу
повернутись у процедуру, з якої здійснювався виклик

Виклик завдань
 Для переключення між завданнями (процесами) в
команді CALL повинен бути заданий селектор, що
вказує на дескриптор системного сегмента TSS –
сегмента стану завдання
 Такі дескриптори можуть знаходитись лише у таблиці GDT
 Формат дескриптора аналогічний формату дескриптора
сегмента даних, але значення біту S = 0
 Сегмент TSS зберігає контекст процесу, тобто всю
інформацію, необхідну для поновлення
виконання процесу після переривання
 Переключення контекстів здійснюється апаратно

Бітова карта введення/виведення (БКВВ) 8 кБ
Додаткова інформація ОС
Відносна адреса БКВВ 0...0 64
0...0 Селектор LDT 60
0...0 gs 5C
0...0 fs 58
Структура 0...0
0...0
ds
ss
54
50
сегмента 0...0
0...0
cs
es
4C
48
TSS
edi 44
esi 40
ebp 3C
esp 38
ebx 34
edx 30
ecx 2C
eax 28
eflags 24
eip 20
cr3 1C
0...0 ss рівня 2 18
esp2 14
0...0 ss рівня 1 10
esp1 0C
0...0 ss рівня 0 08
esp0 04
0 . .-. Лекція
Безпека ОС 0 15-16 селектор TSS повернення 20/41
00
Послідовність дій під час
переключення контекстів
1.Виконується команда CALL, в якій задано селектор, що
указує на дескриптор сегмента типу TSS
2.Здійснюється перевірка прав доступу
 Якщо CPL > DPL, доступ заборонено
3.Селектор поточного сегмента TSS береться з регістру tr
До TSS заносяться значення регістрів процесора
4.В регістр tr завантажується селектор TSS завдання, на яке
переключається процесор
5.З нового TSS в регістр ldtr завантажується селектор LDT
6.З відповідних полів нового TSS оновлюються всі регістри
процесора
7.Селектор сегмента TSS попереднього завдання заноситься
в поле селектора повернення нового сегмента TSS

Вплив рівнів привілеїв
процесів на виклик завдань
 Для виклику нового завдання поточний процес
повинен мати рівень привілеїв, не нижчий за нове
завдання (CPL ≤ DPL)
 Таким чином, більш привілейований код має змогу викликати
менш привілейовані завдання
 Наприклад, ОС має змогу запускати і переключати програми
 Передбачена також можливість виклику і більш
привілейованого коду
 Для цього використовуються шлюзи, аналогічні тим, що
використовуються для виклику процедур
 Для виклику завдання шлюз повинен указувати на дескриптор TSS
 При цьому шлюзи можуть знаходитись як у таблиці GDT, так і в LDT

Привілейовані команди
 Процесори x86 надають права виконання деяких команд лише програмам, що
мають визначений рівень привілеїв CPL
 Такі команди називаються привілейованими
 Цей механізм дозволяє реалізувати захист структур ОС від дій процесів користувача
 До числа команд, які можуть виконуватись лише при CPL = 0, тобто з
найвищими привілеями, відносяться:
 команди роботи з регістрами керування cr0…cr4;
 команди завантаження регістрів системних адрес gdtr, ldtr, idtr, tr;
 команда зупинки процесора HALT.
 Існують також команди, які стосуються операцій введення/виведення і
вимагають, аби рівень привілеїв поточного процесу CPL був вищий, ніж
рівень привілеїв введення/виведення IOPL (тобто, CPL ≤ IOPL)
 Такі команди іноді називають чутливими
 До них належать:
 команди заборони/дозволу маскованих переривань CLI/SLI;
 команди введення/виведення IN, INS, OUT, OUTS.
 Рівень привілеїв введення/виведення IOPL зберігається у спеціальному полі

регістру eflags

Бітова карта введення-
виведення
 Якщо при спробі виконання команди введення-
виведення не виконується умова CPL ≤ IOPL, то
здійснюється звернення до бітової карти введення-
виведення (БКВВ)
 БКВВ має розмір 8 кбайт і описує доступ до 65536
портів
 Можливість доступу до порту з конкретною адресою
визначається відповідним бітом у БКВВ
 Коли біт, що відповідає певному порту, дорівнює
нулю, операція введення-виведення дозволяється
 Це дає можливість відкрити прямий доступ до
окремих портів програмам з низьким рівнем привілеїв

Підтримка керування
пам’яттю
 Основними завданнями розподілу пам’яті є:
 відстеження вільної і зайнятої пам’яті, виділення пам’яті
процесам під час їх запуску і в процесі роботи, звільнення
пам’яті, дефрагментація пам’яті;
 трансляція адрес, що використовуються в програмах;
 організація віртуальної пам’яті;
 розмежування доступу процесів до окремих областей
пам’яті як з метою ізоляції адресних просторів процесів від
доступу інших процесів, так і з метою організації
контрольованого спільного доступу процесів до виділених
областей пам’яті.
 Лише четверте з зазначених завдань
безпосередньо пов'язано з захистом інформації
Віртуальні адреси
 Віртуальні адреси дозволяють забезпечити коректну
адресацію незалежно від розташування програми в
оперативній пам’яті комп’ютера
 Для цього використовуються відносні адреси, тобто зміщення
від деякої базової адреси
 Моделі пам’яті:
 Пласка модель – кожному процесу виділяється єдина
неперервна послідовність віртуальних адрес
 Зміщення дозволяє однозначно вказати на положення даних або
команди в адресному просторі даного процесу
 Сегментна модель – адресний простір процесу поділяється на
окремі частини – сегменти (секції, області)
 Віртуальна адреса задається парою чисел (n, m), де n визначає
сегмент, а m – зміщення в даному сегменті

Трансляція віртуальної адреси за
сегментної організації пам’яті
Віртуальна адреса
Номер сегмента – i Зміщення в сегменті
Таблиця дескрипторів
сегментів
сегмент 1 Базова
сегмент 2 адреса
... сегмента
сегмент i
...
Фізична адреса

Байт захисту дескриптора
сегмента
7 (47) 6 (46) 5 (45) 4 (44) 3 (43) 2 (42) 1 (41) 0 (40)
P DPL S E C/ED R/W A
type_seg
 Чотири молодших розряди байту захисту прийнято називати полем

типу сегмента (type_seg)
 насправді тип сегмента задається розрядами не 0...3, а 1...4
 Розряд 0 встановлюється при доступі до сегмента і може використовуватись
операційною системою при реалізації алгоритмів керування віртуальною пам’яттю
 Розряд 4 визначає, чи є об’єкт, який описує цей дескриптор, сегментом у пам’яті чи
спеціальним системним об’єктом
 Розряди 1...3 визначають, власне, тип сегмента і права доступу до нього
 Два розряди байту захисту дескриптора – розряди 5 і 6 – задають
рівень привілеїв дескриптора (DPL – Descriptor Privilege Level)
 Разом з рівнем привілеїв селектора RPL і поточним рівнем привілеїв процесу, що
виконується (CPL – Current Privilege Level), ці рівні дозволяють організувати
розмежування доступу до сегментів пам’яті за мандатним принципом – кільця
захисту

Значення поля типу сегмента
Біт Комбінація
S бітів у полі Тип сегмента
type_seg
0 0100 Локальна таблиця дескрипторів (LDT)

0001
0 1000 Сегмент стану завдання (TSS)
1101
1101
1 000x Сегмент даних, тільки для зчитування
1 001x Сегмент даних, дозволені зчитування і записування
1 010x Не визначено
1 011x Сегмент стека, дозволені зчитування і записування
1 100x Сегмент коду, дозволено тільки виконання
1 101x Сегмент коду, дозволені зчитування і виконання
1 110x Підпорядкований сегмент коду, дозволено тільки виконання
1 111x Підпорядкований сегмент коду, дозволені зчитування і виконання
Дескриптор сторінки
31 12 11 … 9 8 7 6 5 4 3 2 1 0
Номер сторінки AVL 0 D A PCD PWT U W P
Номер Символічне Призначення і вміст

біту позначення
0 P (Present) Прапорець присутності сторінки у фізичній пам’яті.
1 W (Writable) Прапорець дозволу записування у сторінку
2 U (User mode) Прапорець користувач/супервізор
3 PWT Керують механізмом кешування сторінок (введені, починаючи з
4 PCD процесора i486)
5 A (Accessed) Ознака, що мав місце доступ до сторінки
6 D Ознака модифікації вмісту сторінки
7…8 0 Зарезервовані
9…11 AVL (Available) Зарезервовані для потреб операційної системи
12...31 Номер сторінки у пам’яті
 Віртуальна лінійна адреса є 32-розрядною
 старші 20 розрядів інтерпретуються як номер віртуальної сторінки (індекс дескриптора сторінки)
 З дескриптора визначається номер сторінки у фізичній пам’яті
 молодші 12 розрядів інтерпретуються як зміщення в сторінці
 Зміщення у віртуальній і фізичній сторінках співпадають
Трансляція віртуальної адреси за
дворівневої сторінкової організації
пам’яті
Віртуальна адреса
Номер Номер віртуальної Зміщення
розділу – i сторінки в розділі – j в сторінці
Таблиця Таблиця сторінок

розділів розділу i
розділ 1 сторінка 1
... ...
розділ i сторінка j
... ...
Номер фізичної Зміщення

сторінки в сторінці
Вихідна віртуальна адреса
Номер сегмента – i Зміщення в сегменті
Таблиця дескрипторів
сегментів
Трансляція сегмент 1
сегмент 2
Базова
адреса
сегмента
...
віртуальної сегмент i
...
адреси за Лінійна віртуальна адреса
сегментно- Номер
розділу – j
Номер віртуальної
сторінки в розділі – k
Зміщення
в сторінці
сторінкового Таблиця Таблиця сторінок
розподілу
розділів розділу i
пам’яті ...
розділ j
...
сторінка k
... ...
Номер фізичної Зміщення
Безпека ОС - Лекція 15-16 сторінки в сторінці
32/41
Завантаження селектора в сегментний
регістр – пошук дескриптора
 Якщо у селекторі прапорець TI = 0, то дескриптор міститься у GDT

 Базова адреса і межа (розмір) таблиці GDT визначаються з регістру gdtr
 Для вибору потрібного дескриптора використовується індекс, що міститься в селекторі
 Перевіряється, чи не виходить дескриптор за встановлену межу таблиці GDT
 Якщо ні – відбувається звернення до дескриптора
 В разі виходу за межу, генерується внутрішнє переривання процесора – виняткова ситуація
11
 Якщо у селекторі прапорець TI = 1, то дескриптор міститься в таблиці LDT
 Першим кроком є пошук таблиці LDT, для чого в якості селектора використовується вміст
регістру ldtr
 З таблиці GDT вибирається дескриптор, що описує таблицю LDT
 Перевіряється
 чи відповідає тип дескриптора таблиці дескрипторів
 чи присутня таблиця у фізичній пам’яті (біт P байта AR дескриптора дорівнює 1)
 З дескриптора таблиці LDT визначаються базова адреса таблиці та її межа
 Здійснюється операція вибору з таблиці LDT необхідного дескриптора, яка аналогічна
операції вибору дескриптора з таблиці GDT, з тими ж перевірками

регістр – перевірка сумісності типів
 За звернення до дескриптора здійснюється перевірка сумісності

типів селектора і дескриптора
 Дескриптор повинен описувати сегмент у пам’яті (біт S = 1)
 Якщо селектор завантажується в регістр, що вказує на сегмент
даних, то несумісним буде дескриптор, що описує сегмент коду із
захистом від зчитування (біт E = 1, біт R = 0)
 Якщо селектор завантажується в регістр cs, то сумісним типом буде
лише сегмент коду
 Якщо селектор завантажується в регістр ss, то сумісним типом буде
лише сегмент стека
 Очевидно, що більш жорсткі умови сумісності для сегментів стека і коду
спрямовані на запобігання “підсовування” процесору зловмисного коду через
сегменти даних
 Якщо перевірка дає негативний результат, фіксується несумісність
типів – генерується виняткова ситуація 13 (загальна помилка
захисту)

Дозволені комбінації бітів
байту захисту дескриптора
при виконанні операції
завантаження селектора в
сегментний регістр
Регістр P DPL S E C/ED R/W A Примітка
cs x xx 1 1 x x x сегмент коду
ss x xx 1 0 1 1 x сегмент стека
1 x 1 x сегмент коду
ds, es, fs, gs x xx 1
0 х х х сегмент даних або стека

регістр – перевірка привілеїв доступу
 Після перевірки сумісності типів здійснюється перевірка

привілеїв доступу до сегмента
 Для цього порівнюються значення
 RPL — рівня привілеїв запитувача (селектора, який ми завантажуємо в
сегментний регістр процесора),
 DPL — рівня привілеїв дескриптора, на який посилається селектор, що ми
завантажуємо, і
 CPL (Current Privilege Level) — рівня привілеїв процесу (потоку), що
виконується, який дорівнює RPL селектора, що знаходиться в регістрі cs
 Для сегмента стека в разі спроби завантаження селектора в регістр ss
повинна виконуватись рівність DPL = RPL = CPL
 Для всіх інших сегментів рівень DPL повинен бути не вищим за рівень
RPL і CPL, тобто DPL ≥ RPL і DPL ≥ CPL
 найвищому рівню привілеїв відповідає значення 0, а найнижчому – 3
 Якщо потрібне співвідношення не виконується, фіксується недостатній
рівень привілеїв (виняткова ситуація 13 – загальна помилка захисту).

Звернення до пам’яті
 В процесі звернення до пам’яті за сегментного розподілу перевіряється
дозвіл на операцію і коректність доступу
 Для команди зчитування з пам’яті обмеження можуть бути встановлені лише для сегментів
коду (біт E = 1): якщо біт R = 0, то зчитування заборонено
 Для команди записування в пам’ять сегмент коду взагалі є несумісним типом, а всі інші
типи сегментів можуть бути захищені бітом W: якщо W = 0, записування заборонено
 В усіх зазначених випадках генерується виняткова ситуація 13 – загальна помилка захисту
 Перевірка коректності доступу полягає у перевірці відсутності виходу за
межу сегмента
 Перевірка здійснюється з урахуванням розміру даних і напряму зростання сегмента
 Якщо сегмент є сегментом стека (біт E = 0 та біт ED = 1), то він зростає в бік молодших
адрес, і тоді обчислена адреса повинна бути не меншою за межу сегмента
 Якщо ж сегмент є сегментом коду (біт E = 1) або даних (біт E = 0 та біт ED = 0), то він
зростає в бік старших адрес, тому до обчисленої адреси додається розмір даних (для
команди mov – в залежності від того, який з регістрів процесора бере участь у
передаванні/прийманні даних), і отримана адреса повинна бути не більшою за межу
сегмента
 В разі помилки генерується виняткова ситуація 13 – загальна помилка захисту

Дозволені комбінації бітів
байту захисту дескриптора
при виконанні операцій
звернення до пам’яті
Операція P DPL S E C/ED R/W A Примітка
1 xx 1 0 x x x сегмент даних або

Зчитування стека
з пам’яті
1 xx 1 1 x 1 x сегмент коду
Записування 1 xx 1 0 x 1 x сегмент даних або

у пам’ять стека

Особливості використання пам’яті
в архітектурі x86-64 (amd64)
 У сучасних реалізаціях x86-64 насправді може
використовуватись лише невелика частина 64-розрядних
адрес
 Для перетворення адреси (пошуку по таблиці сторінок) використовуються
лише найменші значимі 48 біт адреси віртуальної пам'яті
 Біти від 48 до 63 для будь-якої віртуальної адреси повинні бути копією біта 47 —
інакше процесор згенерує виняткову ситуацію
 Формат адрес що відповідають цьому правилу називають "канонічною формою"
 Реально використовуються 2 діапазони адрес:
 від 0 до 00007FFFFFFFFFFF,
 від FFFF800000000000 до FFFFFFFFFFFFFFFF
 Кожний з цих діапазонів — у 128 TiB, разом — 256 TіB віртуального
 Це приблизно в 64000 разів більше від віртуального адресного простору в 32-
розрядній архітектурі, але все ж є мізерною частинкою повного 64-розрядного

Особливості сегментації пам’яті в
архітектурі amd64 (x86_64) 1/2
 Процесор підтримує режими:
 long (64 розряди, з підтримкою 32-розрядних програм), при цьому
використовують 4-рівневі таблиці сторінок
 legacy (32 розряди, повністю сумісний із захищеним режимом x86)
 В режимі long, сегментація пам’яті залежить від того, в
якому під-режимі працює процесор:
 В режимі сумісності (compatibility mode), сегментація працює точно
так, як і в режимі legacy, використовуючи семантику legacy 16-bit
або захищеного режиму 32-bit
 В режимі 64-bit, сегментація відключена, і використовується
пласка 64-розрядна модель віртуального адресного простору, за
винятком окремих функцій деяких сегментних регістрів
 Значення базової адреси сегмента з дескриптора ігнорують, і вважають за 0
 Границі сегментів і більшість атрибутів також ігнорують

Особливості сегментації пам’яті в
архітектурі amd64 (x86_64) 2/2
 Що не ігнорують в режимі 64-bit:
 Атрибути з байту захисту дескриптора сегмента CS:
 DPL — визначає рівень привілеїв виконуваної програми
 D — розмір операндів за умовчанням
 L — чи працює програма в режимі 64-bit або сумісності
(compatibility)
 Регістри FS і GS можуть використовуватись як додаткові
базові регістри в обчисленнях адреси, і ці сегменти
можуть мати ненульові значення базової адреси
 Це спрощує адресацію локальних даних потоку і деяких
структур даних системного ПЗ
 Регістри системних сегментів використовуються і в
режимі 64-bit

Безпека
операційних систем і
комп’ютерних мереж
Для добавления
Довідковий текста
матеріал до
щелкните
лекцій 7-8 мышью
(Засоби захисту Windows)
Витяг з Microsoft Windows 10, Windows
Server (April 2018 Update) Security Target
Why Using the Security Target?
• How an ST should be used (according to the Common Criteria):
– Before and during the evaluation, the ST specifies “what is to be evaluated”
• Technical correctness and completeness are major issues for this role
– After the evaluation, the ST specifies “what was evaluated” (our case)
• The ST describes the exact security properties of the TOE in an abstract manner
• The potential consumer can rely on this description because the TOE has been evaluated to meet the ST
• Ease of use and understandability are major issues for this role
• However, an ST should not be used as:
– a detailed specification:
• An ST is designed to be a security specification on a relatively high level of abstraction
• An ST should, in general, not contain detailed protocol specifications, detailed descriptions of algorithms
and/or mechanisms, long description of detailed operations etc.
• This may be a drawback in out case
– a complete specification:
• An ST is designed to be a security specification and not a general specification
• Unless security-relevant, properties such as interoperability, physical size and weight, required voltage etc.
should not be part of an ST
• This means that in general an ST may be a part of a complete specification, but not a complete
specification itself
• This is not a problem in out case
2
Target of Evaluation (TOE)
Reference
• TOE Software Identification: The following Windows Operating
Systems (OS):
– Microsoft Windows 10 Home Edition (April 2018 Update) (32-bit version)
– Microsoft Windows 10 Pro Edition (April 2018 Update) (64-bit versions)
– Microsoft Windows 10 Enterprise Edition (April 2018 Update) (64-bit
versions)
– Microsoft Windows Server Standard Core, version 1803
– Microsoft Windows Server Datacenter Core, version 1803
• TOE Versions:
– Windows 10: build 10.0.17134 (also known as version 1803)
– Windows Server: build 10.0.17134 (also known as version 1803)
– The following security updates must be applied for Windows 10 and
Windows Server: all critical updates as of July 30, 2018
3
TOE Overview
• The TOE includes
– the Windows 10 operating system,
– the Windows Server operating system,
– those applications necessary to manage, support and configure the operating system.
• Windows 10 and Windows Server can be delivered preinstalled on a new
computer or downloaded from the Microsoft website.
• All Windows 10 and Windows Server editions, collectively called “Windows”, are
preemptive multitasking, multiprocessor, and multi-user operating systems.
– In general, operating systems provide users with a convenient interface to manage
underlying hardware. They control the allocation and manage computing resources such
as processors, memory, and Input/Output (I/O) devices.
– Windows expands these basic operating system capabilities to controlling the allocation
and managing higher level IT resources such as security principals (user or machine
accounts), files, printing objects, services, window station, desktops, cryptographic keys,
network ports traffic, directory objects, and web content.
– Multi-user operating systems such as Windows keep track of which user is using which
resource, grant resource requests, account for resource usage, and mediate conflicting
requests from different programs and users.
4
TOE Usage
• Windows 10 is suited for business desktops, notebook, and convertible computers.
– It is the workstation product and while it can be used by itself, it is designed to serve as a client
within Windows domains.
• Windows Server is built for workloads ranging from the department to the enterprise
to the cloud. It delivers:
– intelligent file and printer sharing;
– secure connectivity based on Internet technologies,
– centralized desktop policy management.
It provides the necessary scalable and reliable foundation to support
– mission-critical solutions for databases,
– enterprise resource planning software,
– high-volume, real-time transaction processing,
– server consolidation,
– public key infrastructure,
– virtualization,
– and additional server roles.
• Windows provides an interactive User Interface (UI), as well as a network interface.
5
TOE Usage — Domains and Forests
• The TOE includes a set of computer systems that can be connected via
their network interfaces and organized into domains and forests.
– A domain is a logical collection of Windows systems that allows the administration
and application of a common security policy and the use of a common accounts
database.
– One or more domains combine to comprise a forest.
– Windows supports single-domain and multiple-domain (i.e., forest) configurations as
well as federation between forests and external authentication services.
• Each domain must include at least one designated server known as a
Domain Controller (DC) to manage the domain.
– The TOE allows for multiple DCs that replicate TOE user and machine account as
well as group policy management data among themselves to provide for higher
availability.
• Each Windows system, whether it is a DC server, non-DC server, or
workstation, provides a subset of the TSFs (TOE Security Functions).
– The TSF subset for Windows can consist of the security functions from a single
system, for a stand-alone system, or the collection of security functions from an
entire network of systems, for a domain configuration.
6
TOE Security Services
• Security Audit
• Cryptographic Support
• User Data Protection
• Identification and Authentication
• Protection of the TOE Security Functions
• Session Locking
• TOE Access
• Trusted Path for Communications
• Security Management
7
TOE Security Services (1)
• Security Audit:
– Windows has the ability to
• collect audit data,
• review audit logs,
• protect audit logs from overflow,
• and restrict access to audit logs.
– Audit information generated by the system includes
• the date and time of the event,
• the user identity that caused the event to be generated,
• and other event specific data.
– Authorized administrators can review audit logs and have the
ability to search and sort audit records.
– Authorized Administrators can also configure the audit system to
include or exclude potentially auditable events to be audited based
on a wide range of characteristics.
8
• Cryptographic Support:
– Windows provides FIPS 140-2 CAVP validated cryptographic functions that support
• encryption/decryption,
• cryptographic signatures,
• cryptographic hashing,
• cryptographic key agreement,
• and random number generation.
– The TOE additionally provides support for public keys, credential management and
certificate validation functions and provides support for the National Security Agency’s
Suite B cryptographic algorithms.
– Windows also provides
• extensive auditing support of cryptographic operations,
• the ability to replace cryptographic functions and random number generators with alternative
implementations,
• and a key isolation service designed to limit the potential exposure of secret and private keys.
– In addition to using cryptography for its own security functions, Windows offers access
to the cryptographic support functions for user-mode and kernel-mode programs.
– Public key certificates generated and used by Windows authenticate users and
machines as well as protect both user and system data in transit.
9
• User Data Protection:
– In the context of this evaluation Windows protects user data and
provides virtual private networking capabilities.
• Identification and Authentication
– Each Windows user must be identified and authenticated based on
administrator-defined policy prior to performing any TSF-mediated
functions.
– An interactive user invokes a trusted path in order to protect his I&A
information.
– Windows maintains databases of accounts including their identities,
authentication information, group associations, and privilege and
logon rights associations.
– Windows account policy functions include the ability to define the
minimum password length, the number of failed logon attempts, the
duration of lockout, and password age.
10
• Protection of the TOE Security Functions:
– Windows protects against unauthorized data disclosure and
modification by using a suite of Internet standard protocols
including IPsec, IKE, and ISAKMP.
– Windows ensures process isolation security for all processes
through private virtual address spaces, execution context, and
security context.
– The Windows data structures defining process address space,
execution context, memory protection, and security context are
stored in protected kernel-mode memory.
– Windows includes self-testing features that ensure the integrity
of executable program images and its cryptographic functions.
– Finally, Windows provides a trusted update mechanism to
update Windows binaries itself.
11
• Session Locking:
– Windows provides the ability for a user to lock their session either
immediately or after a defined interval.
– Windows constantly monitors the mouse, keyboard, and touch display for
activity and locks the computer after a set period of inactivity.
• TOE Access:
– Windows allows an authorized administrator to configure the system to
display a logon banner before the logon dialog.
• Trusted Path for Communications:
– Windows uses HTTPS, TLS, DTLS, and EAP-TLS to provide a trusted
path for communications.
• Security Management:
– Windows includes several functions to manage security policies.
– Policy management is controlled through a combination of access control,
membership in administrator groups, and privileges.
12
TOE Logical Boundaries
• Conceptually the Windows TOE can be thought of as a collection of the
security services which were briefly reviewed above, and will be described
with increasing detail further.
• These services are primarily provided by Windows components:
– The Boot Manager, which is invoked by the computer’s bootstrapping code.
– The Windows Loader which loads the operating system into the computer’s memory.
– The Windows Kernel which contains device drivers for the Windows NT File System,
full volume encryption, the crash dump filter, and the kernel-mode cryptographic library.
– The IPv4 / IPv6 network stack in the kernel.
– The Windows Trusted Installer which installs updates to the Windows operating
system.
– The Local Security Authority Subsystem which identifies and authenticates users
prior to log on and generates events for the security audit log.
– FIPS-Approved cryptographic algorithms to protect user and system data.
– The Key Isolation Service which protects secret and private keys.
– Local and remote administrative interfaces for security management.
– Windows Explorer which can be used to manage the OS and check the integrity of
Windows files and updates.
13
TOE Physical Boundaries
• Each instance of the general purpose OS TOE runs on a tablet,
convertible, workstation or server computer.
• The TOE executes on processors from Intel (x86 and x64) or AMD (x86
and x64) along with peripherals for input/output (keyboard, mouse, display,
and network).
• The TOE was tested on the following physical and virtual computer
platforms:
– Microsoft Surface Book 2
– Microsoft Surface Pro LTE
– Microsoft Surface Laptop
– Microsoft Surface Go
– Dell Latitude 5290
– Dell Latitude 12 Rugged Tablet
– Dell PowerEdge R740 3 (representing the 14 th generation of PowerEdge servers.)
– Microsoft Windows Server Hyper-V
– Microsoft Windows Server 2016 Hyper-V
14
Product Description
• In addition to core operating system capabilities described above, Windows can
also be categorized as the following types of Information Assurance (IA) or IA-
enabled IT products:
– these capabilities leverage functionality included in this General Purpose OS evaluation
as well as capabilities which fall outside the scope of the GP OS PP
• Windows is a Network Management and Desktop Management product to
support security infrastructure
– Group Policy and mobile device management Configuration Service Providers (part of the
Windows TOE) provide the centralized network management in Windows networks and
desktops.
• Windows is a Single Sign-On product for Windows networks
• Windows is a Firewall product with the capability to filter network traffic based
upon
– source and destination addresses,
– ports,
– applications,
– user or machine identity,
– and protocols.
15
CC Conformance Claims
• This ST and the Windows 10 editions (TOEs) are consistent with the
following specifications:
– Common Criteria for Information Technology Security Evaluation Part 2:
Security functional requirements, Version 3.1, Revision 5, April 2017,
extended (Part 2 extended)
– Common Criteria for Information Technology Security Evaluation Part 3:
Security assurance requirements Version 3.1, Revision 5 April 2017, (Part 3
extended)
– General Purpose Operating Systems Protection Profile, Version 4.1, March
9, 2016 (GP OS PP)
– General Purpose Operating Systems Protection Profile / Mobile Device
Fundamentals Protection Profile Extended Package (EP) Wireless Local
Area Network (WLAN) Clients, version 1.0, February 8, 2016 (WLAN EP)
• This ST and the Windows Server editions (TOEs) are consistent with
the following specifications:
– 1-3 of the above
16
Security Problem Definition
• The security problem definition consists of the
– threats to security,
– organizational security policies,
– and usage assumptions
as they relate to Windows.
• The assumptions, threats, and policies are copied from:
– the General Purpose Operating Systems Protection Profile,
Version 4.1, March 9, 2016 (“GP OS PP”) and
– the General Purpose Operating Systems Protection Profile/
Mobile Device Fundamentals Protection Profile Extended
Package (EP) Wireless Local Area Network (WLAN) Clients
(“WLAN EP”).
17
Table 1 GP OS PP Threats
Addressed by Windows
Threat Description
T.NETWORK An attacker is positioned on a communications channel or elsewhere
_ATTACK on the network infrastructure. Attackers may engage in communications
with applications and services running on or part of the OS with the
intent of compromise. Engagement may consist of altering existing
legitimate communications.
T.NETWORK An attacker is positioned on a communications channel or elsewhere

_EAVESDROP on the network infrastructure. Attackers may monitor and gain access
to data exchanged between applications and services that are running
on or part of the OS.
T.LOCAL An attacker may compromise applications running on the OS. The
_ATTACK compromised application may provide maliciously formatted input to the
OS through a variety of channels including unprivileged system calls
and messaging via the file system.
T.LIMITED An attacker may attempt to access data on the OS while having a
_PHYSICAL limited amount of time with the physical device.
_ACCESS
18
Table 2 WLAN EP Threats
Addressed by Windows
Threat Description
T.TSF_FAILURE Security mechanisms of the TOE generally build up from a
(TSF Failure) primitive set of mechanisms (e.g., memory management, privileged
modes of process execution) to more complex sets of
mechanisms. Failure of the primitive mechanisms could lead to a
compromise in more complex mechanisms, resulting in a
compromise of the TSF.
T.UNAUTHORIZED A user may gain unauthorized access to the TOE data and TOE
_ACCESS executable code. A malicious user, process, or external IT entity
(Unauthorized may masquerade as an authorized entity in order to gain
Access) unauthorized access to data or TOE resources. A malicious user,
process, or external IT entity may misrepresent itself as the TOE to
obtain identification and authentication data.
T.UNDETECTED Malicious remote users or external IT entities may take actions that
_ACTIONS adversely affect the security of the TOE. These actions may remain
(Undetected undetected and thus their effects cannot be effectively mitigated.
Actions)
19
Table 3 Organizational Security
Policies
Security Policy Description
[None] There are no Organizational Security Policies for the
protection profile or extended package.
20
Table 4 Secure Usage
Assumptions
Assumption Description
A.PLATFORM The OS relies upon a trustworthy computing platform for
its execution. This underlying platform is out of scope of
this PP.
A.PROPER_USER The user of the OS is not willfully negligent or hostile,
and uses the software in compliance with the applied
enterprise security policy. At the same time, malicious
software could act as the user, so requirements which
confine malicious subjects are still in scope.
A.PROPER_ADMIN The administrator of the OS is not careless, willfully
negligent or hostile, and administers the OS within
compliance of the applied enterprise security policy.
21
Table 5 WLAN EP Secure Usage
Assumptions for Windows
Assumption Description
A.NO_TOE_BYPASS Information cannot flow between the wireless
client and the internal wired network without
passing through the TOE.
A.TRUSTED_ADMIN TOE Administrators are trusted to follow and
apply all administrator guidance in a trusted
manner.
22
TOE Summary Specification (TSS)
• The following part of the presentation is based on the chapter
describing the Windows security functions that satisfy the security
functional requirements of the protection profile.
– The TOE also includes additional relevant security functions which are also
described in the following sections, as well as a mapping to the security
functional requirements satisfied by the TOE.
• The TOE performs the following security functions:
– Audit
– Cryptographic Support
– User Data Protection
– Identification and Authentication
– Security Management
– Protection of the TSF
– TOE Access
– Trusted Channels
23
Audit
The TOE Audit security function performs:
– Audit Collection
– Selective Audit
– Audit Log Overflow Protection
– Audit Log Restricted Access Protection
24
Audit Collection
• The Windows Event Log service creates the security event
log,
– The log contains security relevant audit records collected on a system
– There are other event logs which are also registered by other audit
entry providers
• The Local Security Authority (LSA) server
– collects audit events from all other parts of the TSF
– and forwards them to the Windows Event Log service
• The latter will place the event into the log for the appropriate provider.
• There is no size limit for a single audit record
– the authorized administrator can specify a limit for the size of each
event log.
• For each audit event, the Windows Event Log service stores
the following data (see next slide) in each audit entry
25
Standard Fields in a Windows Audit Entry
Field in Description
Audit Entry
Date The date the event occurred.
Time The time the event occurred.
User The security identifier (SID) of that represents the user on
whose behalf the event occurred that represents the user.
Event ID A unique number within the audit category that identifies
the specific audit event.
Source The Windows component that generated the audit event.
Outcome Indicates whether the security audit event recorded is the
result of a successful or failed attempt to perform the
action.
Category The type of the event defined by the event source.
26
Audit Events Categories
• The LSA service defines the following categories
for audit events in the security log:
– System,
– Logon / Logoff
– Object Access
– Directory Service Access
– Privilege Use
– Detailed Process Tracking
– Policy Change
– Account Management
– Account Logon
27
Category-Specific Data (1)
• Each audit entry may also contain category-specific data
that is contained in the body of the entry
– For the System Category, the audit entry includes information
relating to the system such as
• the time the audit trail was cleared,
• start or shutdown of the audit function,
• and startup and shutdown of Windows.
• the specific cryptographic operation is identified when such operations
are audited.
– For the Logon and Account Logon Category, the audit entry
includes the reason the attempted logon failed.
– For the Object Access and the Directory Service Access
Category, the audit entry includes
• the object name
• and the desired access requested.
28
Category-Specific Data (2)
– For the Privilege Use Category, the audit entry identifies the
privilege.
– For the Detailed Process Tracking Category, the audit event
includes the process identifier.
– For the Policy Change and Account Management Category, the
audit event includes the new values of the policy or account
attributes.
– For the Account Logon Category, the audit event includes the
logon type that indicates the source of the logon attempt:
• Interactive (local logon)
• Network (logon from the network)
• Service (logon as a service)
• Batch (logon as a batch job)
• Unlock (for Unlock screen saver)
• Network_ClearText (for anonymous authentication to IIS)
29
Where Security Audit Events
are Collected
• There are two places within the TSF where security audit events are
collected.
– Inside the kernel, the Security Reference Monitor (SRM), a part of the NT
Executive, is responsible for generation of all audit entries for the
• object access,
• privilege use,
• and detailed process tracking event categories.
Windows components can request the SRM to generate an audit record and supply all of the
elements in the audit record except for the system time, which the Executive provides.
– With one exception, audit events for the other event categories are generated by
various services that either
• co-exist in the LSA server
• or call, with the SeAuditPrivilege privilege, the Authz Report Audit interfaces implemented in
the LSA Policy subcomponent.
– The exception is that the Event Log Service itself records an event record
• when the security log is cleared
• and when the security log exceeds the warning level configured by the authorized administrator.
30
Audit Policy
• The LSA server maintains an audit policy in its database that
determines which categories of events are actually collected.
– Defining and modifying the audit policy is restricted to the authorized
administrator. The authorized administrator can
• select events to be audited by selecting the category or categories to be audited.
• individually select each category.
• The only other TSF component that uses the audit policy is the
SRM in order to record object access, privilege use, and detailed
tracking audit.
– LSA and the SRM share a private local connection port, which is used to
pass the audit policy to the SRM.
– When an authorized administrator changes the audit policy, the LSA
updates its database and notifies the SRM.
– The SRM receives a control flag indicating if auditing is enabled and a
data structure indicating that the events in particular categories to audit.
31
Per-user Audit Policy
• In addition to the system-wide audit policy configuration, it is possible to
define a per-user audit policy using auditpol.exe.
– This allows individual audit categories (of success or failure) to be enabled or
disabled on a per user basis.
– The per-user audit policy refines the system-wide audit policy with a more
precise definition of the audit policy for which events will be audited for a specific
user.
– Windows will prevent a local administrator from disabling auditing for local
administrator accounts.
• If an administrator can bypass auditing, they can avoid accountability for such actions as
exfiltrating files without authorization.
• Within each category, auditing can be performed based on success,
failure, or both.
• For object access events, auditing can be further controlled based on
user/group identify and access rights using System Access Control
Lists (SACLs).
– SACLs are associated with objects and indicate whether or not auditing for a
specific object, or object attribute, is enabled.
32
Cryptographic Support
• Cryptographic Algorithms and Operations
• Cryptographic Algorithm Validation
• Networking (TLS)
• Protecting Data with DPAPI
33
Cryptography API: Next Generation
• The Cryptography API: Next Generation (CNG) API is designed to
be extensible at many levels and agnostic to cryptographic algorithm
suites.
– Windows uses CNG exclusively for its own encryption needs and provides
public APIs for external developers.
• An important feature of CNG is its native implementation of the Suite B
algorithms, including algorithms for
– AES (128, 192, 256 key sizes - the 192-bit key size is not used by Windows
but is available to developers),
– the SHA-1 and SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing
algorithms,
– elliptic curve Diffie Hellman (ECDH), and elliptical curve DSA (ECDSA) over
the NIST-standard prime curves P-256, P-384, and P-521.
• Protocols such as the Internet Key Exchange (IKE), and Transport
Layer Security (TLS), make use of elliptic curve Diffie-Hellman (ECDH)
included in Suite B as well as hashing functions.
34
Deterministic Random Bit Generation
• Deterministic random bit generation (DRBG) is implemented
in accordance with NIST Special Publication 800-90
– Windows generates random bits by taking the output of
• a cascade of two SP800-90 AES-256 counter mode based DRBGs in
kernel-mode
• and four cascaded SP800-90 AES-256 DRBGs in user-mode;
– programmatic callers can choose to obtain either 128 or 256
bits from the RBG which is seeded from the Windows entropy
pool
• Windows has different entropy sources (deterministic and
nondeterministic) which produce entropy data that is used for
random numbers generation
– In particular, this entropy data together with other data (such
as the nonce) seed the DRBG algorithm
35
Entropy Pool
• The entropy pool is populated using the following values:
– An initial entropy value from a seed file provided to the Windows OS Loader at boot
time (512 bits of entropy).
• The Windows OS Loader implements a SP 800-90 AES-CTR-DRBG and passes
along 384 bits of entropy to the kernel for CNG to be used during initialization.
• This DBRG uses the same algorithms to obtain entropy from the CPU cycle counter,
TPM, and RDRAND
– A calculated value based on the high-resolution CPU cycle counter which fires after
every 1024 interrupts (a continuous source providing 16384 bits of entropy).
– Random values gathered periodically from the Trusted Platform Module (TPM), (320
bits of entropy on boot, 384 bits thereafter on demand based on an OS timer).
– Random values gathered periodically by calling the RDRAND CPU instruction, (256
bits of entropy).
• Each entropy source is independent of the other sources and does not depend
on time.
– The CPU cycle counter inputs vary by environmental conditions such as
• data received on a network interface card,
• key presses on a keyboard,
• mouse movement and clicks,
• and touch input. 36
Cryptographic Functions Protection
• The TSF defends against tampering of the random number generation (RNG) /
pseudorandom number generation (PRNG) sources by encapsulating its use in
Kernel Security Device Driver.
– The interface for the Windows random number generator is BCryptGenRandom.
• The CNG provider for random number generation is the AES_CTR_DRBG, when
Windows requires the use of a salt it uses the Windows RBG.
• The encryption and decryption operations are performed by independent modules,
known as Cryptographic Service Providers (CSPs).
– Windows generates symmetric keys (AES keys) using the FIPS Approved random number
generator.
• In addition to encryption and decryption services, the TSF provides other
cryptographic operations such as hashing and digital signatures. Hashing is used
by other FIPS Approved algorithms implemented in Windows (the hashed message
authentication code, RSA, DSA, and EC DSA signature services, Diffie-Hellman
and elliptic curve Diffie-Hellman key agreement, and random bit generation). When
Windows needs to establish an RSA-based shared secret key it can act both as a
sender or recipient, any decryption errors which occur during key establishment are
presented to the user at a highly abstracted level, such as a failure to connect.
37
Other Cryptographic Operations
• In addition to encryption and decryption services, the TSF provides
other cryptographic operations such as
– hashing
– digital signatures.
• Hashing is used by other FIPS Approved algorithms implemented
in Windows
– the hashed message authentication code,
– RSA, DSA, and EC DSA signature services,
– Diffie-Hellman and elliptic curve Diffie-Hellman key agreement,
– and random bit generation.
• When Windows needs to establish an RSA-based shared secret
key it can act both as a sender or recipient
– any decryption errors which occur during key establishment are presented
to the user at a highly abstracted level, such as a failure to connect.
38
Windows Cryptographic Algorithm
Standards and Evaluation Methods
Cryptographic Operation Standard Evaluation Method
FIPS 197 AES NIST CAVP # 5847, # 5859,
# 5860, # 5861
NIST SP 800-38A CBC mode # 5847, # 5861
Encryption/Decryption NIST SP 800-38C CCM mode # 5847, # 5859
NIST SP 800-38E XTS mode # 5847
NIST SP 800-38F KW mode # 5860
NIST SP 800-38D GCM mode # 5847
Digital signature (key FIPS 186-4 RSA NIST CAVP # 3079, # 3080
generation)
Digital signature (generation) FIPS 186-4 RSA NIST CAVP # 3079, # 3080,
# 3082
Digital signature (verification) FIPS 186-4 RSA NIST CAVP # 3079, # 3080,
# 3081, # 3082
Digital signature (generation FIPS 186-4 DSA NIST CAVP # 1479
and verification) 39
Windows Cryptographic Algorithm
Standards and Evaluation Methods
Cryptographic Operation Standard Evaluation Method
Digital signature (key FIPS 186-4 ECDSA NIST CAVP # 1563, # 1564,
generation) # 1565
Digital signature (key FIPS 186-4 ECDSA NIST CAVP # 1563, # 1564
generation, signature
generation and verification)
Hashing FIPS 180-4 SHA-1 and NIST CAVP # 4633
SHA-256, SHA-384, SHA-512
Keyed-Hash Message FIPS 198-2 HMAC NIST CAVP # 3858, # 3859
Authentication Code
Random number generation NIST SP 800-90 CTR_DRBG NIST CAVP # 2435, # 2436
Key agreement NIST SP 800-56A ECDH NIST CAVP # 200, # 201
Key establishment NIST SP 800-56B RSA NIST CVL # 2111, # 2112
Key-based key derivation SP800-108 NIST CAVP # 242, # 243
IKEv1, IKEv2, TLS SP800-135 NIST CVL # 2110
40
Key storage
• CNG includes a user-mode key isolation service designed
specifically to host secret and private keys in a protected process to
mitigate tampering or access to sensitive key materials for user-mode
processes.
• CNG performs a key error detection check on each transfer of key
– internal and intermediate transfers.
• CNG prevents archiving of expired (private) signature keys and
destroys non-persistent cryptographic keys.
– Windows overwrites each intermediate storage area for plaintext key/critical
cryptographic security parameter
• i.e., any storage, such as memory buffers for the key or plaintext password which was
typed by the user that is included in the path of such data
– This overwriting is performed as follows:
• For volatile memory, the overwrite is a single direct overwrite consisting of zeros using
the RtlSecureZeroMemory function.
– Note that the administrative guidance precludes hibernating the computer so
that the keys are not persisted into volatile storage
41
Types of Keys Used by Windows (1)
Key Description
Symmetric Keys used for AES (FIPS 197) encryption/decryption for
encryption/decryption IPsec ESP, TLS, Wi-Fi.
keys
HMAC keys Keys used for HMAC-SHA1, HMAC-SHA256, HMAC-
SHA384, and HMAC-SHA512 (FIPS 198-1) as part of
IPsec
Asymmetric ECDSA Keys used for the verification of ECDSA digital signatures
Public Keys (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric ECDSA Keys used for the calculation of ECDSA digital signatures
Private Keys (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric RSA Keys used for the verification of RSA digital signatures
Public Keys (FIPS 186-4) for IPsec, TLS, Wi-Fi and signed product
updates.
Asymmetric RSA Keys used for the calculation of RSA digital signatures
Private Keys (FIPS 186-4) for IPsec, TLS, and Wi-Fi as well as TPM-
based health attestations. The key size can be 2048 or
3072 bits. 42
Types of Keys Used by Windows (2)
Key Description
Asymmetric DSA Keys used for the calculation of DSA digital signatures
Private Keys (FIPS 186-4) for IPsec and TLS. The key size can be
2048 or 3072 bits.
Asymmetric DSA Keys used for the verification of DSA digital signatures
Public Keys (FIPS 186-4) for IPsec and TLS. The key size can be
2048 or 3072 bits.
DH Private and Private and public values used for Diffie-Hellman key
ECDH Private and Private and public values used for EC Diffie-Hellman key
DPAPI master secret 512-bit random value used by DPAPI
DPAPI master AES 256-bit encryption key that protects the DPAPI master
key secret
DPAPI AES key 256-bit encryption key used by DPAPI
DRBG seed The seed for the main DRBG, zeroized
43 during reseeding
Networking (TLS)
• The TOE implements TLS to enable a trusted network path that
is used for client and server authentication, as well as HTTPS.
• The protocols are described at:
– MS-TLSP Transport Layer Security (TLS) Profile
– RFC 2246 The TLS Protocol Version 1.0
– RFC 3268 -AES Ciphersuites for TLS
– RFC 3546 Transport Layer Security (TLS) Extensions
– RFC 4366 Transport Layer Security (TLS) Extensions
– RFC 4492 ECC Cipher Suites for TLS
– RFC 4681 TLS User Mapping Extension
– RFC 5246 - The Transport Layer Security (TLS) Protocol, Version 1.2
– RFC 5289 - TLS ECC Suites with SHA-256384 and AES GCM
44
TLS RFCs Implemented by Windows
RFC# Name How Used
2246 The TLS Protocol Version 1.0 Specifies requirements for TLS 1.0.
3268 Advanced Encryption Standard (AES) Specifies additional ciphersuites implemented
Ciphersuites for Transport Layer Security by Windows.
(TLS)
3546 Transport Layer Security (TLS) Extensions Updates RFC 2246 with TLS 1.0 extensions
implemented by Windows.
4346 The Transport Layer Security (TLS) Protocol Specifies requirements for TLS 1.1.
Version 1.1
4366 Transport Layer Security (TLS) Extensions Obsoletes RFC 3546 Requirements for TLS
1.1 extensions implemented by Windows.
4492 Elliptic Curve Cryptography (ECC) Cipher Specifies additional ciphersuites
Suites for Transport Layer Security (TLS) implemented by Windows.
4681 TLS User Mapping Extension Extends TLS to include a User Principal Name
during the TLS handshake.
5246 The Transport Layer Security (TLS) Protocol Obsoletes RFCs 3268, 4346, and 4366.
Version 1.2 Specifies requirements for TLS 1.2.
5289 TLS Elliptic Curve Cipher Suites with SHA- Specifies additional ciphersuites
256/384 and AES Galois Counter Mode implemented by Windows.
(GCM)
SSL3 The SSL Protocol Version 3 45for SSL3.
Specifies requirements
TLS Implementation
• When negotiating a TLS 1.2 elliptic curve cipher suite, Windows
will include automatically as part of the Client Hello message:
– its supported elliptic curves extension, i.e., secp256r1, secp384r1, and
secp521r1
– signature algorithm, i.e., SHA256, SHA384, and SHA512
based on the ciphersuites selected by the administrator.
– By default, the curve secp521r1 is disabled.
• This curve can be enabled adding its name in the ECC Curve Order file.
• In addition, the curve priority can be edited in this file.
• On the other hand, by default the signature algorithms in the
Client Hello message are: SHA1, SHA256, SHA384 and
SHA512.
– The signature algorithm extension is configurable by editing a registry
key to meet with the FCS_TLSC_EXT.3 requirement.
46
TLS Implementation
• Each Windows component that uses TLS checks that the identifying information in the
certificate matches what is expected. These checks include checking the expected
– Distinguished Name (DN),
– Subject Name (SN),
– Subject Alternative Name (SAN) attributes
– along with any applicable extended key usage identifiers.
• The DN, and any Subject Alternative Name, in the certificate is checked against the identity
of the remote computer’s DNS entry or IP address to ensure that it matches as described at
http://technet.microsoft.com/en-us/library/cc783349(v=WS.10).aspx, and in particular the
“Server Certificate Message” section.
• The reference identifier in Windows for TLS is the DNS name or IP address of the remote
server, which is compared against the DNS name as presented identifier in the Subject
Alternative Name (SAN) or the Subject Name of the certificate.
– There is no configuration of the reference identifier.
• A certificate that uses a wildcard in the leftmost portion of the resource identifier (i.e.,
*.contoso.com) can be accepted for authentication, otherwise the certificate will be deemed
invalid.
– Windows does not provide a general-purpose capability to “pin” TLS certificates.
• Windows implements HTTPS as described in RFC 2818 so that Windows Store and system
applications executing on the TOE can securely connect to external servers using HTTPS.
47
Wireless Networking
• Windows has native implementations of IEEE 802.11-2012 and IEEE
802.11ac-2013 to provide secure wireless local area networking (Wi-
Fi).
– Windows can use PRF-384 in WPA2 Wi-Fi sessions and generate AES
128-bit keys or use PRF-704 to generate AES 256-bit keys, both utilize the
Windows RBG.
– Windows complies with the IEEE 802.11-2012 and IEEE 802.11ac-2013
standards and interoperates with other devices that implement the standard.
– Computers running a Windows OS typically have Wi-Fi CERTIFIED
Interoperability Certificates from the Wi-Fi Alliance.
• Windows implements key wrapping and unwrapping according to the
NIST SP 800-38F specification (the “KW” mode) and so unwraps the
Wi-Fi Group Temporal Key (GTK) which was sent by the access
point.
– Because the GTK was protected by AES Key Wrap when it was delivered in
an EAPOL-Key frame, the GTK is not exposed to the network.
48
Protecting Data with DPAPI
• Windows provides the Data Protection API,
DPAPI, which Windows components, first-party
and third-party applications can use to protect
any persisted data which the developer deems
to be sensitive.
– DPAPI will use AES CBC encryption with a key that
is based in part on the user’s password to protect the
user data.
– When storing private keys and secrets associated
with the user account, the encrypted data is stored
on the file system in a directory which is part of the
user’s profile.
49
User Data Protection
• Discretionary Access Control
• VPN Client
50
Discretionary Access Control
• The executive component within the Windows kernel
mediates access between subjects and user data
objects, also known as named objects.
– This kernel component is the Security Reference Monitor
(SRM)
• Subjects consist of processes with one or more
threads running on behalf of users.
• While the Windows Discretionary Access Control
policy manages several different kinds of named
objects, the protection profile that is the basic for this
evaluation focuses on the NTFS File and NTFS
Directory objects.
51
Subject DAC Attributes
• Windows security access tokens contain the security attributes for a
subject.
• Tokens are associated with processes and threads running on behalf of
the user.
• Information in a security access token that is used by DAC includes:
– The Security Identifier (SID) for the user account
– SIDs representing groups for which the user is a member
– Privileges assigned to the user
– An owner SID that identifies the SID to assign as owner for newly created objects
– A default Discretionary Access Control List (DACL) for newly created objects
– Token type which is either a primary or an impersonation token
– The impersonation level (for impersonation tokens)
– The integrity label SID
– An optional list of restricting SIDs
– The logon SID that identifies the logon session.
• An administrator can change all of these except for the user account SID
and logon SID.
52
Impersonation Tokens
• A thread can be assigned an impersonation token that would be
used instead of the process’ primary token when making an access
check and generating audit data.
– Hence, that thread is impersonating the client that provided the
impersonation token.
– Impersonation stops when the impersonation token is removed from the
thread or when the thread terminates.
• An access token may also include a list of restricting SIDs which
are used to limit access to objects.
– Restricting SIDs are contained in restricted tokens
– Restricted tokens is a special form of a thread impersonation token
– When configured, they serve to limit the corresponding process access to
no more than that available to the restricted SID.
• Access decisions are made using the impersonation token of a
thread if it exists, and otherwise the thread’s process primary token
(which always exists).
53
Object DAC Attributes
• Security Descriptors (SDs) contain all of the security attributes associated
with an object.
• All named objects have an associated SD.
• The security attributes from a SD used for discretionary access control are:
– the object owner SID which specifies the owner of the security descriptor,
– the DACL present flag,
– the DACL itself, when present.
• DACLs contain a list of Access Control Entries (ACEs).
• Each ACE specifies
– an ACE type,
– a SID representing a user or group,
– an access mask containing a set of access rights.
• Each ACE has inheritance attributes associated with it that specify if the
ACE applies to the associated object only, to its children objects only, or to
both its children objects and the associated object.
54
Two Types of ACEs
• There are two types of ACEs that apply to discretionary
access control:
– ALLOW ACES
• ACCESS_ALLOWED_ACE: used to grant access to a user or group of
users.
• ACCESS_ALLOWED_OBJECT_ACE: (for DS objects) used to grant
access for a user or group to a property or property set on the directory
service object, or to limit the ACE_inheritance to a specified type of child
object. This ACE type is only supported for directory service objects.
– DENY ACES
• ACCESS_DENIED_ACE: used to deny access to a user or group of
users.
• ACCESS_DENIED_OBJECT_ACE: (for DS objects) used to deny
access for a user or group to a property or property set on the directory
service object or to limit the ACE_inheritance to a specified type of child
object. This ACE type is only supported for directory service objects.
55
Access Mask
• In the ACE, an access mask contains object access rights granted (or
denied) to the SID, representing a user or group.
• An access mask is also used
– to specify the desired access to an object when accessing the object
– and to identify granted access associated with an opened object.
• Each bit in an access mask represents a particular access right.
• There are four categories of access rights: standard, specific, special, and
generic.
– Standard access rights apply to all object types.
– Specific access rights have different semantic meanings depending on the type of
object.
– Special access rights are used in desired access masks to request special access
or to ask for all allowable rights.
– Generic access rights are convenient groupings of specific and standard access
rights.
• Each object type provides its own mapping between generic access rights
and the standard and specific access rights.
56
Handle Tables
• For most objects, a subject requests access to the object (e.g., opens it)
and receives a pointer to a handle in return.
• The TSF associates a granted access mask with each opened handle.
• For kernel-mode objects,
– Handles are maintained in a kernel-mode handle table.
– There is one handle table per process.
– Each entry in the handle table identifies an opened object and the access rights
granted to that object.
• For user-mode TSF servers,
– The handle is a server-controlled context pointer associated with the connection
between the subject and the server.
– The server uses this context handle in the same manner as with the kernel
mode
• (i.e., to locate an opened object and it’s associated granted access mask).
• In both cases (user and kernel-mode objects), the SRM makes all
access control decisions.
57
DAC Access Rights and Named Objects
NTFS Directory NTFS File
ACCESS_SYSTEM_SECURITY ACCESS_SYSTEM_SECURITY
READ_CONTROL READ_CONTROL
WRITE_DAC WRITE_DAC
WRITE_OWNER WRITE_OWNER
SYNCHRONIZE SYNCHRONIZE
FILE_LIST_DIRECTORY FILE_WRITE_DATA
FILE_ADD_FILE FILE_READ_DATA
FILE_ADD_SUBDIRECTORY FILE_APPEND_DATA
FILE_DELETE_CHILD FILE_WRITE_EA
FILE_READ_ATTRIBUTES FILE_EXECUTE
FILE_WRITE_ATTRIBUTES FILE_READ_ATTRIBUTES
FILE_DELETE_CHILD | FILE_ADD_FILE FILE_WRITE_ATTRIBUTES
DELETE FILE_WRITE_DATA and FILE_WRITE_ATTRIBUTES
DELETE
FILE_WRITE_DATA | FILE_READ_DATA
FILE_READ_DATA | FILE_EXECUTE
FILE_READ_DATA | FILE_EXECUTE |
FILE_WRITE_DATA
FILE_WRITE_DATA | FILE_WRITE_EA |
FILE_WRITE_ATTRIBUTES
58
DAC Enforcement Algorithm
• The TSF enforces the DAC policy to objects based on
– SIDs and privileges in the requestor’s token,
– the desired access mask requested,
– the object’s security descriptor.
• In order for access to be granted, all access rights specified in the desired
access mask must be granted by one of the following steps
1.Privilege Check
2.Owner Check
3.DACL not present
4.DACL present but empty
5.Iteratively process each ACE in the order that they appear in the DACL
6.Access check against the restricting SIDs
• At the end of any step, if all of the requested access rights have been
granted then access is allowed.
• At the end of the algorithm, if any requested access right has not been
granted, then access is denied.
59
DAC Enforcement Algorithm (1)
1. Privilege Check:
a)Check for SeSecurity privilege: This is required if ACCESS_SYSTEM_SECURITY is in
the desired access mask.
• If ACCESS_SYSTEM_SECURITY is requested and the requestor does not have this privilege, access
is denied.
• Otherwise ACCESS_SYSTEM_SECURITY is granted.
b)Check for SeTakeOwner privilege:
• If the desired mask has WRITE_OWNER access right, and the privilege is found in the requestor’s
token, then WRITE_OWNER access is granted.
c)Check for SeBackupPrivilege: The Backup Files and Directories privilege allows a subject
process to read files and registry objects for backup operations regardless of their ACE in
the DACL.
• If the subject process has the SeBackupPrivilege privilege and the operation requires the privilege, no
further checking is performed and access is allowed.
• Otherwise this check is irrelevant and the access check proceeds.
d)Check for SeRestorePrivilege: The Restore Files and Directories privilege allows a
subject process to write files and registry objects for restore operations regardless of their
ACE in the DACL.
• If the subject process has the SeRestorePrivilege privilege and the operation requires the privilege no
further checking is performed, and access is allowed.
• Otherwise this check is irrelevant and the access check proceeds.
60
2. Owner Check:
a)If the DACL contains one or more ACEs with the OwnerRights SID, those entries, along
with all other applicable ACEs for the user, are used to determine the owner's rights.
b)Otherwise, check all the SIDs in the token to determine if there is a match with the
object owner. If so, the READ_CONTROL and WRITE_DAC rights are granted if
requested.
3. DACL not present:
All further access rights requested are granted.
4. DACL present but empty:
If any additional access rights are requested, access is denied.
5. Iteratively process each ACE in the order that they appear in the DACL as
described below:
a)If the inheritance attributes of the ACE indicate the ACE is applicable only to children
objects of the associated object, the ACE is skipped.
b)If the SID in the ACE does not match any SID in the requestor’s access token, the ACE
is skipped.
c)If a SID match is found, and the access mask in the ACE matches an access in the
desired access mask (see the next slide)
61
i. Access Allowed ACE Types:
– If the ACE is of type ACCESS_ALLOWED_OBJECT_ACE and the ACE includes a GUID
representing a property set or property associated with the object, then the access is
granted to the property set or specific property represented by the GUID (rather than to the
entire object).
– Otherwise the ACE grants access to the entire object.
ii. Access Denied ACE Type:
– If the ACE is of type ACCESS_DENIED_OBJECT_ACE and the ACE includes a GUID
representing a property set or property associated with the object, then the access is
denied to the property set or specific property represented by the GUID.
– Otherwise the ACE denies access to the entire object.
– If a requested access is specifically denied by an ACE, then the entire access request fails.
6. Restricting SIDs check:

– If all accesses are granted but the requestor’s token has at least one
restricting SID, the complete access check is performed against the
restricting SIDs.
– If this second access check does not grant the desired access, then
the entire access request fails.
62
Default DAC Protection
• The TSF provides a process ensuring a DACL is applied by default to
all new objects.
– When new objects are created, the appropriate DACL is constructed.
• The methods used to build a DACL for a new DS object and for a new
named kernel objects are slightly different. There are two key
differences, which are as follows:
– For DS objects, the rules for creating a DACL distinguish between generic
inheritable ACEs and object-specific inheritable ACEs in the parent object's
SD.
• Generic inheritable ACEs can be inherited by all types of child objects.
• Object-specific inheritable ACEs can be inherited only by the type of child object to
which they apply.
– The AD schema definition for the object can include a SD.
• Each object class defined in the schema has a defaultSecurityDescriptor attribute.
• If neither the creating process nor inheritance from the parent object provides a DACL
for a new AD object, the TOE uses the DACL in the default SD specified by the schema.
63
Rules to Set the DACL in the SDs
for New Named Kernel Objects
• The object's DACL is the DACL from the SD specified by the creating process.
– The TOE merges any inheritable ACEs into the DACL unless SE_DACL_PROTECTED is set in the SD
control flags.
– The TOE then sets the SE_DACL_PRESENT SD control flag.
• Note that a creating process can explicitly provide a SD that includes no DACL. The result will be an object with no
protections. This is distinct from providing no SD.
• If the creating process does not specify a SD,
– The TOE builds the object's DACL from inheritable ACEs in the parent object's DACL.
• If the parent object has no inheritable ACEs,
– The TOE uses its object manager subcomponent to provide a default DACL.
– The TOE then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
• If the object manager does not provide a default DACL,
– The TOE uses the default DACL in the subject's access token.
– The TOE then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
– The subject's access token always has a default DACL, which is set by the LSA subcomponent when the
token is created.
• All tokens are created with an appropriate default DACL, which can be applied to the new objects as appropriate.
• The default DACL is restrictive in that it only allows the SYSTEM SID and the user SID that created the object to have
access. The SYSTEM SID is a special SID representing TSF trusted processes.
64
Rules to Set the DACL in the SD
for New DS Objects
• The object's DACL is the DACL from the SD specified by the creating process.
– The TOE merges any inheritable ACEs into the DACL unless SE_DACL_PROTECTED is set in the SD
control flags.
• If the creating process does not specify a SD,
– The TOE checks the parent object's DACL for inheritable object-specific ACEs that apply to the type of
object being created.
– If the parent object has inheritable object-specific ACEs for the object type, the TOE builds the object's
DACL from inheritable ACEs, including both generic and object-specific ACEs.
– It then sets the SE_DACL_PRESENT SD control flag
• If the parent object has no inheritable object-specific ACEs for the type of object being
created,
– The TOE uses the default DACL from the AD schema for that object type.
– It then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
• If the AD schema does not specify a default DACL for the object type,
– the TOE uses the default DACL in the subject's access token.
– It then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
– The subject's access token always has a default DACL, which is set by the LSA subcomponent when
the token is created.
65
DAC Management
• The following are the four methods that DACL
changes are controlled:
– Object owner: Has implicit WRITE_DAC access.
– Explicit DACL change access: A user granted explicit
WRITE_DAC access on the DACL can change the DACL.
– Take owner access: A user granted explicit
WRITE_OWNER access on the DACL can take
ownership of the object and then use the owner’s implicit
WRITE_DAC access.
– Take owner privilege: A user with SeTakeOwner privilege
can take ownership of the object and then user the
owner’s implicit WRITE_DAC access.
66
Reference Mediation
• Access to objects on the system is generally predicated on obtaining a
handle to the object.
– Handles are usually obtained as the result of opening or creating an object.
• In these cases, the TSF ensures that access validation occurs before creating a new handle
for a subject.
– Handles may also be inherited from a parent process or directly copied (with
appropriate access) from another subject.
• In all cases, before creating a handle, the TSF ensures that that the security policy allows the
subject to have the handle (and thereby access) to the object.
– A handle always has a granted access mask associated with it.
• This mask indicates, based on the security policy, which access rights to the object that the
subject was granted.
• On every attempt to use a handle, the TSF ensures that the action requested is allowed
according to the handle’s granted access mask.
• In a few cases, such as with DS, objects are directly accessed by name
without the intermediate step of obtaining a handle first.
– In these cases, the TSF checks the request against the access policy directly
(rather than checking for a granted access mask).
67
VPN Client (1)
• The Windows IPsec VPN client can be configured by
the device local administrator.
– The administrator can configure the IPsec VPN client that all
IP traffic is routed through the IPsec tunnel except for:
• IKE traffic used to establish the VPN tunnel
• IPv4 ARP traffic for resolution of local network layer addresses and
to establish a local address
• IPv6 NDP traffic for resolution of local network layer addresses and
to establish a local address
• The IPsec VPN is an end-to-end internetworking
technology
– VPN sessions can be established over physical network
protocols such as wireless LAN (Wi-Fi) or local area network.
68
VPN Client (2)
• The components responsible for routing IP traffic through the VPN
client:
– The IPv4 / IPv6 network stack in the kernel processes ingoing and
outgoing network traffic.
– The IPsec and IKE and AuthIP Keying Modules service which hosts
the IKE and Authenticated Internet Protocol (AuthIP) keying modules.
• These keying modules are used for authentication and key exchange in Internet
Protocol security (IPsec).
– The Remote Access Service device driver in the kernel, which is used
primarily for VPN connections; known as the “RAS IPsec VPN” or “RAS
VPN”.
– The IPsec Policy Agent service which enforces IPsec policies.
• Universal Windows App developers can implement their own VPN
client if authorized by Microsoft to use the networkingVpnProvider
capability, which includes setting the policy to lockdown networking
traffic as described above
69
Identification and Authentication (1)
• Windows 10, Windows 10 S, and Windows Server can authenticate
users based on
– username and password
– using a Windows Hello PIN which is backed by a TPM
• Windows 10 and Windows Server can also use physical or virtual
smart card thus supporting multiple user authentication.
• All logons are treated essentially in the same manner regardless of
their source
– interactive logon,
– network interface,
– internally initiated service logon
and start with
– an account name,
– domain name (which may be NULL; indicating the local system),
– and credentials that must be provided to the TSF.
70
• Password-based authentication to Windows succeeds when the
credential provided by the user matches the stored protected
representation of the password
• Windows Hello and smart cards both use PIN-based authentication
to unlock a protected resource, a private key, the stored
representation of the PIN is protected by the Secure Kernel.
• Password authentication can be used for
– interactive logons,
– service logons,
– network logons,
– and to initiate the “change password” screen
• The Windows Hello PIN, physical and virtual smart cards can be
used for interactive logons
• The Windows Hello PIN is used to re-authenticate the user when
the user chooses to change their PIN.
71
• When the authentication succeeds,
– the user will be logged onto their desktop,
– their screen unlocked,
– or their authentication factors changed
depending whether
– the user logged onto the computer,
– the display was locked,
– or the PIN or password was to be changed.
72
• The Local Security Authority (LSA) component within Windows
maintains a count of the consecutive failed logon attempts by
security principals from their last successful authentication.
• When the number of consecutive failed logon attempts is larger than
the policy for failed logon attempts, which ranges from 0 (never
lockout the account) to 999, Windows will lockout the user account.
• Windows persists the number of consecutive failed logons on for the
user and so rebooting the computer does not reset the failed logon
counter.
• Interactive logons are done on the secure desktop, which does not
allow other programs to run, and therefore prevents automated
password guessing.
• In addition, the Windows logon component enforces a one second
delay between every failed logon with an increased delay after
several consecutive logon failures.
73
X.509 Certificate Validation and Generation (1)
• Every Windows component that uses X.509 certificates is responsible
for performing certificate validation
– However all components use a common system subcomponent, which
validates certificates as described in RFC 5280, and particular, the specific
validation listed in section 5.1.4.4, including all applicable usage constraints
such as Server Authentication for networking sessions and Code Signing
when installing product updates.
• Every component that uses X.509 certificates will have a repository for
public certificates and will select a certificate based on criteria such as
– entity name for the communication partner,
– any extended key usage constraints,
– and cryptographic algorithms associated with the certificate.
• The Windows component will use the same kinds of information along
with a certification path and certificate trust lists as part of deciding to
accept the certificate.
74
X.509 Certificate Validation and Generation (2)
• If certificate validation fails, or if Windows is not able to check the
validation status for a certificate, Windows will not establish a trusted
network channel,
– It will inform the user and seek their consent before establishing a HTTPS web
browsing session.
– Certification validation for updates to Windows, mobile applications, and
integrity verification is mandatory,
• neither the administrator nor the user have the option to bypass the results of a failed
certificate validation
• software installation and updates is further described in Windows and Application
Updates.
• When Windows needs to generate a certificate enrollment request it will
include
– a distinguished name,
– information about the cryptographic algorithms used for the request,
– any certification extensions,
– and information about the client requesting the certificate.
75
Certificate Storage
• In a Windows OS, stored certificates known as trusted root
certificates are contained in certificate stores.
• Each user has their own certificate store and there is a
certificate store for the computer account;
– access to a certificate store is managed by the discretionary access
control policy in Windows such that only the authorized
administrator, i.e., the user or the local administrator, can add or
remove entries.
• Certificates which are used by applications, for example, TLS,
are also placed in certificate stores for the user.
• In addition to the standard certificate revocation processes,
application certificates can be loaded by either using
administrative tools such as certutil.exe, changes to the trusted
root certificates can be made using Certificate Trust Lists.
76
Security Management
Management Function Administrator User
Enable/disable screen lock √ √
Configure screen lock inactivity timeout √ √
Configure local audit storage capacity √
Configure minimum password length √
Configure minimum number of special characters in password
Configure minimum number of numeric characters in password
Configure minimum number of uppercase characters in password
Configure minimum number of lowercase characters in password
Configure remote connection inactivity timeout √
Enable/disable unauthenticated logon
Configure lockout policy for unsuccessful authentication attempts √
through (timeouts between attempts, limiting number of attempts
during a time period)
Configure host-based firewall √
Configure name/address of directory server to bind with √
77
Security Management
Management Function Administrator User
Configure name/address of remote management server from √
which to receive management settings
Configure name/address of audit/logging server to which
to send audit/logging records
Configure audit rules √
Configure name/address of network time server √
Enable/disable automatic software update √
Configure Wi-Fi interface √
Enable/disable Bluetooth interface √
Configure USB interfaces √
Enable/disable local area network interface √
78
Protection of the TSF
• Separation and Domain Isolation
• Protection of OS Binaries, Audit and
Configuration Data
• Protection From Implementation Weaknesses
• Windows Platform Integrity and Code Integrity
• Windows and Application Updates
79
Separation and Domain Isolation
• The TSF provides a security domain for its own
protection and provides process isolation.
• The security domains used within and by the
TSF consists of the following:
– Hardware
– Virtualization Partitions
– Kernel-mode software
– Trusted user-mode processes
– User-mode Administrative tools process
– Application Containers
80
TSF Hardware and Kernel-Mode
Software
• The TSF hardware is managed by the TSF kernel-mode software and is
not modifiable by untrusted subjects.
• The TSF kernel-mode software is protected from modification by
hardware execution state and protection for both physical memory and
memory allocated to a partition;
– an operating system image runs within a partition.
• The TSF hardware provides a software interrupt instruction that causes a
state change from user mode to kernel mode within a partition.
• The TSF kernel-mode software is responsible for processing all
interrupts, and determines whether or not a valid kernel-mode call is
being made.
– In addition, the TSF memory protection features ensure that attempts to access
kernel-mode memory from user mode results in a hardware exception, ensuring
that kernel-mode memory cannot be directly accessed by software not executing
in the kernel mode.
81
User-Mode Processes Isolation
• The TSF provides process isolation for all user-mode processes
through
– private virtual address spaces (private per process page tables),
– execution context (registers, program counters),
– security context (handle table and token).
The data structures defining process address space, execution
context and security context are all stored in protected kernel-
mode memory.
• All security relevant privileges are considered to enforce TSF
Protection.
• User-mode administrator tools execute with the security
context of the process running on behalf of the authorized
administrator.
– Administrator processes are protected like other user-mode processes,
by process isolation.
82
Application Containers
• Application Containers (“App Containers”) provide an
execution environment for Universal Windows Applications
– it prevents Universal Windows Applications from accessing data
created by other Universal Windows Applications except through
brokered operating system services such as the File Picker dialog.
• Like TSF processes, user processes also are provided a private
address space and process context,
– therefore are protected from each other.
• Additionally, the TSF has the added ability to protect memory
pages using Data Execution Prevention (DEP)
– It marks memory pages in a process as non-executable unless the
location explicitly contains executable code.
– When the processor is asked to execute instructions from a page
marked as data, the processor will raise an exception for the OS to
handle.
83
Cryptographic Protection
• The TSF implements cryptographic mechanisms within a distinct user-mode
process, where its services can be accessed by both kernel- and user-mode
components, in order to isolate those functions from the rest of the TSF to
limit exposure to possible errors while protecting those functions from
potential tampering attempts.
• Furthermore, the TSF includes a Code Integrity Verification feature, also
known as Kernel-mode code signing (KMCS), whereby device drivers will
be loaded only if they are digitally signed by either Microsoft or from a trusted
root certificate authority recognized by Microsoft.
– KMCS uses public-key cryptography technology to verify the digital signature of each
driver as it is loaded.
– When a driver tries to load, the TSF decrypts the hash included with the driver using
the public key stored in the certificate.
– It then verifies that the hash matches the one that it computes based on the driver code
using the FIPS-certified cryptographic libraries in the TSF.
– The authenticity of the certificate is also checked in the same way, but using the
certificate authority's public key, which must be configured in and trusted by the TOE.
84
Protection of OS Binaries, Audit
and Configuration Data
• By default, a Windows operating system is installed into the \Windows\ directory of
the first bootable storage partition for the computer.
– The logical name for this directory is %systemRoot%.
• The kernel, device drivers (.sys files), system executables (.exe files) and dynamically
loadable libraries (.dll files) are stored in the \%systemRoot%\system32 directory
and subdirectories below system32.
– Standard users have permissions to read and execute these files, however modify and write
permissions are limited to the local administrator and system service accounts.
• The root directory for audit logs is %systemRoot%\system32\winevt.
– The local administrator, Event Log service, and the system account have full control over the
audit files; standard users are not authorized to access the logs.
• The primary configuration data store for Windows is the registry
– There are separate registry hives for the computer itself and each user authorized to use the
computer.
– The registry hives for operating system configuration data is located at %systemRoot%\
system32\config; the registry hive for the user is located in the user’s profile home directory.
– Registry files use the same protection scheme as event log files.
85
Protection From Implementation
Weaknesses (1)
• The Windows kernel, user-mode applications, and all Windows Store
Applications implement Address Space Layout Randomization (ASLR)
in order to load executable code at unpredictable base addresses.
– The base address is generated using a pseudo-random number generator that is
seeded by high quality entropy sources when available which provides at least 8
random bits for memory mapping.
• The Windows runtime also provides stack buffer overrun protection
capability that will terminate a process after Windows detects a potential
buffer overrun on the thread’s stack by checking canary values in the
function prolog and epilog as well as reordering the stack.
• All Windows binaries and Windows Store Applications implement stack
buffer overrun protection by
– being complied with the /GS option, and
– checking that all Windows Store Applications are compiled with buffer overrun
protection before ingesting the Windows Store Application into the Windows Store.
86
Protection From Implementation
Weaknesses (2)
• To enable these protections using the Microsoft Visual
Studio development environment, programs are complied
with
– /DYNAMICBASE option for ASLR,
– and optionally with /HIGHENTROPYVA for 64-bit ASLR,
– or /NXCOMPAT:NO to opt out of software-based DEP,
– and /GS (switched on by default) for stack buffer overrun
protection.
• Windows Store Applications are compiled with the
/APPCONTAINER option which builds the executable to
run in a Windows appcontainer, to run with the user-mode
protections described in this section.
87
Windows Platform Integrity and
Code Integrity
• A Windows operating system verifies the integrity of
Windows program code using the combination of Secure
Boot and Code Integrity capabilities in Windows.
• On computers with a Trusted Platform Module (TPM),
before Windows will boot, the computer will verify the
integrity of the early boot components, which includes
– the Boot Loader,
– the OS Loader,
– and the OS Resume binaries.
• This capability is known as Secure Boot
88
Secure Boot (1)
• The Secure Boot checks that the file integrity of early boot
components has not been compromised, mitigating the risk of
rootkits and viruses, and additionally checks that critical boot-
time data have not been modified.
– Secure Boot collects these file and configuration measurements and
seals them to the TPM.
– When Secure Boot starts in the preboot environment, it will compare
the sealed values from the TPM to the measured values from the
current boot cycle
– If those values do not match the sealed values, Secure Boot will lock
the system (which prevents booting) and display a warning on the
computer display.
• While the TPM is part of the external IT environment, the hardware-protected
hashes serve as the first step of the chain that provides integrity from the
hardware, through the bootchain into the kernel and required device drivers.
89
Secure Boot (2)
– When the measurements match, the UEFI firmware will load the OS
Boot Manager, which is an Authenticode-signed image file, based on
the Portable Executable (PE) image file format.
• A SHA-256 hash based signature and a public key certificate chain are
embedded in the boot manager Authenticode signed image file under the
“Certificate” IMAGE_DATA_DIRECTORY of the IMAGE_OPTIONAL_HEADER
of the file.
• This public key certificate chain ends in a root public key.
– The boot manager uses the embedded SHA-256 hash based
signature and public key certificate chain to validate its own integrity. A
SHA-256 hash of the boot manager image file is calculated for the
whole file, with the exception of the following three elements which are
excluded from the hash calculation:
• the CheckSum field in the IMAGE_OPTIONAL_HEADER,
• the IMAGE_DIRECTORY_ENTRY_SECURITY, IMAGE_DATA_DIRECTORY,
• and the public key certificate table, which always resides at the end of the
image file.
90
Secure Boot (3)
– If the boot manager is validated, then the root public key of the
embedded public key certificate chain must match one of the Microsoft
root public keys which indicate that Microsoft is the publisher of the
boot manager.
• These root public keys are necessarily hardcoded in the boot manager.
– If the boot manager cannot validate its own integrity, then the boot
manager does not continue to load other modules and displays an
error message.
– After the boot manager determines its integrity, it attempts to load one
application from the following list of boot applications:
• OS Loader: (Winload.exe or Winload.efi): the boot application started by the
boot manager load the Windows kernel to start the boot process
• OS Resume (winresume.exe or winresume.efi): the boot application started by
the boot manager to resume the instance of the executing OS which is
persisted in the hibernation file “hiberfil.sys”
• A physical memory testing application (memtest.exe) to check the physical
memory ICs for the machine are working correctly.
91
Secure Boot (4)
– These boot applications are also Authenticode signed image files and
so, the Boot Manager uses the embedded trusted SHA-256 hash
based signature and public key certificate chain within the boot
application’s IMAGE_OPTIONAL_HEADER to validate the integrity of
the boot application before attempting to load it.
– Except for three elements which are excluded from the hash
calculation (these are the same three elements mentioned above in
the Boot Manager description), a hash of a boot application image file
is calculated in the same manner as for the Boot Manager.
– If the boot application is validated, then the root public key of the
embedded public key certificate chain must match one of the
hardcoded Microsoft’s root public keys.
– If the boot manager cannot validate the integrity of the boot
application, then the boot manager will not load the boot application
and instead displays an error message below along with the full name
of the boot application that failed the integrity check.
92
Secure Boot (5)
– After the boot application’s integrity has been determined, the
boot manager attempts to load the boot application. If the boot
application is successfully loaded, the boot manager then
transfers execution to the loaded application.
– After the Winload boot application is loaded, it receives the
transfer of execution from the boot manager.
• During its execution, Winload attempts to load the Windows kernel
(ntoskrnl.exe) together with a number of early-launch drivers.
– Among the modules that Winload must validate in the Portable
Executable (PE) image file format, are the cryptography-related
modules listed below
• The Windows kernel (ntoskrnl.exe)
• The BitLocker drive encryption filter driver (fvevol.sys)
• The Windows kernel cryptography device driver (cng.sys)
• The Windows code integrity library module (ci.dll)
93
Secure Boot (6)
– The four image files above have their trusted SHA hashes stored in
catalog files that reside in the local machine catalog directory
• Because they are PKCS #7 SignedData messages, catalog files are signed
• The root public key of the certificate chain used to verify the signature of a
Microsoft’s catalog file must match one of the Microsoft’s root public keys
indicating that Microsoft is the publisher of the Windows image files
• These Microsoft’s root public keys are hardcoded in the Winload boot application
– If the image files are validated, their SHA-256 hashes, as calculated by
the Winload boot application, must match their trusted SHA-256 hashes
in a Microsoft’s catalog file, which has been verified by the Winload boot
application
– A hash of an image file is calculated for the whole file, with the exception
of the following three elements which are excluded from the hash
calculation:
• the CheckSum field in the IMAGE_OPTIONAL_HEADER,
• the IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DATA_DIRECTORY,
• the public key certificate table, which always resides at the end of the image file.
94
Secure Boot (7)
– Should the Winload boot application be unable to validate the integrity of
one of the Windows image files, the Winload boot application does not
continue to load other Windows image files
• Rather it displays an error message and fails into a non-operational mode
• In limited circumstances the pre-boot environment will attempt to repair the boot
environment, such as copying files from a repair partition to repair files with integrity
errors
• When repair is not possible, the boot manager will ask the user to reinstall Windows
– After the initial device drivers have been loaded, the Windows kernel will
continue to boot the rest of the operating system using the Code Integrity
capability (ci.dll) to measure code integrity for
• (1) the remaining kernel-mode and user-mode programs which need to be loaded for
the OS to complete its boot and
• (2) after booting, CI also verifies the integrity of applications launched by the user
(applications from Microsoft are always signed by Microsoft, and third-party
applications which may be signed by the developer) by checking the RSA signature
for the binary and SHA-256 hashes of the binary which are compared to the catalog
files described above.
95
Kernel-mode code signing (KMCS)
• Kernel-mode code signing (KMCS), also managed by CI, prevents kernel-
mode device drivers, such as the TCIP/IP network driver (tcpip.sys), from
loading unless they are published and digitally signed by developers who
have been vetted by one of a handful of trusted certificate authorities
(CAs).
– KMCS, using public-key cryptography technologies, requires that kernel-mode
code include a digital signature generated by one of the trusted certificate
authorities
– When a kernel device driver tries to load, Windows decrypts the hash included
with the driver using the public key stored in the certificate, then verifies that the
hash matches the one computed with the code
– The authenticity of the certificate is checked in the same way, but using the
certificate authority's public key, which is trusted by Windows
– The root public key of the certificate chain that verifies the signature must match
one of the Microsoft’s root public keys indicating that Microsoft is the publisher of
the Windows image files
– These Microsoft’s root public keys are hardcoded in the Windows boot loader
96
Windows File Protection
• Windows File Protection maintains a set of protected
files that are stored in a cache along with cryptographic
hashes of each of those files
• Once the system is initialized, Windows File Protection
is loaded and will scan the protected files to ensure
they have valid cryptographic hashes
• Windows File Protection also registers itself to be
notified should any of the protected files be modified so
that it can recheck the cryptographic checksum at any
point while the system is operational
• Should the any of the cryptographic hash checks fail,
the applicable file will be restored from the cache
97
Windows and Application Updates (1)
• Updates to Windows are delivered as Microsoft Update Standalone
Package files (.msu files) which are signed by Microsoft with two digital
signatures,
– a RSA SHA1 signature for legacy applications
– a RSA SHA-256 signature for modern applications.
The digital signature is signed by Microsoft Corporation, with a certification
path through a Microsoft Code Signing certificate and ultimately the Microsoft
Root Certification Authority.
– These certificates are checked by the Windows Trusted Installer prior to installing the
update.
• The Windows operating system will check that the certificate is valid and has
not been revoked using a standard PKI CRL.
– Once the Trusted Installer determines that the package is valid, it will update Windows;
– otherwise the installation will abort and there will be an error message in the event log.
• Note that the Windows installer will not install an update if the files in the
package have lower version numbers than the installed files.
98
Windows and Application Updates (2)
• The integrity of the Microsoft Code Signing certificate on the computer is
protected by the storage root key within the TPM, and the validated integrity
of the Windows binaries as a result of Secure Boot and Code Integrity.
• Updates to the Windows operating system, Windows applications, and
Microsoft desktop applications are delivered through the
– Windows Update capability (for Windows) and
– Microsoft Update (for Microsoft desktop applications),
which is enabled by default
or the user can go to http://catalog.update.microsoft.com to search and obtain
security updates on their own volition.
• A user can then check that the signature is valid either by viewing the digital
signature details of the file from Windows Explorer or by using the Get-
AuthenticodeSignature PowerShell Cmdlet.
– If the Get-AuthenticodeSignature PowerShell Cmdlet or Windows Explorer could not
verify the signature, the status will be marked as invalid.
– This verification check uses the same functionality described above.
99
Windows Store Applications
• Universal Windows Platform (UWP) apps can be downloaded
from the Microsoft Store and their installation packages are
verified using a digital signature from Microsoft Corporation with
the Code Signing usage.
– These applications are contained in either AppX packages, or a
collection of AppX packages known as an AppX bundle.
– The AppX package uses the Open Packaging Conventions (OPC)
standard.
– Each package contains a directory file which lists the other files in the
package, a digital signature for the package, a block map representing
the application files which may be installed on the target computer, and
the application files themselves.
• The AppX Deployment Service will verify the RSA SHA-256
digital signature for the block map and the other AppX metadata
at the beginning of the AppX package (or bundle) download.
100
Distributing Updates
• There are several distribution channels for
updates to Windows and Windows applications:
– Windows Update: Windows Update is the web service
for delivering Windows updates directly to consumers.
– Windows Server Update Services (WSUS): WSUS is
a server role in Windows Server which IT
administrators can use to distribute application updates
to users within their enterprise.
– Windows Store: The Windows Store is a web service
for delivering updates to Universal Windows Platform
apps which were originally installed from the Windows
Store.
101
TOE Access (1)
• Windows provides the ability for a user to lock their interactive logon
session at their own volition or after a user-defined inactivity timeout.
• Windows also provides the ability for the administrator to specify the
interval of inactivity after which the session will be locked.
– This policy will be applied to either the local machine or the computers within a
domain using either local policy or group policy respectively.
– If both the administrator and a standard user specify an inactivity timeout period,
Windows will lock the session when the shortest time period expires.
• Once a user has a desktop session, they can invoke the session locking
function by using the same key sequence used to invoke the trusted
path (Ctrl+Alt+Del).
– This key sequence is captured by the TSF and cannot be intercepted or altered
by any user process.
– The result of that key sequence is a menu of functions, one of which is to lock
the workstation.
– The user can also lock their desktop session by going to the Start screen,
selecting their logon name, and then choosing the “Lock” option.
102
TOE Access (2)
• Windows constantly monitors the mouse, keyboard, touch
display, and the orientation sensor for inactivity in order to
determine if they are inactive for the specified time period.
• After which, Windows will lock the workstation and execute
the screen saver unless the user is streaming video such as a
movie.
– Note that if the workstation was not locked manually, the TSF will
lock the display and start the screen saver program if and when the
inactivity period is exceeded
– It will also display any notifications from applications which have
registered to publish the application’s badge or the badge with
associated notification text to the locked screen.
– The user has the option to not display any notifications, or choose
one Windows Store Application to display notification text, and
select other applications display their badge.
103
TOE Access (3)
• After the computer was locked, in order to unlock their session, the user either
presses a key or swipes the display.
– The user must provide the Ctrl+Alt+Del key combination if the Interactive Logon: Do
not required CTRL+ALT+DEL policy is set to disabled.
Either action will result in an authentication dialog.
• The user must then re-enter their authentication data, which has been cached
by the local system from the initial logon, after which the user’s display will be
restored and the session will resume.
– Alternately, an authorized administrator can enter their administrator identity and
password in the authentication dialog.
– If the TSF can successfully authenticate the administrator, the user will be logged off,
rather than returning to the user’s session, leaving the workstation ready to
authenticate a new user.
• As part of establishing the interactive logon session, Windows can be
configured to display a logon banner, which is specified by the administrator,
that the user must accept prior to establishing the session.
• As described in the administrator guidance, an authorized adminstator can
specify which Wi-Fi networks (SSIDs) a computer may be connected to.
104
Trusted Channels
• Windows provides trusted network channels to communicate with supporting
IT infrastructure or applications:
– Using TLS (HTTPS) for certificate enrollment; CRL checking; authentication to
network resources such as web (HTTPS) and directory (LDAP-S) servers; and
management via configuration sevrice providers in Windows that are local interface
for processing Mobile Device Management (MDM) requests.
– Using DTLS for datagram-based services and web browsing using a DTLS version
which is specified by the client application.
• In order to establish a trusted channel, these communications are protected
as described above
• The remote access can be performed through the following methods:
– Connect to another computer using Remote Desktop Connection
– PowerShell Remoting
• Both methods use TLS (1.2) protocol for establishing the remote connection.
• Windows implements IEEE 802.11-2012, IEEE 802.1X and EAP-TLS to
provide authenticated wireless networking sessions when requested by the
user as described above in Wireless Networking.
105
Безпека
операційних систем і
комп'ютерних мереж
Довідковий матеріал
Для добавления до лекцій
текста
9-10 (Засоби
щелкните захисту Linux)
мышью
Витяг з Red Hat Enterprise Linux (v.7.1);
SUSE Linux Enterprise Server (v.12);
Oracle Linux (v.7.3); Ubuntu (16.04 LTS)
Security Targets
Вступ
■ Як і для Windows, розглянемо функції безпеки Linux за документами
Security Target (ST), що готували для оцінювання окремих
дистрибутивів Linux за стандартом Common Critera
■ Оцінювання (з наступною сертифікацією) проводили для різних
дистрибутивів, серед яких
● Red Hat Enterprise Linux (v.7.1)
● SUSE Linux Enterprise Server (v.12)
● Oracle Linux (v.7.3)
● Wind River Linux Secure (v.1.0)
● Ubuntu (16.04 LTS)
■ Багато підрозділів опису функцій безпеки зазначених продуктів в
різних ST повторюються дослівно, що свідчить про те, що за основу
береться один документ, розроблений для Linux взагалі, а не для
окремих дистрибутивів
■ Однак є суттєві відмінності, пов’язані як з відмінностями функцій
дистрибутивів, так і з комплектацією відповідних TOE
2
Required Hardware (1)
■ Red Hat Enterprise Linux 7.1:
● HP
□ based on x86 64bit Intel Xeon processors: HP Proliant ML, DL, BL, SL series G7, Gen8, Gen9 product
line
□ based on AMD64 processors: HP Proliant ML, DL, BL, SL series G7, Gen8 product line
● Dell based on x86 64bit Intel:

□ Dell
PowerEdge R920, R930, M620, M520, M420, T430, T630, R430, R530, R630, R730, R730xd, M630,
M830, FC430, FC630, FC830, C6320, and Precision R7910
● IBMSystem p based on Power 8 processors providing execution environments with
PowerVM:
□ Big Endian with PowerVM: Tuleta BE model number - Power 835 model 8286-41A
□ Little Endian with RHEV for Power 3.6: Power 835 model 8284-22A
● IBM System z based on z/Architecture processors:

□ zEnterprise EC12 (zEC12), BC12 (zBC12), 196 (z196), 114 (z114)
● The following virtual environment is allowed as an execution environment for the TOE:
□ KVM on x86 hardware as provided by RHEL 7 or later
□ KVM on POWER LE hardware as provided by RHEV-H 3.6 or later
■ All hardware must be configured using a RAM with automated error correction
mechanism present. For example ECC RAM would be suitable to cover that
requirement.
3
Required Hardware (2)
■ SUSE Linux Enterprise Server 12:
● HP based on x86 64bit Intel Xeon processors: HP ProLiant BL460c G1
● HP based on X86 64bit AMD Opteron processors: HP ProLiant BL465c G1
● IBM System z based on z/Architecture processors: zEnterprise EC12 (zEC12), BC12
(zBC12), 196 (z196), 114 (z114)
Note: all x86_64 system implement the VT-x or AMD-V virtualization support including the
nested page table support (EPT — Intel, NPT — AMD)
■ Ubuntu LTS 16.04:
● x8664bit Intel Xeon processors: Supermicro SYS-5018R-WR
● IBM System z based on z/Architecture processors: IBM z13
● IBM System P based on OpenPOWER processors:
□ IBM Power System S822L (PowerNV 8247-22L)
□ IBM Power System S822LC (PowerNV 8001-22C)
□ IBM Power System S822LC (PowerNV 8335-GTB)
Note: the x86_64 system implements the VT-x including the nested page table support
(EPT — Intel). The listed machines provide the IOMMU implementation of VT-d.
■ Oracle Linux
● x86 64-bit Intel Xeon processors: Oracle Server X7-2
4
General System Overview (RHEL)
■ The Target of Evaluation (TOE) is the Linux distribution in the version specified in the ST
executing on the hardware specified in the ST.
■ Multiple TOE systems can be connected via a physically-protected Local Area Network (LAN).
● Each computer provides the same set of local services, such as file, memory, and process management
● Each computer also provides network services, such as remote secure shells and file transfers, to users
on other computers
● A user logs in to a host computer and requests services from the local host and also from other
computers within the LAN.
■ User programs issue network requests by sending Transmission Control Protocol (TCP) or
User Datagram Protocol (UDP) messages to another computer
● Some network protocols, such as Secure Shell (SSH), can start a shell process for the user on another
computer, while others are handled by trusted server daemon processes.
■ The TOE system provides a user Identification and Authentication (I&A) mechanism by
requiring each user to log in with proper password at the local workstation, and also at any
remote computer where the user can enter commands into a shell program (for example,
remote SSH sessions)
● Each computer enforces a set of the following policies:
□ Discretionary Access Control (DAC) policy, based on UNIX®-style mode bits
□ an optional Access Control List (ACL)
□ Mandatory Access Control (MAC) policy using Security Enhanced Linux (SELinux) extensions for the named objects
under its control.
5
Host Computer Structure
6
TOE Services
■ Each host computer in the system is capable of providing the
following types of services:
● Local services to the users who are currently logged in to the system
using
□a local computer console,
□ virtual consoles,
□ or terminal devices connected through physically protected serial lines.
● Local services to the previous users via deferred jobs;

□ an example is the cron daemon.
● Local services to users who have accessed the local host via the
network using a protocol such as SSH, which starts a user shell on the
local host.
● Network services to potentially multiple users on either the local host or
on remote hosts.
● Virtualization environments are provided to allow untrusted software to
execute in user state of the processor.
7
Local and network services
provided by Linux (1)
■ A user can log in to the local host computer and make file
system requests or memory management requests for
services via system calls to the kernel of the local host
● All
such local services take place solely on the local host computer
and are mediated solely by trusted software on that host
■ Network services, such as SSH or FTP, involve client-server
architecture and a network service-layer protocol
● The client-server model splits the software that provides a service
into a client portion that makes the request, and a server portion that
carries out the request, usually on a different computer
● The service protocol is the interface between the client and server
8
Local and network services
provided by Linux (2)
■ User A can log in at Host 1, and then
use SSH to log in to Host 2.
● On Host 2, User A is logged in from a
remote host
● On Host 1, when User A uses SSH to log
in to Host 2, the SSH client on Host 1
makes protocol requests to an SSH server
process on Host 2
● The server process mediates the request
on behalf of User A, carries out the
requested service, if possible, and returns
the results to the requesting client
process.
■ Also, note that the network client and server can be on the same host system.
● For example, when User C uses SSH to log in to Host 2, the user's client process opens
an SSH connection to the SSH server process on Host 2
● Although this process takes place on the local host computer, it is distinguished from
local services because it involves networking protocols
9
Security Policy Model (1)
■ The security policy for the TOE is defined by the security functional
requirements.
■ The following is a list of the subjects and objects participating in the policy.
Subjects:
● Processes acting on behalf of a human user or technical entity
● Processes acting on behalf of a human user or technical entity providing a virtual
machine environment
Named objects:
● File system objects in the following allowed file systems:
□ XFS — standard file system for general data
□ VFAT — special purpose file system for UEFI BIOS support mounted at /boot/efi
□ Ext4 — standard file system for general data
□ iso9660 — ISO9660 file system for CD-ROM and DVD
□ tmpfs — the temporary file system backed by RAM
□ rootfs — the virtual root file system used temporarily during system boot
□ procfs — process file system holding information about processes, general statistical data and
tunable kernel parameters
□ sysfs — system-related file system covering general information about resources maintained by the
kernel including several tunable parameters for these resources
10
□ devpts — pseudoterminal file system for allocating virtual TTYs on demand
□ devtmpfs — temporary file system that allows the kernel to generate character or block device
nodes
□ binfmt_misc — configuration interface allowing the assignment of executable file formats with user
space applications
□ securityfs — interface for loadable security modules (LSM) to provide tunables and configuration
interfaces to user space
□ selinuxfs — interface for allowing user space components to interact with the SELinux module
inside the kernel, including managing the SELinux policy
Note that the TOE supports a number of additional virtual (i.e. without backing of
persistent storage) file systems which are only accessible to the TSF — they are not or
cannot be mounted
□ Allabove mentioned virtual file systems implement access decisions based DAC attributes inferred
from the underlying process’ DAC attributes
□ Additional restrictions may apply for specific objects in this file system
● Inter Process Communication (IPC) objects:

□ Semaphores
□ Shared memory
□ Message queues
□ Named pipes
□ UNIX domain socket special files
11
TSF data:
● TSF executable code
● Subject meta data — all data used for subjects except data which is not
interpreted by the TSF and does not implement parts of the TSF (this data is
called user data)
● Named object meta data — all data used for the respective objects except data
which is not interpreted by the TSF and does not implement parts of the TSF
(this data is called user data)
● User accounts, including the security attributes defined by FIA_ATD.1
● Audit records
User data:
● Non-TSF executable code used to drive the behavior of subjects
● Data not interpreted by TSF and stored or transmitted using named objects
12
Security policy (1) — Users
■ A user is an authorized individual with an account.
■ Users can use the system in one of following ways:
● By interacting directly with the system through a session at a computer console (in
which case the user can use the display provided as the physical console), or
● By interacting directly with system through a session at a serial terminal, or
● Through deferred execution of jobs using the cron mechanism, or
● By using services implemented with applications accessing these services either
locally or remotely, or
● By using virtual machine environments accessing these environments either
locally or remotely.
■ A user must log in at the local system in order to access the protected
resources of the system.
■ Once a user is authenticated, the user can access files or execute
programs on the local computer, or make network requests to other
computers in the system.
13
Security policy (2) —
Subjects and Objects
■ The only subjects in the system are processes
●A process consists of an address space with an execution context
● The process is confined to a computer; there is no mechanism for dispatching a
process to run remotely (across TCP/IP) on another host
● Every process has a process ID (PID) that is unique on its local host computer, but
PIDs are not unique across systems
□ As an example, each host in the system has an init process with PID 1
■ Objects are passive repositories of data
● The TOE defines three types of objects:
□ named objects which are resources, such as files and IPC objects, which can be manipulated
by multiple users using a naming convention defined at the TSF interface;
□ storage objects which is an object that supports both read and write access by multiple non-
trusted subjects; and
□ public objects which is an object that can be publicly read by non-trusted subjects and can be
written only by trusted subjects.
● Consistent with these definitions, all named objects are also categorized as storage
objects, but not all storage objects are named objects.
14
Security policy (3) —
Access Control
■ Linux enforces a DAC policy for all named objects under its control, and
an object reuse policy for all storage objects under its control
● The DAC policy that is enforced varies among different object classes, in all
cases it is based on user identity and on group membership associated with the
user identity
■ In addition to the DAC policy, Linux also enforces a MAC policy for all
named objects under its control
● DAC policy is enforced first, while MAC is enforced only if DAC permits the
operation
● The MAC policy is non-authoritative; that is, a DAC policy denial cannot be
overridden by the MAC policy
● The MAC policy that is enforced varies among different object classes, in all
cases it is based on the domain of the user and the type of the object
■ To allow for enforcement of the access control policies, all users must be
identified, and their identities must be authenticated
15
Security policy (4)
■ The TOE uses both hardware and software protection mechanisms
● The hardware mechanisms used by Linux to provide a protected domain for its own execution
include a multistate processor, memory segment protection, and memory page protection
● The TOE software relies on these hardware mechanisms to implement TSF isolation, non-
circumventability, and process address-space separation
■ A user can log in at the console, at other directly attached terminals, or through a
network connection
■ Authentication is based on a password entered by the user and authentication data
stored in a protected file or via other types of credentials, such as cryptographic
keys when using SSH
● Users must log in to a host before they can access any named objects on that host
● Some services, such as SSH, to obtain a shell prompt on another host, or ftp, to transfer files
between hosts in the distributed system, require the user to re-enter authentication data to the
remote host
● Linux permits the user to change passwords (subject to TOE enforced password guidelines),
change identity, submit batch jobs for deferred execution, and log out of the system
■ The system architecture provides TSF self-protection and process isolation
mechanisms
16
TSF identification
■ The Linux operating system is distributed as a collection of packages
●A package can include programs, configuration data, and documentation for the package
● Analysis is performed at the file level, except where a particular package can be treated
collectively
■ A file is included in the TSF for one or more of the following reasons:
● It contains code, such as the kernel, kernel module, and device drivers, that runs in a
privileged hardware state of the processor
● It enforces the security policy of the system
● It allows SUID or SGID to a privileged user (for example, root) or group
● It is given file system capabilities implying a privilege escalation during execution
● It grants one or more abilities to override security-related rules enforced by the system to the
calling user
● It started as a daemon executing with root privileges or with a system UID / GID
● It is software that must function correctly to support the system security mechanisms
● It is required for system administration
● It consists of TSF data or configuration files
● It consists of libraries linked to TSF programs
● It started as an application with different privileges than the caller
□ The most notable examples are init, modprobe, and v86d used by the uvesafb driver
● It grants one or more MLS override capabilities to the calling user
17
Kernel TSF Software
■ The Linux kernel includes
● thebase kernel and
● separately-loadable kernel modules and device drivers
■ The kernel implements the Linux system call interface, which

provides system calls for
● file
management,
● memory management,
● process management,
● networking,
● and other TSF (logical subsystems) functions
■ An incoming request from user space passes the system call

layer and it is checked for its input and permission
● Afterthese checks, the requested work is executed which may need to
access device drivers to obtain hardware access
18
Non-kernel TSF Software
■ Non-kernel TSF software includes programs that run with the administrative privilege,
such as the sshd, and systemd daemons
● The TSF also includes the configuration files that define
□ authorized users,
□ groups of users,
□ services provided by the system,
□ and other configuration data
● Not included as TSF are

□ shellsused by administrators,
□ and standard utilities invoked by administrators
■ The Linux system, which includes

● hardware,
● kernel-mode software,
● non-kernel programs,
● and databases,
provides a protected environment in which users and administrators run the programs,
or sequences of CPU instructions
● Programs execute as processes with the identity of the users that started them (except for some
exceptions defined further), and with privileges as dictated by the system security policy
● Programs are subject to the access control and accountability processes of the system
19
TSF interfaces (1)
■ The TSF interfaces include:
● localinterfaces provided by each host computer
● the network client-server interfaces provided by pairs of host computers
■ TSF interfaces include any interface that is possible between untrusted

software and the TSF
■ The local interfaces provided by a host computer include the following
kernel-provided interfaces:
● System calls made by trusted and untrusted programs to the privileged kernel-
mode software
□ System calls are exported by the base Linux kernel and by kernel modules
● The following kernel interfaces should be considered independent interfaces
during a security analysis (despite they are a semantical extension of the open,
ioctl or socket-related system calls):
□ Device files: device files allow direct access to hardware resources
•
The access is established using the read, write and/or mmap functions or using ioctls to implement more
specific access mechanisms
•
In addition, a limited number of device files allow access to kernel-internal data structures using file
system semantics as well as ioctls
20
TSF interfaces (2)
□ Virtualfile systems: virtual file systems provide access to kernel-internal
data structures using file system semantics
•
Access is limited to read, write and/or mmap functions
□ Network sockets using the AF_NETLINK protocol: netlink sockets provide
access to kernel-internal data structures using networking semantics
•
Access is limited to sending and/or receiving information
□ Network sockets using the PF_KEY protocol: the PF_KEY sockets are
used to interact with the network packet transformation logic in the kernel
□ Network sockets using the AF_ALG protocol: The AF_ALG network
protocol can be used to interact with the kernel crypto API
● Any network protocol analyzer/parser implemented by the kernel:
□ Ethernet
□ ARP
□ TCP/IP protocol family
□ IPSec
□ Labeled communication using IPSec protocols
21
TSF interfaces (3)
■ The following interfaces are implemented by trusted processes in user
space:
● Networked interfaces provided by pairs of host computers:
□ SSHv2 (RFC 4252)
□ IKEv1 and IKEv2: (IKE — RFC 2409 and RFC 5996, the available Diffie-Hellman groups —
RFC 2409, RFC 3526, RFC 5114)
□ TLS v1.1 and TLS v1.2: (RFC 4346 and RFC 5246)
● The argv and envp character arrays which are arguments to the execve system call
□ These two arrays can be evaluated by the executed application
□ A number of environment variables that can be provided with envp are implemented by libraries
that are commonly loaded by most, if not all, applications (like the C-library)
● Files that are part of the TSF database that define the configuration parameters used
by the security functions
● Inter-process communication interfaces exported by an application
□ Theinter-process communication interface type includes the DBus support
□ DBus is a protocol that runs on top of kernel-provided inter-process communication mechanisms
● Hypervisor calls and instruction emulation and simulation implemented by the Linux
kernel to support the KVM virtualization environment
□ This includes the simulation and emulation of hardware provided with the Linux kernel
22
Non-TSF interfaces (1)
■ Interfaces between non-TSF processes and the underlying hardware
● Typically, user processes do not interface directly with the hardware; exceptions are
□ processor,
□ USB,
□ parallelport connections,
□ serial port connections
□ and graphics hardware
● The unprivileged processor instructions do not implement any security functionality, and
the processor restricts these instructions to the bounds defined by the processor
● In addition, the rest of the listed hardware components are not part of the TOE as they are
peripherals
■ Interfaces between different parts of the TSF that are invisible to normal users
(for example, between subroutines within the kernel)
● The interface is internal to the trusted part of the TOE and cannot be invoked outside of
those parts
■ The firmware, while part of the TOE, are not considered as providing TSF
interfaces
● because they do not allow direct unprivileged operations to them
23
Non-TSF interfaces (2)
■ Processor exceptions reflected to the firmware, are not considered to be TSF
interfaces
● They are not relevant to security because they provide access to the firmware, which
does not implement any security functionality
■ In case the IT environment provides a virtualization environment, such as
● KVM host systems,
● z/VM or PR/SM on s390x systems or
● POWER LPAR on IBM POWER systems,
the architected hypervisor interfaces of the virtualization environment (like

hypervisor calls) are not considered a TSF interface
● because it is not accessible by unprivileged processes in the problem state, and does not
provide any security functionality
Note, the hypervisor functionality implemented by the Linux kernel and its
interfaces is not referenced here
■ The SMM state of Intel-based processors is not security relevant as the software
executing in this state does not implement any security functionality
● Moreover, unprivileged code cannot access or modify the software executing in this
processor state.
24
What is not permitted
■ There is a distinction between non-TSF user-mode software that can be
loaded and run on the system, and software that must be excluded from the
system
■ The following methods are used to ensure that excluded software cannot be
used to violate the security policies of the system:
● Addition of kernel modules is not permitted
● The installation software may change the configuration (for example, mode bits) so that
a program cannot violate the security policy
● Addition of programs with SUID bit enabled and owning UID of either root or a system
UID is not permitted
● Addition of programs with SGID bit enabled and owning GID of either root or a system
GID is not permitted
● Addition of programs capability bits enabled is not permitted
● Addition of daemons executing with root or system UID / GID is not permitted
● Alterations of the rule set of the frameworks that allow spawning of processes with
different privileges, such as udev or PolicyKit is not permitted
● Addition of programs with MLS override capabilities enabled is not permitted
25
Software Architecture (RHEL)
■ Hardware and software privilege ■ TOE Security Functions software
● Hardware privilege structure
□ X86 Privilege level ● Kernel TSF software
□ PowerPC Privilege level □ Logicalcomponents
□ SystemZ Privilege level □ Execution components
□ Virtualization consideration •
Base kernel
•
Kernel threads
● Software privilege •
Kernel modules and device drivers
□ DAC
● Non-kernelTSF software
•
Subjects and objects
•
Attributes ● TSF databases
Access control rules ■ Hardware
•
•
Software privilege
□ SELinux ■ Firmware
LSM MAC
•
Subjects and objects
•
Attributes
•
Attribute storage
•
Access control rules
•
Software privilege
□ Capabilities
•
Software privilege
□ Programs with software privilege
26
Software Architecture
■ This section summarizes the software structure and design of
the Linux system
● The following subsections describe
□ the TOE Security Functions (TSF) software (kernel and non-kernel components)
□ the TSF databases for the Linux system
● The descriptions are organized according to the structure of the system

and describe the Linux kernel that controls access to shared resources
from trusted (administrator) and untrusted (user) processes
■ The following section — Functional Description — describes the
functions performed by the Linux logical subsystems.
● These logical subsystems generally correspond to the architectural
subsystems described in Software Architecture section.
● The material in this section provides the foundation information for the
descriptions in the Functional Description section.
27
Hardware privilege — X86
Privilege level
■ The concept of privilege is implemented by assigning a value of
0 to 3 to key objects recognized by the processor.
● This value is called the privilege level.
■ The following processor-recognized objects contain privilege
levels:
● Descriptors contain a field called the descriptor privilege level (DPL).
● Selectors contain a field called the requestor’s privilege level (RPL).
□ The RPL is intended to represent the privilege level of the procedure that
originates the selector.
● An internal processor register records the current privilege level (CPL).
□ Normally the CPL is equal to the DPL of the segment the processor is currently
executing.
□ The CPL changes as control is transferred to segments with differing DPLs.
28
Levels of privilege interpreted
as layers of protection
■ The center is for the segments
containing the most critical
software, usually the kernel of the
operating system.
■ Outer layers are for the segments
of less critical software.
■ The Linux kernel, as with most
other UNIX-variant kernels, utilizes
only two of these execution modes.
● The highest, with the processor
privilege level of 0, corresponds to
the kernel mode;
● The lowest, with the processor
privilege of 3, corresponds to the user
mode.
29
Implementation of the hardware
privilege
■ User and kernel modes implement hardware privilege as follows:
● When the processor is in kernel mode, the program has hardware privilege because it can access and
modify any addressable resources, such as memory, page tables, I/O address space, and memory
management registers. This is not possible in the user mode.
● When the processor is in kernel mode, the program has hardware privilege because it can execute
certain privileged instructions that are not available in user mode.
Thus, any code that runs in kernel mode executes with hardware privileges.
■ Software that runs with hardware privileges includes:
● The base Linux kernel.
□ This constitutes a large portion of software that performs memory management file I/O and process management.
● Separately loaded kernel modules, such as many device driver modules.
□A kernel module is an object file whose code can be linked to, and unlinked from, the kernel at runtime.
□ The kernel module code is executed in kernel like any other statically-linked kernel function.
All other software on the system normally runs in user mode, without hardware privileges,
including user processes such as shells, networking client software, and editors.
■ User-mode processes run with hardware privileges when they invoke a system call.
● The execution of the system call or processor traps (such as page faults) caused by user space
applications switches the mode from user to kernel mode, and continues the operation at a designated
address within the kernel where the code of the system call handler or trap handler is located.
30
PowerPC and SystemZ
Privilege level
■ PowerPC Privilege level
● This processor architecture provides three execution modes, identified
by the PR bit (bit 49) and the HV bit (bit 3) of the Machine State
Register (MSR) of the processor
□ Values of 0 for both PR and HV bits indicate a hypervisor execution mode
□ An HV bit value of 1, and a PR bit value of 0, indicate a supervisor, or kernel,
execution mode
□ An HV bit value of 1 and a PR bit value of 1 indicate a user execution mode
■ SystemZ Privilege level

● The System z systems also provide two execution modes identified by
the Problem State bit (bit 15) of the processor’s Program Status Word
(PSW).
□ The value of 0 indicates a supervisor, or kernel, execution mode
□ The value of 1 indicates a problem state, or user, execution mode
31
Virtualization consideration
■ When the TOE is used as a host system for the KVM virtualization, a third privilege state is
used in addition to the two mentioned above: the hypervisor mode.
● The hypervisor mode utilizes additional hardware support provided by the processor.
□ With the hypervisor mode, processor register are accessible that are not accessible via the other two states.
□ Using these registers, another layer of memory address translation is implemented.
□ In addition, I/O address space virtualization is utilized if available.
■ The Linux kernel utilizes this mode when the KVM virtualization is activated.
● In this case, the entire Linux kernel operates in hypervisor mode.
● Normal processes still operate in user mode.
● For user mode processes, the Linux kernel behaves the same way as if the kernel would operate in
supervisor mode.
● In addition, processes may also use the supervisor mode with the help provided by KVM to implement
a guest operating system.
● From the Linux kernel perspective, a guest system is nothing more than a regular process where parts
of that process are executed by enabling the virtualization functionality of the processor.
■ The following CPU mechanisms are used to implement the hypervisor state:
● Intel-based:
VT-x
● AMD-based: SVM
● System Z: SIE instruction
■ The Linux kernel does not provide virtualization support for CPUs other than those listed.
32
Software privilege
■ Software privilege in Linux involves the ability to override the kernel’s
access control mechanisms.
■ Linux implements the following access control models:
● Discretionary Access Control enforced on storage objects
● Capability-based security checks to restrict the execution of system calls or
functional subsets of system calls to callers having the respective capability
● Linux Security Module (LSM) access checks – Mandatory Access Control policies
are implemented using LSMs
■ When accessing named objects, Discretionary Access Control (DAC) is
applied first, and the LSM access checks is applied if and only if the DAC
check grants access.
● The kernel implements software privileges for the DAC policy.
● In addition, the SELinux LSM module may implement software privileges with an
optionally loaded MLS policy.
■ Besides the access control software privileges, capabilities are another
software privilege that can be granted to applications
33
Discretionary Access Control (1)
■ The DAC model allows the owner of the object to decide who can
access that object, and in what manner
● Like any other access control model, DAC implementation can be explained
by
□ which subjects and objects are under the control of the model,
□ security attributes used by the model,
□ access control and attribute transition rules,
□ and the override (software privilege) mechanism to bypass those rules.
■ Subjects and objects

● Subjects in Linux are regular processes and kernel threads.
□ They are both represented by the task_struct structure.
□ Kernel threads run only in the kernel mode, and are not constrained by the DAC
policy.
● All storage objects such as regular files, character and block files,
directories, sockets, IPC objects, and kernel key rings are under the control
of the DAC policy.
34
Discretionary Access Control (2)
■ Attributes
● Subject attributes used to enforce DAC policy are the process UID, GID, supplementary
groups, and process capabilities.
□ These attributes are stored in the task_structure of the process, and are affected by the system
calls.
● Objectattributes used to enforce DAC policy are owner, group owner, permission bits,
and POSIX.1e Access Control Lists (ACLs) for file system objects.
□ These attributes are stored in-core and, for appropriate disk-based file systems, in the on-disk inode.
■ Access control rules
● DAC access control rules specify how a certain process with appropriate DAC security
attributes can access an object with a set of DAC security attributes
● In addition, DAC access control rules also specify how subject and object security
attributes transition to new values and under what conditions
■ Software privilege
● Software privilege for DAC policy is based on the capabilities of CAP_DAC_OVERRIDE,
CAP_DAC_READ_SEARCH which can be assigned to a process.
● A process bearing these capabilities is granted software privilege with respect to DAC as
it can bypass the access control policies of the system.
35
SELinux LSM MAC
■ With the Mandatory Access Control implemented with the SELinux LSM,
it is the system security policy (unlike the owner in DAC) that controls
who should be allowed access to what information
■ The MAC policy provided with SELinux rests on two policy types:
● Type Enforcement (TE) which is used to implement role-based access control,
and
● Multi-Level Security (MLS) with a Bell-LaPadula style hierarchical labeling policy
■ Subjects and objects

● Subjects in Linux are regular processes and kernel threads (same as in DAC)
□ Kernel threads run only in the kernel mode and are not constrained by the MAC policy
● Allnamed objects such as regular files, character and block files, directories,
sockets, and IPC objects are under the control of the MAC policy.
● In addition to named objects, the MAC policy can also control access to certain
kernel data structures such as file descriptors, IPC messages, and file systems
to allow granular expression of the system security policy.
36
SELinux Attributes
■ Subject and object security attributes,

also referred to as the SELinux security context, have the same format.
■ In user-readable and external form, the security context is an ASCII string.
● The kernel, for performance reasons, converts the string into a 32-bit integer at run-time
■ The security context consists of four colon-separated components
■ They correspond to user, role, type, and MLS range of the subject or object
■ User: The user component is the SELinux user name.
■ Role: The role component is the SELinux role corresponding to the subject or object.
● For subjects, the role is used to implement role-based access control by allowing the role to control access to
domains.
● For objects, the role component is not used, and is all object_r.
■ Type: The type field represents the subject domain or object type.
● Domains and types are equivalent classes for processes and resources, respectively.
● Access decisions in the kernel are made based on subject domain and object type.
■ MLS label range: The MLS label range contains two complete MLS labels.
● Each MLS label consists of two components, a hierarchical classification level (or sensitivity level), and a
non-hierarchical set of categories.
37
MLS labels
■ Each MLS label consists of two components,
●a hierarchical classification level (or sensitivity level), and
● a non-hierarchical set of categories.
■ The MLS label range contains two complete MLS labels

● They are arranged with the low label on the left and the high label, which dominates the
low label, on the right. The two labels are separated by a dash
■ For subjects,
● the low label of the range corresponds to the effective MLS label of the subject, while
● the high label corresponds to the clearance of the subject
□ The subject clearance maps to the clearance of the user on whose behalf the subject is acting.
■ For objects such as regular files, the security policy dictates that the low label
and the high label are equal,
● thus making the object, effectively, single level
■ Objects such as directories, devices, and sockets may have a high label that is
not equal to the low label.
● These objects are multilevel, and their MLS label range requires that the sensitivity level
of any information that passes through them dominates the low label and is dominated by
the high label.
38
SELinux Attributes
■ SELinux attributes are stored:
● in the task_struct process structure for subjects,
● in in-core and on-disk inode data structure for file system objects.
● in the kern_ipc_perm data structure for system V IPC objects,
● in the sock data structure for sockets,
● in the xfrm_state structure for netlink sockets,
● and the key data structure for keys.
■ SELinux maps invalid contexts to the system_u:object_r:unlabeled_t:s0 context.

■ Access control rules:
● MAC access control implementation is based on Type Enforcement (TE)
□ TE provides fine-grained access control over subjects and objects.
□ The TE and the MLS policy rules are defined with the SELinux policy.
□ TE rules are defined as access control checks whereas the MLS policy is expressed as a constraint on top of the TE.
● Therefore, the total access control check happens in three logical steps, as follows:
1.The first is the DAC check using DAC attributes, followed by
2.the TE check using domains and types of the SELinux security context, followed by
3.the Bell-LaPadula MLS policy check using the MLS range of the SELinux security context.
● Each check is non-authoritative.
□ That is, permissions are only reduced at each stage;
□a DAC denial cannot be overridden by TE,
□ and a TE denial cannot be overridden by MLS.
39
Software privilege for MAC
■ Software privilege for the MAC policy is implemented with the domain of the
process and security policy rules associated with that domain.
● For example, processes running in the init_t domain are allowed to read objects whose
sensitivity label dominates the process sensitivity label.
● This override is achieved by domain attributes.
■ The policy rule expresses the domain’s access to type with the override tied to
an attribute of the domain.
● For example, the following policy rule can be used to allow a process to override the Bell-
LaPadula restriction of “no-read-up” when it tries to read a regular file:
mlsconstrain {file} {read} ((l1 dom l2) or (t1 == mlsfileread));
● The above statement sets the security policy that label l1 (belonging to the subject) must
dominate label l2 (belonging to the object) for the read operation to succeed, unless the
process domain has the mlsfileread attribute.
■ System security policy for different subject and object types is described with the
functional description of those subjects and objects.
● In addition to the process attributes which can grant override rights, the following
capability are known to the Linux kernel: CAP_MAC_OVERRIDE.
● If a process possesses this capability, the process can bypass the entire SELinux policy
enforcement.
40
Capabilities
■ The Linux kernel has a framework for providing software privilege for many different functions
provided by the Linux kernel by using capabilities.
● These capabilities allow breakup of the kernel software privilege associated with user ID zero into a set of
discrete privileges based on the operation being attempted.
■ Capabilities integrate with user IDs as follows:
● If a SUID application with the owning ID of root is executed, all capabilities for that process are enabled.
● If the set*uid system call family is used to change the UID of the calling process to an ID not equal to 0, all
capabilities are removed for that process.
● Processes spawned by root initially have all capabilities set.
● Processes spawned by non-root users initially have no capability set.
■ Software privilege
● The kernel restricts the use of many system calls or functional areas called by system calls to processes which
possess a specific capability.
● If the calling process does not possess the required capability, the execution of the affected code area is
denied and the error of EPERM is returned to the caller.
□ For example, if a process is trying to create a device special file by invoking the mknod system call, the kernel checks to
ensure that the process is capable of creating device special files by verifying that the process possesses the CAP_MKNOD
capability.
● Inthe absence of special kernel modules that define and use capabilities, as is the case with the TOE,
capability checks revert back to granting kernel software privilege based on the user ID of the process.
■ The capabilities are based on the POSIX.1e draft plus a number of additional capabilities.
● The entire list of all capabilities including their meanings is fully described in the Linux kernel source code file
of include/linux/capability.h.
41
Programs with software privilege
■ Examples of programs running with software privilege are:
● Programs that are run by the system, such as the cron and init daemons.
● Programs that are run by trusted administrators to perform system administration.
● Programs that run with privileged identity by executing SUID / SGID / file system capabilities
program files.
● Programs executed by trusted super daemons. The following super daemons with the capability of
spawning applications with dissimilar privileged on behalf of calling users are present:
□ systemd: The system boot and management framework provided by systemd allows users to communicate with
it via DBus channels. As systemd runs as root, it allows untrusted users to perform actions that otherwise would
not be possible for such users.
□ PolKit: The user space authorization framework is implemented by the PolKit daemon. That daemon offers its
services via DBus providing the capability to spawn applications as configured by its policy via a SUID helper
application.
■ All software that runs with hardware privileges or software privileges are part of the TSF
■ In a properly administered system:
● Unprivilegedsoftware is subject to the security policies of the system and does not have any
means of bypassing the enforcement mechanisms
□ This unprivileged software need not be trusted in any way, and is thus referred to as untrusted software.
● Trustedprocesses that do not implement any security function need to be protected from
unauthorized tampering using the security functions of Linux.
□ They need to be trusted to not perform any function that violates the security policy of Linux.
42
TSF Software Structure
■ Below is described the structure of the Linux software that constitutes the
TOE Security Functions (TSF)
■ The Linux system is a multi-user operating system
● the kernel running in a privileged hardware mode
● the user processes running in user mode
■ The TSF includes both the kernel software and certain trusted non-kernel
processes
■ The concept of breaking the TOE product into logical subsystems is
described in the Common Criteria.
● These logical subsystems are the building blocks of the TOE, and are described in
the Functional Descriptions section
● They include logical subsystems and trusted processes that implement security
functions
● A logical subsystem can implement or support one or more functional components
□ For
example, the File and I/O subsystem is partly implemented by functions of the Virtual
Memory Manager
43
Kernel TSF software
■ The kernel is the core of the operating system. It
● Interactsdirectly with the hardware,
● Implements the sharing of resources, providing common services to programs,
and
● Prevents programs from directly accessing hardware-dependent functions
■ The Linux kernel is a fully preemptible kernel
● In non-preemptive kernels, kernel code runs until completion
□ That is, the scheduler is not capable of rescheduling a task while it is in the kernel
□ Moreover, the kernel code is scheduled cooperatively, not preemptively, and it runs until it
finishes and returns to user-space, or explicitly blocks
● Inpreemptive kernels, it is possible to preempt a task at any point, so long as the
kernel is in a state in which it is safe to reschedule
■ Services provided by the kernel include the following:
● Control of the execution of processes by allowing their creation, termination or
suspension, and communication
● Allocation of the main memory for an executing process
● Life-cycle maintenance of virtual machines
● File system maintenance
44
Services provided by the kernel (1)
■ Control of the execution of processes by allowing their creation, termination or
suspension, and communication. These include:
● Fairscheduling of processes for execution on the CPU.
● Share of processes in the CPU in a time-shared manner.
● CPU execution of a process.
● Kernel suspension when its time quantum elapses.
● Kernel schedule of another process to execute.
● Later kernel rescheduling of the suspended process.
● Management of the process security-related meta data, such as UIDs, GIDs, SELinux
labels, capabilities.
■ Allocation of the main memory for an executing process. These include:
● Kernel allowance of processes to share portions of their address space under certain
conditions, but protection of the private address space of a process from outside
tampering.
● If the system runs low on free memory, the kernel frees memory by writing a process
temporarily to secondary memory, or a swap device.
● Coordination with the machine hardware to set up a virtual-to-physical address that
maps the compiler-generated addresses to their physical addresses.
45
Services provided by the kernel (2)
■ Life-cycle maintenance of virtual machines, which includes:
● Enforcement of the resource limits configured by the emulation application
applicable to the virtual machine.
● Starting of the virtual machine code.
● Handling of exiting of virtual machines by either performing an instruction
completion or deferring the instruction completion to the user-space emulation
application.
■ File system maintenance. These include:
● Allocation of secondary memory for efficient storage and retrieval of user data.
● Allocation of secondary storage for user files.
● Reclamation of unused storage.
● Structure of the file system in a well-understood manner.
● Protection of user files from illegal access.
● Allowance of processes’ controlled access to peripheral devices such as
terminals, tape drives, disk drives, and network devices.
● Mediation of access between subjects and objects, allowing controlled access
based on the DAC policy and any policy enforced by the loaded LSM.
46
Kernel logical components
■ File and I/O subsystem
■ Process subsystem
■ Memory subsystem
■ IPC subsystem
■ Kernel framework subsystem
■ Auditing
■ Linux Security Extensions
■ Device driver subsystem
■ KVM subsystem
■ Crypto API
47
Kernel logical components (1)
■ File and I/O subsystem:
● This subsystem implements functions related to file system objects.
● Implemented functions include those that allow a process to create, maintain,
interact, and delete file-system objects.
● These objects include regular files, directories, symbolic links, hard links,
device-special files, named pipes, and sockets.
■ Process subsystem:
● Thissubsystem implements functions related to process and thread
management.
● Implemented functions include those that allow the creation, scheduling,
execution, and deletion of process and thread subjects.
■ Memory subsystem:
● This subsystem implements functions related to the management of memory
resources of a system.
● Implemented functions include those that create and manage virtual memory,
including management of page tables and paging algorithms.
48
■ Networking subsystem:
● This subsystem implements UNIX and Internet domain sockets, as well as
algorithms for scheduling network packets.
■ IPC subsystem:
● This subsystem implements functions related to IPC mechanisms.
● Implemented functions include those that facilitate controlled sharing of information
between processes, allowing them to share data and synchronize their execution, in
order to interact with a common resource.
■ Kernel framework subsystem:
● This subsystem implements the infrastructure for the kernel to sustain various kernel
mechanisms.
● This subsystem includes the following functions among others:
□ Support for loadable modules: Implemented functions include those that load, initialize, and
unload kernel modules.
□ Exception handling such as context switches, system call loading, etc.
□ Auditing: The audit subsystem implements functions related to recording of security-critical
events on the system. Implemented functions include those that trap each system call to record
security-critical events and those that implement the collection and recording of audit data.
49
■ Linux Security Extensions:
● The Linux Security extensions implement various security-related aspects that are provided
to the entire kernel, including the Linux Security Module framework.
● The LSM framework provides a security-agnostic framework for modules to implement
different security policies, including SELinux.
□ SELinux is an important logical subsystem.
□ This subsystem implements mandatory access control functions to mediate access between all subjects
and objects.
■ Device driver subsystem:
● This
subsystem implements support for various hardware and software devices through a
common, device-independent interface.
■ KVM subsystem:
● This subsystem implements the virtual machine life-cycle handling.
● It includes instruction completion for instructions requiring only small verifications.
● For any other instruction completion, KVM calls the QEMU user-space component.
■ Crypto API:
● This subsystem provides a kernel-internal cryptographic library to all components of the
kernel.
● It provides cryptographic primitives to callers.
50
Kernel execution components
■ Base kernel
● The base kernel includes the code that is executed to provide a service, such as servicing a
user’s system call invocation, or servicing an interrupt or exception event.
● A majority of the compiled kernel code falls under this category.
■ Kernel threads
● Inorder to perform certain routine tasks such as flushing disk caches, or reclaiming memory by
swapping out unused page frames, the kernel creates internal processes, or threads.
● Threads are scheduled just like regular processes, but they do not have context in user mode.
● Kernel threads reside in kernel space, and only run in the kernel mode.
■ Kernel modules and device drivers

● Kernelmodules are pieces of code that can be loaded and unloaded into and out of the kernel
upon demand.
□ They extend the functionality of the kernel without the need to reboot the system.
□ Once loaded, the kernel module object code can access other kernel code and data in the same manner as
statically-linked kernel object code.
●A device driver is a special type of kernel module that allows the kernel to access the hardware
connected to the system.
□ These devices can be hard disks, monitors, or network interfaces.
□ The driver interacts with the remaining part of the kernel through a specific interface, which allows the kernel
to deal with all devices in a uniform way, independently of their underlying implementations.
51
Non-kernel TSF software and databases
■ The non-kernel TSF software consists of trusted programs that are used to
implement security functions
Note that shared libraries, including PAM modules in some cases, are used by trusted
programs. However, there is no instance where a shared library by itself is considered to
be a trusted entity
■ The trusted commands can be grouped as follows
● System Initialization
● Identification and Authentication
● Network Applications
● Batch Processing
● System Management
● User Level Audit
● Cryptographic Support
● Virtual machine support
● User space authorization handling
■ TSF databases are configuration files for trusted applications

● None of these databases is modifiable by a user other than an administrative user
● Access control is performed by the file system component of the Linux kernel
52
Hardware and Firmware
■ Hardware
● The hardware consists of the physical resources such as
□ CPU,
□ main memory,
□ registers,
□ caches,
□ and devices that effectively make up the computer system
■ Firmware
● The firmware consists of the software residing in the hardware
that is started when the system goes through a power-on reset
● In addition to initializing the hardware and starting the
operating system, on the partitioning-capable platforms the
firmware provides logical partitioning support as well
53
TOE Security Functionality
■ Auditing
■ Cryptographic support
(Trusted Channel for RHEL)

■ Packet filter
(Network Information Flow Control for RHEL)
■ Identification and Authentication
■ Discretionary Access Control
■ Authoritative Access Control
(not mentioned for RHEL)
■ Virtual machine environments
(not mentioned for RHEL)
■ Security Management
54
Audit
■ The Lightweight Audit Framework (LAF) is designed to be an audit
system for Linux compliant with the requirements from Common Criteria.
● LAF is able to intercept all system calls as well as retrieving audit log entries from
privileged user space applications.
● The subsystem allows configuring the events to be actually audited from the set of
all events that are possible to be audited.
● Those events are configured in a specific configuration file and then the kernel is
notified to build its own internal structure for the events to be audited.
■ auditd is the userspace component to the Linux Auditing System.
● It's
responsible for writing audit records to the disk.
● Viewing the logs is done with the ausearch or aureport utilities.
● Configuring the audit system or loading rules is done with the auditctl utility.
□ During startup, the rules in /etc/audit/audit.rules are read by auditctl and loaded into the
kernel.
□ Alternately, there is also an augenrules program that reads rules located in /etc/audit/rules.d/
and compiles them into an audit.rules file.
● The audit daemon itself has some configuration options that the admin may wish to
customize. They are found in the auditd.conf file.
55
Audit functionality (1)
■ The Linux kernel implements the core of the LAF functionality
● Itgathers all audit events, analyzes these events based on the audit rules and forwards the audit events that
are requested to be audited to the audit daemon executing in user space
● Audit events are generated in various places of the kernel
● A user space application can create audit records which needs to be fed to the kernel for further processing
■ The audit functionality of the Linux kernel is configured by user space applications which
communicate with the kernel using a specific netlink communication channel
● This netlink channel is also to be used by applications that want to send an audit event to the kernel
■ The kernel netlink interface is usable only by applications possessing the following capabilities:
● CAP_AUDIT_CONTROL: Performing management operations like adding or deleting audit rules, setting or
getting auditing parameters;
● CAP_AUDIT_WRITE: Submitting audit records to the kernel which in turn forwards the audit records to the
audit daemon.
■ Based on the audit rules, the kernel decides whether an audit event is discarded or to be sent to
the user space audit daemon for storing it in the audit trail.
■ The kernel sends the message to the audit daemon again using the above mentioned netlink
communication channel.
● The audit daemon writes the audit records to the audit trail.
● An internal queuing mechanism is used for this purpose.
● When the queue does not have sufficient space to hold an audit record the TOE switches into single user
mode, is halted or the audit daemon executes an administrator-specified notification action depending on the
configuration of the audit daemon
56
Audit functionality (2)
■ Access to audit data by normal users is prohibited by the DAC function of the TOE
● The access to the audit trail and audit configuration files is restricted to the system administrator only
■ The system administrator can define the events to be audited using simple filter expressions
● The system administrator is also able to define a set of user IDs for which auditing is active or alternatively a
set of user IDs that are not audited
● Individual files can be configured to be audited by adding them to a watch list that is loaded into the kernel
■ Audit rules can be specified to generate audit data based on a large number of different
attributes, including:
● Subject or user identifiers
● Result of the operation (success/failure)
● Object identity
● Operation performed on an object
● System call number
● SELinux label components
■ The audit system can be configured to take actions if the audit trail is full or reaches a given
theshold of disk space
● The actions that can be configured include a halting of the system, preventing further auditable actions,
notifications to an administrator or the execution of a configured command.
■ The TOE provides a management application that uses the aforementioned netlink interface.
● This application is used during boot time to load the audit rules from the configuration file
/etc/audit/audit.rules.
● The audit rules can be modified at runtime of the system.
57
Audit trail
■ An audit record consists of one or more lines of text containing fields in a “keyword=value” tagged format
■ The following information is contained in all audit record lines:
● Type: indicates the source of the event, such as SYSCALL, PATH, USER_LOGIN, or LOGIN
● Timestamp: Date and time the audit record was generated
● Audit ID: unique numerical event identifier
● Login ID (“auid”), the user ID of the user authenticated by the system (regardless if the user has changed his real
and / or effective user ID afterwards)
● Effective user and group ID: the effective user and group ID of the proces s at the time the audit event was
generated
● Success or failure (where appropriate)
● Process ID of the subject that caused the event (PID)
● Hostname or terminal the subject used for performing the operation
● Information about the intended operation
■ This information is followed by event specific data.

■ In some cases, such as SYSCALL event records involving file system objects, multiple text lines will be
generated for a single event, these all have the same time stamp and audit ID to permit easy correlation.
■ The audit trail is stored in ASCII text.
● The TOE provides tools for managing ASCII files that can be used for post-processing of audit data
● The application ausearch allows selective extraction of records from the audit trail using defined selection criteria.
■ The audit trail is stored in files which are accessible by root only
● If the audit trail fills up and reaches a warning threshold the administrator is notified about reaching the configured
level.
● If the audit trail is full, the audit daemon rejects fetching new audit logs from the kernel to store them into a file.
58
Audit framework
59
Audit subsystem implementation
■ Kernel-userspace interface
■ Task structure extensions for audit
■ Syscall auditing
■ Socket call and IPC audit record generation
■ Filesystem auditing
■ Auditing of other kernel actions
■ Kernel audit initialization
■ Audit record format
■ Auditing Support for IPTables
■ Auditing Support for OpenSSH
■ Time Stamp Maintenance
(currently — see documentation for further information)
60
Cryptographic services
■ The TOE provides cryptographically secured network communication channels to allow
remote users to interact with the TOE.
■ Using one of the following cryptographically secured network channels, a user can request
the following services:
● OpenSSH (RHEL, SUSE, Ubuntu): The OpenSSH application provides access to the command line
interface of the TOE. Users may employ OpenSSH for interactive sessions as well as for non-interactive
sessions. The console provided via OpenSSH provides the same environment as a local console.
OpenSSH implements the SSHv2 protocol.
● libvirtd (SUSE, Ubuntu): The libvirtd daemon is the management facility to allow remote users to
configure virtual machines. The configuration covers all aspects such as assigning of resources, starting
or stopping of virtual machines. libvirtd directly interacts with the virtual machines. This interface is
protected using OpenSSH.
● VNC (SUSE, Ubuntu): The VNC interface provides the access mechanism for users to interact with the
console of a virtual machine. The VNC connection is tunneled through OpenSSH.
● IPSec (SUSE): The strongSwan application suite implements the IKEv1 and IKEv2 protocol family to
negotiate the ISAKMP SA as well as the IPSEC SA to securely establish session keys used for the
IPSec network protocol. The established session keys are transferred to the kernel which implements
the generation as well as processing of ESP and AH packets as part of the IPSec operation.
■ In addition to the cryptographically secured communication channels, the TOE also provides
cryptographic algorithms for general use.
■ The cryptographic primitives for implementing the above mentioned cryptographic
communication protocols are provided by OpenSSL.
61
SSHv2 Protocol (RHEL, SUSE, Ubuntu)
■ The TOE supports the following security functions of the SSH v2.0 protocol:
● Establishing a secure communication channel using the following cryptographic functions
provided by the SSH v2.0 protocol:
□ Encryption as defined in section 4.3 of RFC4253 - the keys are generated using the random number
generator of the underlying cryptographic library;
□ Diffie-Hellman key exchange as defined in section 6.1 of RFC4253;
□ The keyed hash function for integrity protection as defined in section 4.4 of RFC4253.
● Performing user authentication using the standard password-based authentication

method the TOE provides for users (password authentication method as defined in
chapter 5 of RFC4252).
● Performing user authentication using a RSA, DSA or ECDSA key-based authentication
method (public key authentication method as defined in chapter 5 of RFC4252).
● Checking the integrity of the messages exchanged and close down the connection in
case an integrity error is detected.
■ The OpenSSH applications of sshd, ssh and ssh-keygen use the OpenSSL
random number generator seeded by /dev/random or /dev/urandom to generate
cryptographic keys.
● OpenSSL provides different DRNGs depending whether the FIPS 140-2 mode is enabled
in the system.
62
IPSEC and IKEv2 Protocol Family (SUSE)
(1)
■ The TOE implements the protocol family of IPSEC and IKE.
■ The Linux kernel handles the ESP / AH processing and the strongSwan
user application covers the IKE protocol suite processing as follows:
● Internet Key Exchange:
□ The IKE protocol establishes the mutual session key used for encrypting the
communication
□ In addition, as part of the IKE protocol the key agreement for the ISAKMP SA is performed
which protects the entire IKE communication
□ The IKE protocol is implemented by the charon daemon and is solely provided with user
space code
□ The cryptographic primitives required for IKE are provided by OpenSSL
● IPSec:
□ Once the keys for the IPSEC SA are exchanged or agreed on, the encryption and
decryption of the actual data that flows over the wire is covered with the IPSec protocols of
ESP, potentially supported by AH
□ In Linux, the kernel exclusively implements the IPSec protocols using the keys established
with the IKE protocol
■ The charon daemon implements the IKEv2 protocol.
● The protocol is specified in RFC5996.
63
IPSEC and IKEv2 Protocol Family (SUSE)
(2)
■ The IPSec implementation of the kernel supports the transport as well as the
tunnel mode
● Thisallows the configuration of a peer-to-peer, a peer-to-network or a network-to-
network scenario.
■ The following RFCs are supported for implementing the IPSec protocol family:
● RFC4301, RFC4303: Defining of SPD/SAD, SA, ESP
● RFC4306, RFC4307: IKEv2 with ISAKMP, Diffie-Hellman group
● RFC3526: Diffie-Hellman groups
● RFC4106: AES GCM mode for IPSec
● RFC4307: Various cipher types for IPSec
● RFC4303: Various cipher types for IPSec
● RFC4309: AES CCM mode for IPSec
● RFC5996: IKEv2
■ The cryptographic implementations ensure that sensitive data is appropriately

zeroized before releasing the associated memory.
64
Confidentiality protected data
storage (SUSE, Ubuntu) (1)
■ File system objects are stored on block devices, such as partitions on hard
disk.
■ The Linux operating systems offers the use of an additional layer between
the file systems and the physical block device to encrypt and decrypt any
data transmitted between the file system and the block device.
■ The dm_crypt functionality uses the Linux device mapper to provide such
encryption and decryption operation that is transparent to the file system and
therefore to the user.
■ Before mounting the block device that is protected by the dm_crypt
encryption scheme, the owner of the encrypted block device has to provide a
passphrase.
● Once the dm_crypt protected device is unlocked and mounted, it is accessible as any
other file system.
● When it is unmounted and locked (i.e. the kernel is informed to discard the volume
key), all data on the device is inaccessible.
□ When an administrator would access the raw hardware hosting the block device, only encrypted
data can be read. 65
Confidentiality protected data
storage (SUSE, Ubuntu) (2)
■ The encryption and decryption operation of the device is implemented by the kernel. To
unlock the encrypted volume key stored on the protected block device, the cryptsetup
application performs the following steps:
1.obtain the user's passphrase
2.apply the LUKS key derivation mechanism on the passphrase
3.read the encrypted volume key from the device
4.decrypt the volume key with the key derived from the user's passphrase
5.inject the decrypted volume key into the kernel and set up the mapping between the block device and
the volume key
■ Using the cryptsetup tool, the volume key can also be transferred by encrypting it with
another passphrase which can be given to another user. Similarly, the cryptsetup tool can
be used to erase the storage location of one encrypted volume key.
■ The key material used for by cryptsetup for the disk encryption mechanism is derived from /
dev/urandom and XORing 13 bytes from /dev/random into the state random number
generator.
■ In FIPS 140-2 mode, the libgcrypt DRBG is used for generating keys seeded by
/dev/urandom XORing 13 bytes from /dev/random.
■ The installer with the exception of IBM System Z allows the configuration of the full disk
encryption schema where the entire disk is protected, except the /boot partition.
66
Network Information Flow
Control (Packet Filter)
■ The Linux kernel's network stack implementation follows the
layering structure of the network protocols.
■ It implements the code for handling the link layer as well as
the network layer.
■ For those layers, independent filter mechanism are provided:
● Link layer (SUSE, Ubuntu): ebtables implements the filtering
mechanism for bridges
● Network layer (RHEL, SUSE, Ubuntu): netfilter/iptables implements
the filtering mechanism for non-bridge interfaces
■ Packet filter rules can only be injected into the Linux kernel
for enforcement by processes possessing the
CAP_NET_ADMIN capability (RHEL)
67
Network layer filtering — Netfilter(1)
■ Netfilter is a framework for packet mangling, implemented in the
Linux kernel network stack handling the network layer.
■ The netfilter framework comprises of the following parts:
● The IP stack defines five hooks which are well-defined points in a network
packet's traversal of the IP protocol stack. Each of the hooks, the network
stack will call the netfilter framework allowing it to operate on the entire
packet.
● The netfilter framework provides register functions for other kernel parts to
listen to the different hooks. When a packet traverses one of the hooks and
passed to the netfilter framework, it invokes every registered kernel part.
These kernel parts then can examine the packet and possibly alter it. As
part of the examination, these kernel parts can instruct the netfilter
framework to discard the packet, to allow it to pass, or to queue it to user
space.
● When a packet is marked to be queued to user space, the netfilter
framework handles the asynchronous communication with user space
68
Network layer filtering — Netfilter(2)
■ The netfilter framework implements the five hooks at the following
points in the packet traversal chain:
● When the packet enters the network layer of the TOE and after applying
some sanity checks, but before the routing table is consulted, the
NF_IP_PRE_ROUTING hook is triggered.
● After passing the routing table decision and the routing code marks the
packet to be targeted for another host, the NF_IP_FORWARD hook is
triggered.
● After passing the routing table decision and the routing code marks the
packet to be targeted for the local system, the NF_IP_LOCAL_IN hook is
triggered.
● When the packet traversed all of the network stack and is about to be
placed on the wire again, the NF_IP_POST_ROUTING hook is triggered.
● When a packet is generated locally, the NF_IP_LOCAL_OUT hook is
triggered before the routing table is consulted.
69
Network layer filtering - IPTables(1)
■ All communication on the network layer can be controlled by the IPTables
framework.
■ The combination of IPTables and netfilter implements the packet filter
which provides stateful and stateless packet filtering for network
communication by inspecting the IP header, the TCP header, UDP header
and/or ICMP header of every network packet that passes the network
stack.
■ The packet selection system called IP Tables uses the netfilter framework
to implement the actual packet filtering logic on the network layer for the
TCP/IP protocol family.
● Note: IPTables is able to perform Network Address Translation (NAT) as well as
Port Address Translation (PAT) for simple as well as more complex protocols.
Furthermore, packet mangling support is provided with IPTables.
■ IPTables registers all hooks provided by the netfilter framework.
● The NAT/PAT mechanism uses the pre-routing and post-routing hooks
● The packet filtering capability is enforced on the local-in, local-out and forwaring
hooks
70
Network layer filtering - IPTables(2)
■ IPTables consists of the following two components:
1)In-kernel packet filter enforcement:
● The kernel-side of IPTables use the netfilter framework.
● Three lists of packet filter rules are enforced by the kernel mechanism:
one for each netfilter framework hook that applies to packet filtering.
● Each list contains zero or more rules which are iterated sequentially.
● A rule consists of a matching part (also called the "match extension")
and an action part (also called the "target extension").
2)User space configuration application:
● The user space application iptables(1) allows the configuration of the
IPTables kernel components.
● The application allows the specification of one rule per invocation where
a rule contains the above mentioned matching part and action part.
● The tool also allows modification or deletion of existing rules as well as
configuration of the default action.
71
Link layer filtering - ebtables chains
■ The link layer code handling the bridging functionality implements chains
that are used by ebtables to apply filtering.
■ The netfilter framework is used to implement the ebtables chains at the
following points in the packet traversal logic:
● When the packet enters the link layer of the TOE and after applying some sanity
checks, but before the bridging decision made, the BROUTING chain is triggered.
● After passing the BROUTING chain but still before the bridging decision, the
PREROUTING chain is triggered. When the bridging code decides that the frame is
not intended for a bridge, it is forwarded to the network layer and processing on the
link layer stops.
● After passing the bridge routing decision and the routing code marks the packet to
be targeted for another host, the FORWARD chain is triggered.
● After passing the bridge routing decision and the routing code marks the packet to
be targeted for the local system, the INPUT chain is triggered.
● When a packet is generated locally and the bridging decision marks the frame to be
intended for a bridge, the OUTPUT chain is triggered.
● When the packet traversed all of the bridge logic and is about to be placed on the
wire again, the POSTROUTING chain is triggered.
72
Link layer filtering —
ebtables filtering rules
■ The packet selection system called ebtables uses the netfilter framework to
implement the actual packet filtering logic for Ethernet frames routed through
bridges.
■ Bridged networking communication is only visible on the link layer.
● As the host system uses bridges to connect virtual machines to the environment, only
ebtables can be used to control the traffic flow.
● The data encapsulated within the Ethernet frames are not routed through the host system's
network stack and can therefore not be analyzed and controlled by the IPTables framework
outlined above.
● Even though the network stack of the host system does not analyze the bridged Ethernet
frames any more, the ebtables framework receives the entire frame and is allowed to operate
on that frame. Therefore, ebtables can analyze the protocol inside the Ethernet frame.
■ The ebtables framework can apply filters based on the following concepts:
● Matching of the frame/packet: Matches are based on Ethernet protocols or source and/or
destination MAC addresses.
● Action to be performed on matched frames: Similarly to IPTables, ebtables must be
configured to perform an action on the matched frame. The action can either be to discard the
packet or to accept it.
73
PAM-based identification and
authentication mechanisms (1)
■ Linux uses a suite of libraries called the "Pluggable Authentication
Modules" (PAM) that allow an administrative user to choose how PAM-
aware applications authenticate users.
■ The TOE provides PAM modules that implement all the security
functionality to:
● Provide login control and establishing all UIDs, GIDs and login ID for a subject
● Ensure the quality of passwords
● Enforce limits for accounts (such as the number of maximum concurrent
sessions allowed for a user)
● Enforce the change of passwords after a configured time including the
password quality enforcement
● Enforcement of locking of accounts after failed login attempts.
● Restriction of the use of the root account to certain terminals
● Restriction of the use of the su and sudo commands
74
PAM-based identification and
authentication mechanisms (2)
■ The login processing sets the real, file system, effective and login UID as well
as the real, effective, file system GID and the set of supplemental GIDs of the
subject that is created.
■ It is up to the client application usually provided by a remote system to protect
the user’s entry of a password correctly (e. g. provide only obscured
feedback).
■ After a successful identification and authentication, the TOE initiates a
session for the user and spawns the initial login shell as the first process the
user can interact with.
■ The TOE provides a mechanism to lock a session either automatically after a
configurable period of inactivity for that session or upon the user's request.
■ User accounts are stored in configuration files (/etc/passwd and /etc/shadow).
● Both are writable to the root user only.
● In addition, /etc/shadow is readable to the root user only.
● Modification of both files is performed using a set of administrative applications.
75
Pluggable Authentication Module
■ PAM is responsible for the identification and authentication subsystem.
■ PAM provides a centralized mechanism for authenticating all services.
■ PAM allows for limits on access to applications and alternate, configurable authentication
methods.
● For more detailed information about PAM, see the PAM project Web site at
http://www.kernel.org/pub/linux/libs/pam.
■ PAM consists of a set of shared library modules, which provide appropriate authentication and
audit services to an application
● Applicationsare updated to offload their authentication and audit code to PAM, which allows the system to
enforce a consistent identification and authentication policy, as well as to generate appropriate audit records.
■ The following programs are enhanced to use PAM:
● login
● passwd
● su,sudo
● useradd, usermod, userdel
● groupadd, groupmod, groupdel
● sshd
● chage
● chfn
● chsh
● newrole
76
Authentication with PAM
1.A PAM-aware application makes a call to PAM to initialize certain data structures. With the
initialization, the calling application provides a name to PAM which ultimately is used to find
the configuration file of the authentication stack configuration in /etc/pam.d/. Usually, that
name equals the application name.
2.The PAM module locates the configuration file for that application from
/etc/pam.d/application_name and obtains a list of PAM modules necessary for servicing that
application. If it cannot find an application-specific configuration file, then it uses
/etc/pam.d/other.
3.Depending on the order specified in the configuration file, PAM loads the appropriate
modules for the PAM operation requested by the calling application (i.e. PAM provides one
call back for each module type – the module type is consistent with the “auth”, “session”,
“password” and “account” sections in the PAM configuration files).
4.The authentication module code performs the requested operation depending on the module
type. The module may require input from the user.
Note: a module may perform operations which hardly have anything to do with authentication, but whose
operations are necessary to set up the user environment.
5.Each authentication module performs its action and relays the result back to the application.
6.The PAM library is modified to create a USER_AUTH type of audit record to note the
success or failure from the authentication module.
7.The application takes appropriate action based on the aggregate results from all
authentication modules.
77
User Identity Changing —
su command
■ The su command is intended for a switch to a another identity that establishes a new
login session and spawns a new shell with the new identity.
■ When invoking su, the user must provide the credentials associated with the target
identity - i.e. when the user wants to switch to another user ID, it has to provide the
password protecting the account of the target user.
■ The primary use of the su command within the TOE is to allow appropriately authorized
individuals the ability to assume the root identity to perform administrative actions.
● The capability to login as the root identity has been restricted to defined terminals only
● The use of the su command to switch to root has been restricted to users belonging to a special
group.
● Users that don’t have access to a terminal where root login is allowed and are not member of that
special group will not be able to switch their real, file system and effective user ID to root even if
they would know the authentication information for root.
■ Note that when a user executes a program that has the setuid bit set, only the effective
user ID and file system ID are changed to that of the owner of the file containing the
program while the real user ID remains that of the caller.
■ The login ID is neither changed by the su command nor by executing a program that
has the setuid or setgid bit set as it is used for auditing purposes.
78
User Identity Changing —
sudo command
■ The sudo command is intended for giving users permissions to
execute commands with another user identity.
■ When invoking sudo, the user has to authenticate with this credentials.
■ Sudo is associated with sophisticated ruleset that can be engaged to
specify which:
● source user ID
● originating from which host
● can access a command, a command with specific configuration flags, or all
commands within a directory
● with which new user identity.
■ When switching identities, the real, file system, and effective user ID,
and real, file system, and effective group ID are changed to the one of
the user specified in the command (after successful authentication as
this user).
79
Authentication Data Management (1)
■ Each TOE instance maintains its own set of users with their passwords
and attributes.
● Although the same human user may have accounts on different servers
interconnected by a network and running an instantiation of the TOE, those
accounts and their parameter are not synchronized on different TOE instances.
● As a result the same user may have different user names, different user Ids,
different passwords and different attributes on different machines within the
networked environment.
■ Each TOE instance within the network maintains its own administrative
database by making all administrative changes on the local TOE
instance.
● The file /etc/passwd contains for each user the user’s name, the id of the user,
an indicator whether the password of the user is valid, the principal group id of
the user and other (not security relevant) information.
● The file /etc/shadow contains for each user a hash of the user's password, the
userid, the time the password was last changed, the expiration time as well as
the validity period of the password and some other information.
80
■ Users are allowed to change their passwords by using the
passwd command.
● This application is able to read and modify the contents of /etc/shadow
for the user’s password entry, which would ordinarily be inaccessible to
a non-privileged user process.
● Users are also warned to change their passwords at login time if the
password will expire soon, and are prevented from logging in if the
password has expired.
■ The time of the last successful logins is recorded in the directory /
var/log/tallylog where one file per user is kept.
■ The TOE displays informative banners before or during the login
to users.
● The banners can be specified with the files /etc/issue for logins via the
physical console or /etc/issue.net for remote logins, such as via SSH.
81
■ SSSD is a system daemon with the primary function of providing access to
identity and authentication remote resource through a common framework that
can provide caching and offline support to the system
● It provides PAM and NSS modules
● It provides also a better database to store local users as well as extended user data
■ SSSD can be configured to use a native LDAP domain (that is, an LDAP
identity provider with LDAP authentication), or an LDAP identity provider with
Kerberos authentication
■ One of the primary benefits of SSSD is offline authentication
● This solves the case of users having a separate corporate account and a local machine
account because of the common requirement to implement a Virtual Private Network
(VPN)
● SSSD can cache remote identities and authentication credentials
● This means that a user can still authenticate with these remote identities even when a
machine is offline
■ In an SSSD system, a user only needs to manage one account
■ SSSD integrates with the PAM and NSS framework and can therefore be used
together with PAM modules for local credential stores
82
SSH key-based authentication
■ In addition to the PAM-based authentication, the OpenSSH server is able to perform a
key-based authentication.
● When a user wants to log on, instead of providing a password, the user applies his SSH key.
● After a successful verification, the OpenSSH server considers the user as authenticated and
performs the PAM-based operations.
■ To establish a key-based authentication, a user first has to generate an RSA, or ECDSA
key pair.
● The private part of the key pair remains on the client side.
● The public part is copied to the server into the file .ssh/authorized_keys which resides in the home
directory of the user he wants to log on as.
■ When the login operation is performed the SSHv2 protocol tries to perform the
"publickey" authentication using the private key on the client side and the public key
found on the server side.
■ The operations performed during the publickey authentication is defined in RFC4252
chapter 7.
■ Users have to protect their private key part the same way as protecting a password.
● Appropriate permission settings on the file holding the private key is necessary.
● To strengthen the protection of the private key, the user can encrypt the key where a password
serves as key for the encryption operation.
83
Session locking
■ The TOE uses the screen(1) application which locks the current
session of the user either after an administrator-specified time of
inactivity or upon the user's request.
■ To unlock the session, the user must supply his password.
■ Screen uses PAM to validate the password and allows the user to
access his session after a successful validation.
84

BOS Merged

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BOS Merged

Uploaded by

Copyright:

Available Formats

Київський політехнічний інститут імені Ігоря Сікорського

Навчально-науковий Фізико-технічний інститут

Автор курсу: Грайворонський Микола Владленович

Безпека ОС - Лекція 01 2/4

1) Модель загроз для ОС

Безпека ОС - Лекція 01 4/4

Автор курсу: Грайворонський Микола Владленович

Безпека ОС - Лекція 02 2/32

 Сканування файлової системи

Безпека ОС - Лекція 02 4/32

Безпека ОС - Лекція 02 5/32

Безпека ОС - Лекція 02 6/32

- якщо його помилково вводять у інше поле введення

Безпека ОС - Лекція 02 7/32

Безпека ОС - Лекція 02 8/32

Безпека ОС - Лекція 02 9/32

Безпека ОС - Лекція 02 10/32

Безпека ОС - Лекція 02 11/32

Безпека ОС - Лекція 02 12/32

Безпека ОС - Лекція 02 13/32

Безпека ОС - Лекція 02 15/32

 порушення функціонування систем (“логічні бомби”):

 модифікація програмного забезпечення:

 психологічний тиск на користувача:

Безпека ОС - Лекція 02 16/32

Безпека ОС - Лекція 02 18/32

Сховище Потік даних

Безпека ОС - Лекція 02 21/32

Безпека ОС - Лекція 02 22/32

Безпека ОС - Лекція 02 24/32

 Надалі: TSF = TOE security functions =

Безпека ОС - Лекція 02 28/32

T.ACCESS.TSFDATA (Доступ до даних КЗЗ)

Безпека ОС - Лекція 02 29/32

T.RESTRICT.NETTRAFFIC (Доступ до мережного

Безпека ОС - Лекція 02 30/32

Безпека ОС - Лекція 02 31/32

T.NETWORK_EAVESDROP (Прослуховування мережі)

Безпека ОС - Лекція 02 32/32

Автор курсу: Грайворонський Микола Владленович

 Будемо вважати захищеною таку ОС,

1 Розроблення захищених систем “з

Безпека ОС - Лекція 03 3/22

 При побудові “довірених” версій шляхом

Безпека ОС - Лекція 03 5/22

Безпека ОС - Лекція 03 6/22

Безпека ОС - Лекція 03 7/22

Безпека ОС - Лекція 03 10/22

Безпека ОС - Лекція 03 11/22

Безпека ОС - Лекція 03 12/22

Керування політикою безпеки ОС

Безпека ОС - Лекція 03 13/22

Безпека ОС - Лекція 03 14/22

Безпека ОС - Лекція 03 15/22

Безпека ОС - Лекція 03 16/22

9.Керування політикою безпеки

Безпека ОС - Лекція 03 17/22

Безпека ОС - Лекція 03 18/22

 Політика безпеки повинна постійно коригуватись з урахуванням змін у конфігурації ОС,

Безпека ОС - Лекція 03 19/22

Безпека ОС - Лекція 03 20/22

Безпека ОС - Лекція 03 21/22

4.Втілення політики безпеки

Безпека ОС - Лекція 03 22/22