Модель Грехема-Деннінга

Основу моделі складають такі компоненти[3]:

• Множина об'єктів O — сутностей, доступ до яких повинен контролюватися. Прикладами об'єктів у контексті ОС є сторінки оперативної пам'яті, програми, пристрої зовнішньої пам'яті комп'ютера, інструкції та файли.
• Набір суб'єктів S, чий доступ до об'єктів повинен контролюватися. Під суб'єктом зазвичай мають на увазі пару (процес, домен), в якій процес являє собою активну виконувану програму, а домен — оточення, в якому виконується процес. Прикладами доменів в системі IBM System/370 є стани процесора, супервізора або прикладної програми.

Так як суб'єкти системи повинні бути захищені, вони в свою чергу також розглядаються як об'єкти. Для кожного об'єкта визначений суб'єкт-«власник», а для кожного суб'єкта — суб'єкт-«контролер», які мають особливі права до даного об'єкту або суб'єкту відповідно[4].

• З кожним типом об'єкта асоціюється спеціальний керуючий процес — монітор звернень, через який проходять всі спроби доступу до об'єктів. Прикладами моніторів є, наприклад, системні файли, обладнання для виконання інструкцій та адресації пам'яті.
• Набір правил доступу R, які визначають можливий вид доступу суб'єкта по відношенню до об'єкта. У моделі Грехема-Деннінга визначаються наступні правила доступу, що задають дії та операції, які суб'єкт може виконати над об'єктом[5].
  • Створення об'єкта, створення суб'єкта, видалення об'єкта і видалення суб'єкта дозволяють суб'єкту створити новий об'єкт/суб'єкт у системі або, відповідно, видалити існуючий.
  • Читання прав доступу дозволяє суб'єкту визначити поточні права доступу суб'єкта до об'єкта.
  • Призначення прав доступу дозволяє власнику об'єкта призначити будь-яке право доступу до об'єкта для іншого суб'єкта.
  • Вилучення прав доступу дозволяє суб'єкту видалити право іншого суб'єкта по відношенню до об'єкта (суб'єкт, що видаляє права, є або власником об'єкта, або контролером суб'єкта, права якого видаляються).
  • Передача прав доступу дозволяє суб'єкту передати одне з його прав до об'єкта іншому суб'єкту. Поділяють передаються або непередавані права. Якщо суб'єкт отримує передаване право, він може потім передати це право (як передається чи ні) іншому суб'єкту. Якщо суб'єкт отримує непередаване право, він може використовувати це право, але не може передати це право іншому суб'єкту.
