Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension
AnimplementationofobjectreusesecurityserviceforatrustedOSbasedonOSGNU/LinuxwithRSBACsecurityextensionisconsidered. It is determined that GNU/Linux and RSBAC extension do not fully meet the requirements to the security service, leaving the system vulnerable to confidentiality and integrity threats. A...
Saved in:
| Date: | 2026 |
|---|---|
| Main Authors: | , |
| Format: | Article |
| Language: | Ukrainian |
| Published: |
PROBLEMS IN PROGRAMMING
2026
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/967 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| _version_ | 1866844994293202944 |
|---|---|
| author | Anisimov, A.V. Ivannikov, E.Yu. |
| author_facet | Anisimov, A.V. Ivannikov, E.Yu. |
| author_institution_txt_mv | [
{
"author": "A.V. Anisimov",
"institution": "Kiev Taras Shevchenko National University"
},
{
"author": "E.Yu. Ivannikov",
"institution": "Kiev Taras Shevchenko National University"
}
] |
| author_sort | Anisimov, A.V. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2026-06-01T21:28:34Z |
| description | AnimplementationofobjectreusesecurityserviceforatrustedOSbasedonOSGNU/LinuxwithRSBACsecurityextensionisconsidered. It is determined that GNU/Linux and RSBAC extension do not fully meet the requirements to the security service, leaving the system vulnerable to confidentiality and integrity threats. Additional security facilities to counteract the threats are proposed.Problems in programming 2010; 4: 11-20 |
| first_indexed | 2026-06-02T01:02:03Z |
| format | Article |
| fulltext |
Методи і засоби програмної інженерії
УДК 004.056.53
А.В. Анісімов, Є.Ю. Іванніков
ПОСЛУГА «КО-1. ПОВТОРНЕ ВИКОРИСТАННЯ ОБ’ЄКТІВ»
ДЛЯ ЗАХИЩЕНОЇ ОС НА БАЗІ GNU/LINUX З
РОЗШИРЕННЯМ RSBAC
Розглядається питання реалізації послуги безпеки «КО-1. Повторне використання об’єктів» для
захищеної ОС, яка базується на ОС GNU/Linux з розширенням безпеки RSBAC. Встановлено, що
стандартні засоби базової ОС та розширення RSBAC не повністю відповідають вимогам, які
накладаються на послугу безпеки. Визначено вразливості, що можуть призвести до реалізації загроз
конфіденційності та цілісності. Запропоновані додаткові заходи захисту для протидії загрозам.
Вступ
До захищених операційних систем
(ЗОС) висувається ряд вимог, дотримання
яких гарантує конфіденційність та ціліс-
ність оброблюваної інформації, а також
доступність та спостережність комп’ютер-
ної системи (КС) в цілому. Ці вимоги
розглядаються як набір функціональних
послуг (послуги безпеки) [1].
Однією із таких послуг є послуга
«КО-1. Повторне використання об’єктів».
Її реалізація дозволяє забезпечити корект-
ність повторного використання розділю-
вальних об’єктів, гарантуючи, що в разі,
якщо розділювальний об’єкт виділяється
новому користувачу або процесу, то він не
містить інформації, яка залишилась від
попереднього користувача або процесу [2].
Функціонально послуга «КО-1»
належить до критеріїв захисту від несанк-
ціонованого ознайомлення з інформацією
(критерії конфіденційності) і розглядається
як така, що є необхідною умовою у
реалізації решти послуг із забезпечення
конфіденційності інформації, що є цілком
очевидним [2]. Більше того, втілення
послуги «КО-1» вимагається і для надання
високих рівнів послуг, які забезпечують
цілісність інформації (послуги «ЦД-3»,
«ЦД-4», «ЦА-3» та «ЦА-4») [2].
Таким чином, послуга безпеки з
повторного використання об’єктів явля-
ється важливою складовою частиною
комплексу засобів захисту (КЗЗ). Її
коректна реалізація дозволяє гарантувати,
що зусилля із впровадженню високих
рівнів інших послуг із захисту даних не
виявляться марними.
Стаття є частиною науково-
дослідної роботи із розробки захищеної
ОС, що проводилась на факультеті
кібернетики КНУ ім. Тараса Шевченка.
Профіль безпеки розроблюваної ЗОС
включає послугу «КО-1. Повторне вико-
ристання об’єктів». Автори ставлять перед
собою задачу впровадження названої
послуги безпеки, вимагаючи, щоб її
реалізація відповідала всім вимогам, які
регламентує нормативний документ [2].
Проведений спеціальний аналіз ОС
Linux та розширення RSBAC засвідчив, що
сама по собі базова ОС не забезпечує
повного виконання зазначених вимог. Далі
буде показана можливість реалізації як
загрози конфіденційності, так і загрози
цілісності оброблюваної інформації.
Протидія цим загрозам полягатиме в
організації додаткових заходів адміністра-
тивного характеру, у використанні сторон-
нього програмного забезпечення та у
модифікації ряду системних додатків.
1. Огляд захищеного середовища
Розроблювана ЗОС базується на
дистрибутиві Debian ОС GNU/Linux з
розширенням RSBAC, яке представляє
собою надбудову над ядром ОС Linux i
набiр утилiт адміністрування [3]. RSBAC
функціонує на рівні ядра і додає власні
перевірки до системних викликів. Система
RSBAC розроблена на основі узагальненої
моделі розмежування доступу GFAC
11
© А.В. Анісімов, Є.Ю. Іванніков, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 4
Методи і засоби програмної інженерії
(Generalized Framework for Access Control),
що була запропонована в роботі [4].
В архітектурі RSBAC засоби для
примусового розмежування доступу,
засоби для прийняття рішення про допус-
тимість чи недопустимість доступу, а
також дані про атрибути безпеки сторін –
учасників доступу реалізовані як окремі
компоненти. Структурно механізм захисту
поділяється на три частини:
1) блок контролю системних
викликів (Access Enforcement Facility –
AEF),
2) блок прийняття рішень (Access
Decision Facility – ADF),
3) сховище інформації про атри-
бути безпеки об’єктів і суб’єктів КС
(Access Control Information – ACI).
Системні виклики доповнюються
кодом блоку контролю AEF, який
перетворює їх у один зі стандартних
(визначених у системі RSBAC) запитів до
блока прийняття рішень ADF. Останній
здійснює опитування модулів політик
безпеки та приймає рішення про допус-
тимість чи недопустимість виклику
(надання чи ненадання доступу) на основі
відповідей модулів. Модулі політик
безпеки отримують інформацію для
прийняття рішень із атрибутів безпеки
ініціатора запита і об’єкта доступу, які
зберігаються у сховищі інформації ACI.
2. Вимоги до реалізації послуги
«КО-1»
Згідно критеріїв [2] послуга «КО-1»
мусить відповідати таким вимогам:
1) політика повторного викорис-
тання об’єктів, що реалізується КЗЗ, має
поширюватись на всі об’єкти КС;
2) перш ніж користувач або процес
зможе отримати у своє розпорядження
звільнений іншим користувачем або
процесом об’єкт, встановлені для поперед-
нього користувача або процесу права
доступу до даного об’єкта мають бути
скасовані;
3) перш ніж користувач або процес
зможе отримати у своє розпорядження
звільнений іншим користувачем або
процесом об'єкт, вся інформація, що
міститься в даному об’єкті, має стати
недосяжною.
Ці вимоги потребують деяких
коментарів. Друга вимога гарантує, що
рішення про надання чи про ненадання
доступу до об’єкта завжди будується на
основі інформації про права доступу на
цей об’єкт ініціатора запиту (суб’єкта).
У розроблюваній ЗОС інформація
про права доступу на об’єкт зберігається
окремо від самого об’єкта, тому постає
питання про тривалість життя інформації
про права доступу. А саме, КЗЗ має
гарантувати, що за жодних обставин
інформація про права доступу не містить
дані про неіснуючі (видалені) об’єкти.
Докладніше це буде розглянуто далі.
Якщо дотримання другої вимоги
можна назвати захистом метаданих (про
права доступу), то дотримання третьої
забезпечує власне захист оброблюваної
інформації. Тут ми розрізняємо ситуацію із
видаленням об’єкта, що має супро-
воджуватись знищенням інформації, яка в
ньому містилась, та ситуацію зі спільним
використанням розділювальних об’єктів
(пам’ять, файл або розділ підкачки,
тимчасові файли і т. д.)
З огляду на перераховані вимоги,
робота буде організована таким чином.
Спочатку серед усіх об’єктів КС будуть
визначені такі їхні типи, на які має
поширюватись функціональність, яку
надає послуга безпеки. Для об’єктів
визначених типів буде проведено аналіз на
предмет відповідності другій вимозі.
Оскільки в розроблюваній ЗОС атрибути
доступу зберігаються окремо від об’єктів,
додатково буде досліджено ситуацію зі
скасування атрибутів доступу об’єктів при
їх видаленні. Нарешті, буде розглянуто
третю вимогу про захист інформації, яка
міститься в об’єктах, що видаляються або
звільняються.
3. Об’єкти захисту
Розроблювана ЗОС базується на
розширенні безпеки RSBAC. Захист від
несанкціонованого доступу здійснюється,
в тому числі, з урахуванням типу об’єкта.
Система RSBAC розрізняє такі типи
об’єктів:
12
Методи і засоби програмної інженерії
1) об’єкти файлової системи
(власне файли, каталоги, файли пристроїв);
сюди відносимо символічні посилання та
іменовані канали (FIFO-файли);
2) процеси як об’єкти системних
викликів;
3) користувачі як об’єкти систем-
них викликів;
4) об’єкти міжпроцесної взаємодії:
семафори, черги повідомлень, спільна
пам’ять, анонімні канали, Unix-сокети
(іменовані та анонімні).
Об’єкти КС, на які має поши-
рюватися захист послугою «КО-1», є
розділювальними об’єктами, що можуть
використовуватися повторно. З огляду на
це, захисту має підлягати інформація, яка
міститься у файлах та сторінках пам’яті
(оперативної і віртуальної).
Уточнимо, що ми розуміємо під
повторним використанням файлів. Справа
полягає у тому, що при видаленні файла
або при зменшенні його розміру файлова
система лише позначає вивільнені блоки
як «незайняті». Як такого знищення
інформації, що зберігається в цих блоках,
не відбувається. Слід наголосити на тому,
що коли користувач видаляє файл, який
містить конфіденційну інформацію, ця
інформація виходить зі сфери контролю
КЗЗ. Цілком зрозуміло, що в захищеній ОС
видалення конфіденційної інформації має
бути не лише логічною операцією
файлової системи. Як правило, тут засто-
совується операція «безпечного вида-
лення» файлів, яка полягає у перезаписі
блоків, що вивільняються, нулями або
випадковими даними.
Ті ж самі міркування стосуються й
оперативної пам’яті. Вивільнення сторінки
пам’яті процесом має супроводжуватись
обнуленням її вмісту, так, щоб будь-який
інший процес, звертаючись до вивільненої
сторінки, не отримав інформацію, яка в ній
містилась раніше.
Повноцінний захист пам’яті КС
передбачає і захист віртуальної пам’яті –
області підкачки (як правило, в середовищі
Linux область підкачки являє собою не
файл, а спеціально виділений окремий
розділ диску). Справді, область підкачки
містить сторінки пам’яті, тимчасово
переміщені на диск. Не можна виключити,
що вивантажені сторінки містять конфі-
денційну інформацію та/або результати її
обробки. Вміст області підкачки жодним
чином не контролюється КЗЗ, отже
реалізація послуги «КО-1» повинна надати
механізм, який гарантуватиме немож-
ливість витоку інформації, яка зберігається
в цій області.
Не можна не порушити питання про
таке потенційне джерело компрометації
інформації, як тимчасові файли. Вони
створюються різними програмами під час
своєї роботи для тимчасового зберігання
інформації, і у деяких випадках (помилка у
програмі або некоректна реалізація)
можуть залишатись на диску, замість того,
щоб бути видаленими.
Якщо для ОС загального приз-
начення їхній вміст вважається «сміттям»,
то для захищеної ОС ці файли можуть
містити конфіденційну інформацію, її
фрагменти або ж результати обробки. Як
правило, тимчасові файли всіх корис-
тувачів створюються у спеціальній сис-
темній директорії /tmp і мають випадкові
імена. Через це, можливість впровадження
адміністративного (або, ще гірше для
даного випадку, довірчого) контролю дос-
тупу до них здається досить сумнівною. Ці
файли підлягають автоматичному вида-
ленню при завантаженні системи або при
виході користувача із неї. Така реалізація
хоч і не позбавлена певних недоліків,
однак дозволяє гарантувати нетривалий
час життя тимчасових файлів.
Також слід виділити ще одну
область, на яку має розповсюджуватись
послуга «КО-1». Мова йде про метадані –
атрибути безпеки об’єктів, які вида-
ляються. Цими об’єктами можуть бути
користувачі, процеси, об’єкти файлової
системи та об’єкти міжпроцесної взаємо-
дії. Атрибути безпеки всіх сутностей КС
(суб’єктів і об’єктів) зберігаються у внут-
рішньому сховищі інформації системи
розмежування доступу RSBAC, окремо від
самих сутностей. Для здійснення доступу
до атрибутів безпеки система RSBAC
використовує різні ідентифікатори, в
залежності від типу сутності.
13
Методи і засоби програмної інженерії
Так, користувачі ідентифікуються
системою на підставі унікального число-
вого ідентифікатора uid. Цей іденти-
фікатор пов’язується із кожним користу-
вачем і є саме тим атрибутом, на основі
якого ОС та КЗЗ у її складі здійснює
довірче розмежування доступу.
Процеси ідентифікуються на
підставі унікального числового іденти-
фікатора pid. Цей ідентифікатор визначає
сутність – суб’єкт доступу при адміністра-
тивному розмежуванні доступу системою
RSBAC.
Файлові об’єкти визначаються іден-
тифікатором пристрою та номером індекс-
ного дескриптора (inode). Відомо, що пара
(ідентифікатор пристрою, номер індекс-
ного дескриптора) є унікальною у межах
всієї віртуальної файлової системи (VFS),
тому вона може використовуватися для
взаємнооднозначного співставлення фай-
ловому об’єкту атрибутів безпеки. Цими
атрибутами можуть бути списки контролю
доступу, мітки адміністративного керу-
вання на основі мандатної моделі та дані
інших модулів безпеки.
Для ідентифікації об’єктів міжпро-
цесної взаємодії використовується інформ-
ація про засіб взаємодії (семафор, черга,
спільна пам’ять, анонімний канал, Unix-
сокет) та унікальне числове значення.
Виникає запитання про те, що
відбувається з атрибутами безпеки при
а) видаленні облікового запису корис-
тувача; б) завершенні роботи процесу;
в) видаленні об’єкта файлової системи;
г) видаленні об’єкта міжпроцесної взаємо-
дії.
При видаленні облікового запису
користувача його числовий ідентифікатор
вивільнюється і може бути використаний
при додаванні нового користувача. При
додаванні нового облікового запису,
користувач разом із ім’ям отримує перший
вільний ідентифікатор зі значенням більше
1000 (значення від 0 до 999, як правило,
зарезервовані для ОС). Таким чином,
новостворений користувач «отримає у
спадок» входження у всі списки контролю
доступу, що були встановлені для
попереднього користувача з тим самим
значенням uid.
Аналогічно, при завершенні роботи
процесу його ідентифікатор pid вивіль-
нюється. Не виключена ситуація, при якій
процес, що запускається пізніше, може
отримати таке значення ідентифікатора
pid, яке використовувалось раніше. В
такому випадку, цей процес отримає
атрибути адміністративного допуску, вста-
новлені для попереднього процесу з тим
самим значенням pid.
При створенні нового об’єкта
файлової системи або міжпроцесної
взаємодії він може отримати таке ж
значення ідентифікатора, яке викорис-
товувалось раніше видаленим об’єктом.
Новий об’єкт отримає всі атрибути
безпеки, що були встановлені для
видаленого об’єкта.
Очевидно, що така ситуація є
неприпустимою. Час життя атрибутів
безпеки має не перевищувати час життя
захищених об’єктів. З метою дослідження
цієї проблеми було проведено аналіз
вихідних кодів системи RSBAC. Резуль-
тати аналізу пропонуються у наступному
підрозділі.
Нами були названі об’єкти, на які
має розповсюджуватись захист послугою
«КО-1». Нагадаємо, що це є файли при
їхньому видаленні або зменшенні розміру,
сторінки оперативної пам’яті при
завершенні виконання процесів, область
підкачки, тимчасові файли, атрибути
користувачів, процесів, об’єктів файлової
системи і міжпроцесної взаємодії.
4. Захист атрибутів прав доступу
Задачу захисту прав доступу, що
виникає при розгляді другої вимоги до
реалізації послуги «КО-1» (вимога про
скасування атрибутів), розділимо на дві
частини. По-перше, проаналізуємо ситу-
ацію з атрибутами доступу при запиті
користувача або процесу на доступ до
звільненого іншим користувачем або
процесом об’єкта. По-друге, звернемося до
питання про час життя атрибутів доступу
відносно часу життя об’єктів.
Перша задача не викликає жодних
труднощів. При перехопленні кожного
системного виклику блок контролю сис-
темних викликів (AEF) завжди повідомляє
14
Методи і засоби програмної інженерії
блоку прийняття рішень (ADF) інфор-
мацію про сторони, задіяні у запиті. Блок
ADF вибудовує рішення про дозвіл або
заборону запиту на підставі, серед іншого,
таких відомостей про ініціатора запиту:
1) числовий ідентифікатор процесу
(pid);
2) числовий ідентифікатор корис-
тувача – власника процесу (uid).
Виявляється, що цих відомостей
цілком достатньо для задоволення другої
вимоги. Справді, модулі контролю доступу
системи RSBAC враховують ці дані при
розмежуванні доступу. При адміністра-
тивному керуванні суб’єкт – ініціатор
запиту є процесом, який ідентифікується
за значенням pid. При довірчому керуванні
суб’єкт – ініціатор запиту є користувачем,
який ідентифікується за значенням uid.
Тому, коли користувач або процес
намагається отримати доступ до
звільненого іншим користувачем або
процесом об’єкта, перевірка запиту
здійснюється виходячи зі значень атри-
бутів ініціатора запиту. Права доступу
попереднього користувача або процесу не
враховуються.
Тепер перейдемо до другої задачі.
Нагадаємо, що при додаванні облікового
запису новостворений користувач може
отримати значення uid, яке належало
попередньому (видаленому) користувачу.
Це призведе до того, що новий користувач
отримає всі права довірчого доступу та
значення адміністративного допуску від
користувача, обліковий запис якого було
видалено.
Така ситуація є вкрай небезпечною.
Дійсно, з точки зору КЗЗ дії нового
користувача будуть цілком санкціоно-
ваними, однак вони можуть становити
реальну загрозу не лише конфіденційності
інформації, але й цілісності.
Розширення безпеки RSBAC
містить набір утиліт адміністрування.
Серед інших, наявні дві утиліти:
acl_rm_user та attr_rm_user. Перша утиліта
видаляє всі входження вказаного
користувача з усіх списків контролю
доступу та з усіх груп довірчого керу-
вання, повністю скасовуючи права
довірчого доступу заданого користувача.
Друга утиліта видаляє всі атрибути,
пов’язані з вказаним користувачем, у тому
числі, й атрибути адміністративного конт-
ролю (рівень допуску, множини категорій і
т. д.)
Наявних програмних засобів цілком
достатньо для вилучення прав і атрибутів
користувача. Однак, оскільки ці засоби
реалізовані як окремі утиліти, їхній запуск
залежить цілковито від адміністратора
безпеки (лише він має право на зміну
атрибутів безпеки). Водночас, стандартні
засоби роботи із обліковими записами
користувачів доступні для запуску
виключно адміністратору КС.
На наш погляд, керування обліко-
вими записами (разом із вилученням атри-
бутів) має виконуватись однією особою –
чи то адміністратором КС, чи то адмініс-
тратором безпеки, що визначається кон-
кретною схемою розподілу обов’язків
адміністраторів (послугою безпеки «НО-2»
або «НО-3») [2]. Тому постає задача з
модифікації стандартних засобів керу-
вання обліковими записами користувачів.
Модифікація засобів має забезпе-
чити автоматичний запуск утиліт RSBAC
для видалення атрибутів користувача із
внутрішнього сховища інформації при
вилученні облікового запису. Далі, стан-
дартні дії, що виконуються при видаленні
облікового запису, мають виконуватись від
імені адміністратора КС; перед запуском
утиліти RSBAC необхідна зміна іденти-
фікатора власника процесу на іденти-
фікатор адміністратора безпеки, що дозво-
лить успішно виконати решту дій
(вилучення атрибутів зі сховища інфор-
мації ACI). Для того, щоб уможливити
зміну ідентифікатора uid необхідні налаш-
тування модуля AUTH системи RSBAC,
який, в загальному випадку, забороняє
запити процесу на зміну значення uid.
Аналіз вихідних кодів RSBAC
показує цілком коректне опрацювання
ситуації, що виникає при завершенні
процесу, при видаленні об’єктів файлової
системи (звичайно, маємо на увазі
видалення останнього жорсткого поси-
лання на об’єкт) та об’єктів міжпроцесної
взаємодії (див. рис. 1). Дійсно, завершення
процесу є системним викликом, який конт-
15
Методи і засоби програмної інженерії
ролюється КЗЗ, тому, під час його вико-
нання функція do_exit() здійснює запуск
функції прийняття рішень блоку ADF, яка,
в свою чергу, викликає функцію
rsbac_remove_target(). Остання видаляє всі
атрибути допуску/доступу суб’єкта (об’єк-
та). Отже, новий процес не отримає атри-
бутів безпеки, які були встановлені для
попереднього процесу з тим самим зна-
ченням pid.
Так само не становить проблеми і
видалення файлового об’єкта, оскільки
воно відбувається в результаті виконання
системних викликів, контрольованих КЗЗ.
Код КЗЗ доповнює функції віртуальної
файлової системи vfs_unlink(), vfs_rmdir(),
vfs_rename_dir(), vfs_rename_other(), так,
що після видалення об’єкта файлової
системи відбувається сповіщення блоку
ADF та подальше скасування всіх атри-
бутів, які були встановлені для цього
об’єкта.
Функції ядра для видалення
семафорів semctl_down() та повідомлень
msgctl_down() супроводжуються викликом
блоку ADF із подальшим скасуванням
атрибутів цих об’єктів міжпроцесної взає-
модії.
Дещо інакше опрацьовується вида-
лення об’єктів спільної пам’яті, анонімних
каналів та Unix-сокетів. Функції, відпо-
відно, shm_destroy(), pipe_release() та
unix_release() безпосередньо викликають
функцію rsbac_remove_target().
У кінцевому підсумку, задача за-
хисту атрибутів прав доступу зводиться
лише до задачі коректного вилучення
облікових записів користувачів, що вима-
гає модифікації відповідних програмних
засобів та налаштування політики безпеки.
Рис. 1. Схема викликів функцій при завершенні роботи процесів та при видаленні
об’єктів
16
Методи і засоби програмної інженерії
5. Захист інформації, яка
міститься в об’єктах
Розглянемо проблему захисту
інформації, яка міститься у файлах, що
видаляються. Як зазначалося, стандартний
прийом тут полягає у перезаписі звіль-
нених блоків нулями або випадковими
даними. Хоча це можна зробити і за
допомогою стандартних засобів ОС Linux
або сторонніх утиліт, однак ми вважаємо,
що в захищеній ОС потрібно якомога
зменшити ймовірність помилки корис-
тувача. Якщо особа має у своєму розпо-
рядженні засоби для видалення файлу як
безпечним способом (із затиранням бло-
ків) так і небезпечним, то ніхто не може
гарантувати, що завжди буде реалізову-
ватись саме перший сценарій.
Окрім видалення, існує ще одна
можливість виходу з-під сфери контролю
КЗЗ інформації, що міститься у блоках
файлів. Мова йде про зменшення розміру
файла в результаті його модифікації.
Вивільнені блоки позначаються як вільні і
можуть стати в подальшому джерелом
компрометації.
Очевидно, що задача контролю
блоків, які вивільняються при зменшенні
розміру файла (надалі – при врізанні фай-
ла) не може здійснюватись користувачем
КС. Функціонування цієї частини послуги
має бути цілком сферою відповідальності
КЗЗ.
Слід також враховувати, що
безпечне видалення файла є ресурсоємною
операцією, яку недоцільно здійснювати
для всіх без винятку файлів. Отже,
політика безпеки, яка реалізується в КС,
має визначати конкретні об’єкти, на які
розповсюджується цей захист.
Тут ми бачимо дві можливості.
Перша полягає у використанні модуля FF
системи RSBAC. Модуль дозволяє для
кожного файла зберігати набір атрибутів
безпеки (прапорців), які є спільними для
всіх суб’єктів доступу. Зокрема, передба-
чається прапорець, встановлення якого
призведе до автоматичного затирання всіх
блоків, зайнятих файлом при видаленні
або врізанні. Адміністратор безпеки здатен
визначити окремі файли або каталоги
(оскільки прапорці можуть успадко-
вуватись), які підлягатимуть безпечному
видаленню та врізанню.
Друга можливість не виключає
першу. Автори пропонують розширити
функціональність, яку надає система
RSBAC і використати можливості адмі-
ністративного контролю доступу для
визначення файлів, які потребують такого
типу захисту. Ідея проста: як відомо, з
кожним файлом у моделі мандатного
управління доступом пов’язується мітка
безпеки. Якщо при видаленні файла або
при зменшенні його розміру значення
мітки безпеки перевищує деяке порогове
значення, тоді блоки, що звільняються,
необхідно перезаписати.
Модульна структура RSBAC доз-
воляє впровадити гнучку політику без-
пеки, в тому числі, і за рахунок розробки
власних модулів безпеки. Контроль за
безпечним видаленням може здійсню-
ватись саме таким модулем.
Його реалізація забезпечить функ-
ціонування ефективної системи контролю
об’єктів. Видалення (врізання) файлів, які
підлягають адміністративному розмежу-
ванню доступу, буде контролюватись
автоматично. Крім того, в адміністратора
безпеки завжди є можливість примусово
гарантувати безпечне видалення (врізання)
файла, встановивши відповідний прапо-
рець модуля FF.
На черзі розгляд задачі захисту
сторінок оперативної пам’яті. Виділення
пам’яті виконується з використанням сис-
темних викликів mmap()/mmap2(). Вони
резервують сторінки пам’яті для процесу.
Посилання на кожну сторінку із таблиці
сторінок віртуальної пам’яті після зазна-
ченого системного виклику є посиланнями
на нульову сторінку, яка доступна лише
для читання всім процесам, та заповнена
нулями, тому якщо процес намагається
прочитати данi з пам’яті, то отримає нулі.
Ядро ОС очищує кожну сторінку
пам’яті перед тим, як користувацький
процес намагається вперше здійснити
запис у неї. При цьому генерується
виключна ситуація збою сторінки (page
fault), яка обслуговується функцією ядра
do_page_fault(). Послідовність ключових
17
Методи і засоби програмної інженерії
викликів функцій у такому випадку пока-
зана на рис. 2.
Проведений аналіз дозволяє
стверджувати, що операція виділення
пам’яті для процесу ядром ОС GNU/Linux
повністю відповідає вимогам, які висува-
ються до послуги повторного викорис-
тання об’єктів.
Розглянемо захист інформації, яка
міститься в області підкачки. Вдамося тут
до криптографічних методів захисту.
Існують вільні програмні засоби, які
дозволяють здійснювати прозоре зашиф-
рування і розшифрування даних вірту-
альної пам’яті. Для реалізації послуги було
обрано пакет loop-AES [5]. loop-aes
пропонує модифіковану версію стандарт-
ного модуля loop ядра ОС GNU/Linux. Цей
модуль дозволяє створити псевдопристрій,
пов’язаний із певним фізичним пристроєм
і на стадії передачі даних від псевдо-
пристрою до реального здійснює їхнє
прозоре зашифрування. При передачі
даних в оберненому напрямку відбу-
вається їхнє розшифрування.
Отже, пов’язавши псевдопристрій,
створений модулем, із реальним
пристроєм, який відповідає за розділ
підкачки та змонтувавши перший, отри-
маємо прозорий та ефективний крипто-
графічний захист вмісту області підкачки.
Після розмонтування псевдопристрою всі
дані, фізично присутні на диску підкачки,
будуть зашифрованими та недоступними
для звичайного монтування.
Модуль loop-aes використовує
алгоритм AES з довжиною ключа, яка
обирається користувачем рівною 128, 192
Рис. 2. Схема викликів функцій перед першим звертанням процесу до виділеної сторінки
пам’яті
18
Методи і засоби програмної інженерії
або 256 бітів, у режимі шифрування CBC
(зчеплення блоків шифротексту). Для
розділів підкачки застосовуються одно-
разові ключі – а саме, при кожному монту-
ванні розділу підкачки автоматично гене-
рується значення нового ключа шиф-
рування. Оскільки монтування розділу
підкачки здійснюється при кожному заван-
таженні ОС, один ключ шифрування вико-
ристовується виключно впродовж одного
сеансу роботи КС.
Інсталяція пакету loop-aes для
дистрибутиву Debian ОС GNU/Linux не
становить труднощів. Усі необхідні кроки
описані в інструкції адміністратора КС,
яка входить до складу пакету.
Нарешті, розглянемо механізм за-
хисту інформації, яка міститься в тим-
часових файлах. Як зазначалося при пос-
тановці задачі, стандартний механізм
захисту, який застосовується у ОС типу
Unix, полягає в автоматичному очищенні
директорії /tmp, яка містить тимчасові
файли при кожному завантаженні системи.
Однак цей механізм слугує лише
для обмеження часу життя тимчасових
файлів і не здатний протидіяти реалізації
загрози збирання сміття впродовж сеансу
роботи КС. Дійсно, специфіка вико-
ристання директорії /tmp зумовлює те, що
ця директорія доступна для всіх корис-
тувачів. Права доступу, які встановлюють
програми при створенні тимчасових
файлів, цілком залежать від цих програм.
Використання команди umask [6] для
маскування прав доступу, що вста-
новлюються за замовчуванням, не можна
вважати адекватним рішенням з огляду на
такі причини. По-перше, користувач або
програма можуть змінити значення маски,
яке було задане адміністратором КС. По-
друге, користувач або програма можуть
змінити права доступу файла, що був
створений. Отже, ми не можемо
гарантовано виключити некоректне приз-
начення прав доступу, тому цілком реаль-
ною є ситуація, коли один користувач
матиме можливість для несанкціонованого
доступу до тимчасового файла, створеного
програмою, яка діє від імені іншого
користувача.
Для боротьби із таким потенційним
джерелом компрометації автори пропо-
нують використати концепцію багато-
екземплярних директорій /tmp [7]. Зміст
поняття полягає у тому, що для кожного
користувача створюється окрема підди-
ректорія у директорії /tmp, власником якої
є цей користувач. Ім’я піддиректорії має
вигляд /tmp/tmp-inst/tmp-<uid>, де <uid> –
значення ідентифікатора користувача.
Ключовою особливістю є те, що корис-
тувацькі процеси звертаються, як і раніше,
до директорії /tmp. При цьому відбу-
вається розв’язання імені /tmp в ім’я
/tmp/tmp-inst/tmp-<uid>. Справжній вміст
директорії /tmp приховується. Таким
чином, директорія /tmp для кожного
користувача містить лише такі файли, що
були створені процесами, які діяли від
його імені. Доступ до тимчасових файлів
інших користувачів стає неможливим
завдяки тому, що кожна директорія з ім’ям
вигляду /tmp/tmp-inst/tmp-<uid> доступна
лише для її власника.
Реалізація схеми заснована на
використанні модуля pam_namespace
бібліотеки PAM [8]. Модуль автоматично і
прозоро виконує вищеописані дії. Його
конфігурування не викликає труднощів і
не є предметом роботи.
Висновки
Авторами був проведений спеціа-
льний аналіз базової ОС GNU/Linux та
розширення безпеки RSBAC на предмет
дотримання вимог, які висуває норматив-
ний документ [2] щодо реалізації послуги
«КО-1. Повторне використання об’єктів».
Дослідження виявило, що деякі об’єкти КС
не охоплюються контролем щодо
повторного використання. Нагадаємо, що
такими об’єктами є атрибути користувачів,
файли при видаленні і врізанні, розділ
підкачки та тимчасові файли. Для
розширення сфери застосування послуги
вважаємо за необхідне вжити таких
додаткових заходів:
1) скористатись модулем FF сис-
теми RSBAC для встановлення контролю
за видаленням і врізанням файлів; на
розгляд вноситься пропозиція розширення
адміністративного контролю системи
19
Методи і засоби програмної інженерії
RSBAC для автоматичного визначення
файлів, які потребують операції безпеч-
ного видалення і врізання на основі
значення їхніх міток доступу;
2) використати стороннє ПЗ для
прозорого шифрування файла підкачки;
3) використати модуль pam_name-
space бібліотеки PAM для створення бага-
тоекземплярних директорій, де зберігати-
муться тимчасові файли.
Підготовка роботи супроводжува-
лась реалізацією та дослідною експлуата-
цією запропонованих рішень у ході роз-
робки захищеної ОС на базі дистрибутиву
Debian ОС GNU/Linux. Подальша робота
над послугою полягає у модифікації сис-
темних утиліт для роботи із обліковими
записами користувачів, що забезпечить
повне впровадження послуги безпеки
«КО-1. Повторне використання об’єктів».
1. НД ТЗІ 1.1-002-99. Загальні положення
щодо захисту інформації в комп’ютерних
системах від несанкціонованого доступу. –
К.: ДСТСЗІ СБ України, 1999. – 21 с.
2. НД ТЗІ 2.5-004-99. Критерії оцінки
захищеності інформації в комп’ютерних
системах від несанкціонованого доступу. –
К.: ДСТСЗІ СБ України, 1999. – 59 с.
3. Ott A. Regelsatz-basierte Zugriffskontrolle
nach dem „Generalized Framework for
Access Control” Ansatz am Beispiel Linux. –
Diplomarbeit. Universität Hamburg, 10.
November 1997.
http://www.rsbac.org/doc/media/dipl-ps.zip.
4. LaPadula L.J. Essay 9: Rule-Set Modeling of
a Trusted Computer System // Information
Security: An Integrated Collection of Essays /
Ed. by M. D. Abrams, S. Jajodia, H. J. Podell.
— Los Alamitos, California, USA: IEEE
Computer Society Press.
http://www.acsac.org/secshelf/
book001/09.pdf
5. http://loop-aes.sourceforge.net
6. Сивер Э., Спейнауэр С., Фиггинс С.,
Хекман Д. Linux. Справочник / Пер. с англ.
– СПб: Символ-Плюс, 2001. – 912 с.
7. Romans R. Improve security with
polyinstantiation using a Pluggable
Authentication Module to protect private data
// IBM developerWorks, 26 Feb 2008. – 9 p.
8. Morgan A., Kukuk T. The Linux-PAM System
Administrators’ Guide.
http://www.kernel.org/pub/linux/libs/pam/
Linux-PAM-html/Linux-PAM_SAG.html
Отримано 12.01.2010
Про авторів:
Анісімов Анатолій Васильович,
доктор фізико-математичних наук,
член-кореспондент НАН України,
завідувач кафедрою математичної
інформатики КНУ ім. Тараса Шевченка,
Іванніков Євген Юрійович,
аспірант кафедри математичної
інформатики КНУ ім. Тараса Шевченка.
Місце роботи авторів:
Київський національний університет
ім. Тараса Шевченка,
Україна, 03680, Київ-680,
Проспект Академіка Глушкова, 2,
корпус 6.
Тел.: 38 044 259 0427
E-mail:
ava@unicyb.kiev.ua
ivannikoff@meta.ua
20
http://www.rsbac.org/doc/media/dipl-ps.zip
http://www.acsac.org/secshelf/%0Bbook001/09.pdf
http://www.acsac.org/secshelf/%0Bbook001/09.pdf
http://loop-aes.sourceforge.net/
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html
ПОСЛУГА «КО-1. ПОВТОРНЕ ВИКОРИСТАННЯ ОБ’ЄКТІВ» ДЛЯ ЗАХИЩЕНОЇ ОС НА БАЗІ GNU/LINUX З РОЗШИРЕННЯМ RSBAC
|
| id | pp_isofts_kiev_ua-article-967 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Ukrainian |
| last_indexed | 2026-06-02T01:02:03Z |
| publishDate | 2026 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/2a/102227619fa3659dabb20ac59c1bc52a.pdf |
| spelling | pp_isofts_kiev_ua-article-9672026-06-01T21:28:34Z Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension Услуга "КО-1. Повторное использование объектов" для защищенной ОС на базе GNU/Linux с расширением RSBAC Послуга "КО-1. Повторне використання об’єктів" для захищеної ОС на базі GNU/Linux з розширенням RSBAC Anisimov, A.V. Ivannikov, E.Yu. UDC 004.056.53 УДК 004.056.53 УДК 004.056.53 AnimplementationofobjectreusesecurityserviceforatrustedOSbasedonOSGNU/LinuxwithRSBACsecurityextensionisconsidered. It is determined that GNU/Linux and RSBAC extension do not fully meet the requirements to the security service, leaving the system vulnerable to confidentiality and integrity threats. Additional security facilities to counteract the threats are proposed.Problems in programming 2010; 4: 11-20 Рассматривается вопрос реализации услуги безопасности «КО-1. Повторное использование объектов» для защищенной ОС на основе ОС GNU/Linuxс расширением безопасности RSBAC. Установлено, что стандартные средства базовой ОС и расширения RSBAC не полностью отвечают требованиям, накладываемым на услугу безопасности. Определены уязвимости, могущие привести к реализации угрозы конфиденциальности и целостности. Предложены дополнительные средства защиты для противодействия угрозам.Problems in programming 2010; 4: 11-20 Розглядається питання реалізації послуги безпеки «КО-1. Повторне використання об’єктів» для захищеної ОС, яка базується на ОС GNU/Linux з розширенням безпеки RSBAC. Встановлено, що стандартні засоби базової ОС та розширення RSBAC не повністю відповідають вимогам, які накладаються на послугу безпеки. Визначено вразливості, що можуть призвести до реалізації загроз конфіденційності та цілісності. Запропоновані додаткові заходи захисту для протидії загрозам.Problems in programming 2010; 4: 11-20 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2026-06-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/967 PROBLEMS IN PROGRAMMING; No 4 (2010); 11-20 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2010); 11-20 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2010); 11-20 1727-4907 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/967/1035 Copyright (c) 2026 PROBLEMS IN PROGRAMMING |
| spellingShingle | UDC 004.056.53 Anisimov, A.V. Ivannikov, E.Yu. Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title | Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title_alt | Услуга "КО-1. Повторное использование объектов" для защищенной ОС на базе GNU/Linux с расширением RSBAC Послуга "КО-1. Повторне використання об’єктів" для захищеної ОС на базі GNU/Linux з розширенням RSBAC |
| title_full | Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title_fullStr | Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title_full_unstemmed | Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title_short | Object reuse security service for a trusted OS based on GNU/Linux with RSBAC extension |
| title_sort | object reuse security service for a trusted os based on gnu/linux with rsbac extension |
| topic | UDC 004.056.53 |
| topic_facet | UDC 004.056.53 УДК 004.056.53 УДК 004.056.53 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/967 |
| work_keys_str_mv | AT anisimovav objectreusesecurityserviceforatrustedosbasedongnulinuxwithrsbacextension AT ivannikoveyu objectreusesecurityserviceforatrustedosbasedongnulinuxwithrsbacextension AT anisimovav uslugaquotko1povtornoeispolʹzovanieobʺektovquotdlâzaŝiŝennojosnabazegnulinuxsrasšireniemrsbac AT ivannikoveyu uslugaquotko1povtornoeispolʹzovanieobʺektovquotdlâzaŝiŝennojosnabazegnulinuxsrasšireniemrsbac AT anisimovav poslugaquotko1povtornevikoristannâobêktívquotdlâzahiŝenoíosnabazígnulinuxzrozširennâmrsbac AT ivannikoveyu poslugaquotko1povtornevikoristannâobêktívquotdlâzahiŝenoíosnabazígnulinuxzrozširennâmrsbac |