Повноваження

У чистому вигляді модель авторизації на основі повноважень реалізована в системах Burroughs і Intel 432, які детальніше розглядаються в разд. Сегменти, сторінки і системні виклики і Взаємно недовіряючі підсистеми. Повноваження доступу до сегментів єдиного адресного простору в цих системах реалізовані у вигляді полів селектора сегменту або мандатів, а неможливість самостійної їх генерації користувачем забезпечена тэговой архітектурою і забороною арифметичних операцій над сегментною частиною покажчика.
Системи з моделями безпеки, засновані на одних лише повноваженнях, не мали комерційного успіху. Проте концепція повноважень поширена набагато ширше, ніж це прийнято думати. Так, реалізація моделі безпеки на основі ACL можлива лише постільки, поскільки системні модулі мають повноваження робити що завгодно, не звертаючись ні до яких ACL (зокрема, і повноваження виконувати перераховані в ACL операції), а призначений для користувача код таких повноважень не має. Через це, користувач може виконувати необхідні йому операції лише за допомогою звернення до системних модулів.
Лише у цих умовах перевірка ACL перед входом в системний модуль має сенс — якби користувач міг би виконати операцію сам або викликати системні підпрограми без обмежень, обхід будь-якого ACL виконувався б очевидним чином.
Зокрема, тому в системах з відкритою пам'яттю неможливі скільки-небудь ефективні засоби управління доступом: користувач має можливість виконувати будь-які операції самостійно, а при використанні криптографічного захисту може викрасти ключ або модифікувати алгоритм шифрування.
Типова практично використовувана архітектура управління доступом надає користувачеві і системному адміністраторові управління правами у формі списків контролю доступу і містить один або декілька простих типів повноважень, аби запобігти доступу в обхід цих списків. Простою структурою таких повноважень є розділення призначеного для користувача і системного режимів роботи процесора і виконання всієї коди, що не користується довірою, в призначеному для користувача режимі.
Системний режим процесора є повноваженням або, в усякому разі, може застосовуватися як таке: володіння їм дозволяє виконувати операції, недопустимі в призначеному для користувача режимі, і цей режим не може довільно встановлюватися. Він дозволяє реалізувати не лише ACL, але і додаткові повноваження: користувач не має доступу в системний адресний простір, тому система може розглядати ті або інші атрибути дескриптора призначеного для користувача процесу як повноваження (мал. 12.18).
Ідентифікатор користувача, що встановлюється при аутентифікації і зберігається в дескрипторі процесу в адресному просторі ядра, також може розглядатися як повноваження. Для того, щоб цей ідентифікатор дійсно можна було використовувати таким чином, необхідно ввести вельми жорсткі обмеження на те, хто і яким чином може виробляти аутентифікацію.
Два підходи до рішення цієї задачі — це здійснення аутентифікації модулями ядра і введення спеціального ідентифікатора користувача (або спеціального типа процесів).

Мал. 12.18. Зберігання повноважень в системному адресному просторі

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

Аутентифікація в Unix
У системах сімейства Unix процеси з ефективним призначеним для користувача ідентифікатором, рівним 0, мають право виконувати системні виклики setuid і setgid і, таким чином, ставати іншими користувачами. Інші користувачі не мають такої можливості, тому всі процеси, в тій або іншій формі, здійснюючу аутентифікацію і зміну ідентичності, як із застосуванням стандартних системних засобів (файлів /etc/passwd і /etc/shadow в старих системах і бібліотек РАМ, що розділяються, в сучасних), так і самостійно, зобов'язані виконуватися від імені цього користувача.
Оскільки користувач з ідентифікатором 0 (root) може набувати ідентичності інших користувачів, він, як вже говорилося, фактично володіє всіма правами, які є у кого б то не було іншого в системі. Визнавши цей факт, розробники Unix явним чином дали користувачеві root взагалі всі права, у тому числі і такі, яких не має ніхто інший.
Ми вже відзначали в разд. Списки контролю доступущо root може виробляти будь-які операції над файлами, безвідносно до того, кому вони належать і які права у них встановлені, root також має можливість перезавантажувати систему, в ОС з динамічним завантаженням модулів ядра — завантажувати, вивантажувати і перенастроювати ці модулі, запускати процеси з класом планерування реального часу, посилати сигнали чужим процесам (прості смертні можуть це робити лише зі своїми процесами) і виконувати безліч інших операцій, недоступних іншим користувачам. Фактично, всі дії, так або інакше що зачіпають систему в цілому, є винятковою прерогативою користувача root [Хевіленд/грей/салама 2000].
У невеликих і середніх організаціях це не представляє проблеми, тому що всі функції, що вимагають привілеїв root, — резервне копіювання і відновлення даних, реєстрація користувачів і управління їх повноваженнями і власне налаштування системи виконуються однією людиною або командою більш менш взаємозамінних людей, посада яких і називається системний адміністратор.
У крупних організаціях перераховані функції можуть виконуватися різними людьми: адміністратором облікових записів (account manager), адміністратором даних (data administrator) (або адміністратором резервних копій) і власне системним адміністратором (мал. 12.19).
Механізм, що надається системами сімейства Unix, який може бути використаний для реалізації такого розділення повноважень, обговорюватиметься в разд. Зміна ідентифікатора користувача. Декілька забігаючи вперед, скажімо, що рішення полягає в тому, аби дозволити адміністраторам облікових записів і даних запуск з повноваженнями root лише певних програм (наприклад, утиліт управління користувачами і резервного копіювання), але не запуск довільних програм і не виконання довільних дій.

Мал. 12.19. Розділення повноважень адміністраторів системи

Багато постачальників комерційних Unix-систем надають комплектації ОС з підвищеним рівнем безпеки, що містять засоби для згаданого вище розділення повноважень між адміністраторами. Аутентифікація для повноправного входу в систему з ім'ям root в таких системах зазвичай передбачає введення декількох паролів, які, за задумом, мають бути відомі різним людям, так що для виконання всіх дій, що вимагають повних адміністративних повноважень, необхідно збирати комісію., Як правило, така комісія складається з одного або декількох технічних фахівців і одного або декількох представників керівництва компанії.
ОС в такій комплектації застосовуються на центральних серверах крупних компаній, в банківських системах і інших застосуваннях, де ведеться робота з коштовними і високо конфіденційними даними.

Багато ОС надають і повноваження доступу до окремих об'єктів — для того, щоб не перевіряти ACL об'єкту при кожній операції. Так, в системах сімейства Unix права доступу до файлів перевіряються лише у момент відкриття. При відкритті необхідний вказати бажаний режим доступу до файлу: лише читання, лише запис або чтение/запись. Після цього користувач отримує "ручку" - - індекс дескриптора відкритого файлу в системних таблицях.
Ручка є цілим числом і не має сенсу у відриві від відповідного їй дескриптора, зате дескриптор є типовим повноваженням: він недоступний призначеному для користувача коду безпосередньо, тому що знаходиться в системному адресному просторі. Дескриптор може бути сформований лише системним викликом open і допускає лише ті операції над файлом, які були запитані при відкритті. Під час виконання операцій перевірка прав доступу не виробляється (хоча, звичайно, перевіряється їх фізична здійснимість: наявність місця на пристрої і т. д.), так що якщо ми змінимо ACL файлу, це жодні вплине на права процесів, що відкрили файл до цієї модифікації.