• Правила зазвичай задаються матрицею контролю доступу , в якій рядки відповідають суб'єктам, стовпці — об'єктам (включаючи суб'єкти), а елементи таблиці (так звані атрибути доступу) A[S,O] містять список дозволених привілеїв суб'єкта s до об'єкта o.

У таблиці наведені операції для роботи з матрицею доступу і відповідні перед - і пост умови[6]. Суб'єкт, що виконує кожну з команд, позначений x. r* — право доступу, яке може бути згодом передано іншому суб'єкту. Відповідно, право r (без символу '*') вважається непередаваним.

Модель безпеки повинна вирішувати наступні задачі[7]:

1. відобразити стан безпеки,
2. дати суб'єктам доступ до об'єктів лише у випадках і видах, дозволених станом безпеки,
3. і дозволити суб'єктам захисту в певному сенсі змінювати стан безпеки.

Перша задача легко вирішується моделлю, так як стан безпеки системи наочно представляється матрицею доступу А.

Виконання третього завдання ґрунтується на правилах зміни матриці доступу. Зміна стану безпеки системи, або, що те ж саме, зміна матриці доступу в моделі визначається наступним чином. По-перше, правила повинні змінювати матрицю самі. По-друге, ці правила повинні виконуватися моніторами матриці доступу, які на відміну від моніторів об'єктів системи, можуть змінювати матрицю доступу. По-третє, монітор матриці доступу може змінювати (додавати або видаляти) атрибути доступу тільки при належній авторизації суб'єкта, запитувача зміна. Для цієї мети до моделі введено зазначені вище поняття власник і контролер, а також передання прав.

Друга задача вирішується в припущенні, що будь-яка спроба доступу суб'єкта до об'єкта перехоплюється і перевіряється монітором звернень (реалізація цієї вимоги залишається за розробниками системи). Доступ суб'єкта s до об'єкта o відбувається наступним чином[2]:

1. s ініціює доступ до o в манері атрибута а
2. система надає трійку (s, a, o) монітору O 
3. Монітор O запитує матрицю доступу про наявність а в A[s, o]. Якщо атрибут є, доступ дозволяється; в іншому випадку він забороняється і застосовуються заходи щодо усунення порушення.

Зауважимо, що атрибути доступу інтерпретуються моніторами об'єктів під час спроби доступу. Тому, навіть якщо суб'єкт s знає ідентифікаційний номер кожного іншого суб'єкта, в s немає можливості змінити факт, що його номер надається монітора; отже, монітор не може бути обдурять запрашиванием невірної сутності в А[3]. Так як ні в яких суб'єктів немає доступу до А, на підставі вищевикладеного можна побудувати доказ, що підтверджує коректність системи безпеки

Щоб довести коректність описаної моделі безпеки, покажемо, що суб'єкт може отримати доступ до об'єкта тільки будучи авторизованим[2].

Потрібно показати, що:

• будь-яка дія суб'єкта, не змінює стан безпеки, повинно бути авторизованим доступом;
• і будь-яка дія суб'єкта, яка змінює стан безпеки, не може вести до нового стану, в якому б у деяких суб'єктів був неавторизований доступ до об'єктів.

Для доказу першого, досить показати коректність кожного монітора: це випливає з того, що прикріплення системою ідентифікатора абонента суб'єкта до кожної операції робить неможливим для суб'єкта отримати неавторизований доступ до об'єктів. В основі докази лежить головне припущення моделі, що система прикріплює невідчужуваний ідентифікатор до кожної спробі доступу. Якщо модель імплементована вірно (ОС прикріплює ідентифікатор коректно, монітор запитує правильну сутність матриці доступу, і ніякої монітор (крім монітора матриці доступу) не змінює вміст матриці доступу), то перше вимогу коректності моделі виконано.

Розглянемо друге, припускаючи коректність монітора матриці доступу. Очевидно, що кожна операція в системі створює новий стан безпеки, визначеної відповідним правилом манері. Тим не менш, правил є різні аспекти довіри: зокрема, якщо власник даного об'єкту не обережний, то у ненадійних суб'єктів з'являється можливість, діючи поодинці або спільно, дати деяким суб'єктам доступ до об'єктів, не подразумевавшийся власником об'єкта[8]. Так як модель не може задовільно вирішити проблему довіри, це демонструє необхідність зовнішнього регулювання або законів для имплементированного технічного рішення.

Покажемо останнім на прикладі.

Розглянемо передачу і створення прав доступу. Припустимо суб'єкт s1 створив об'єкт х і дав різні типи доступу до х суб'єктам s2 — sn. Припустимо також, що s1 хоче, щоб у s0 ні за яких обставин не було доступу до x. Він може зробити це, не даючи ніяких атрибутів доступу s0, але він також повинен створювати непередавані права всім суб'єктам s2-sn, які можуть порушити довіру і дати доступ до x s0 безпосередньо. Іншими словами, має бути розуміння між s1 та суб'єктами, які отримують доступ до x, що s0 не повинен одержати, прямо або побічно, доступ до x. Тільки якщо таке розуміння досягнуто і реквізити довіри представлені, s1 може призначати передаються права доступу. Тоді, правила створення і передачі прав доступу коректні.

Розглянемо правило створення суб'єкта. Коректність оточення створеного суб'єкта заснована на припущенні, що оточення контролера коректно, так як підлеглий суб'єкт не може мати атрибут доступу, якого немає у контролера. Таким чином, коректність оточення всіх суб'єктів випливає безпосередньо з того, що для користувача, коли він входить у систему, створено коректне оточення. Тут виникає проблема неправильної ідентифікації, яка не може бути вирішена моделлю абсолютно. Знову, для запобігання порушень безпеки системи, потрібно система виявлення та оповіщення порушень і зовнішнє регулювання.

Отже, система захисту коректна і буде оперувати саме як передбачалося серед довірених суб'єктів[2]. Для включення в систему ненадійних суб'єктів, механізмів системи безпеки недостатньо, необхідно зовнішнє регулювання, спільно з системою виявлення порушень і звіту.