Зміна ідентифікатора користувача

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

Авторизація доступу до полів документа в Notes
Програмний комплекс Lotus Notes, широко визнаний як краща основа для реалізації систем документообігу, дозволяє встановлювати права на окремі поля або групи полів документа, а стандартна техніка реалізації наведених вище вимог полягає в тому, аби спочатку надати користувачеві право запису в полі, де має бути підпис, а потім — після підписання — це право тут же зняти. Втім, при реалізації складних циклів документообігу, взаємозв'язаних документів, що включають багато, незрідка виникають ситуації, нерозв'язні за допомогою лише цих засобів [Керн/лінд 2000].

Можна навести і інший приклад, тісніше пов'язаний з темою книги: для зміни інформації про користувача необхідний доступ для запису у відповідну базу даних, але не у всю, а лише в певний запис. Цілком природно і навіть необхідно дати користувачеві можливість міняти пароль, не звертаючись до адміністратора. З іншого боку, абсолютно недопустимо, аби один користувач, не будучи адміністратором облікових записів, міг змінити пароль іншому.
Одним з рішень було б зберігання пароля для кожного з користувачів в окремому файлі, але це у багатьох відношеннях незручно. Інше рішення може полягати у використанні моделі клієнт-сервер з процесом-сервером, що виконується з привілеями адміністратора, який є єдиним засобом доступу до паролів. Наприклад, в Win32 весь доступ до призначеної для користувача бази даних здійснюється через системні виклики, тобто функції процесу-сервера виконує само ядро системи.
У системах сімейства Unix для цієї мети був запропонований оригінальний механізм, відомий як setuid (setting of user id - установка [ефективного] ідентифікатора користувача). По легенді, ідея цього механізму виникла саме при рішенні задачі про те, як же користувачі зможуть міняти свої паролі, якщо їх хэши зберігатимуться в одному файлі.

Установка ідентифікатора користувача в Unix
У Unix кожне завдання має два призначені для користувача ідентифікатори: реальний і ефективний. Реальний ідентифікатор зазвичай збігається з ідентифікатором користувача, що запустив завдання. Для перевірки прав доступу до файлів і інших об'єктів, проте, використовується ефективний ідентифікатор. При запуску звичайних завдань реальний і ефективний ідентифікатори збігаються. Неспівпадання може виникнути при запуску програми зі встановленою ознакою setuid. При цьому ефективний ідентифікатор для завдання встановлюється рівним ідентифікатору господаря файлу, що містить програму.
Ознака setuid є атрибутом файлу, що зберігає завантажувальний модуль програми. Лише господар може встановити цю ознаку, таким чином, передаючи іншим користувачам право виконувати цю програму від свого імені. При модифікації файлу або при передачі його іншому користувачеві ознака setuid автоматично скидається.
Наприклад, програма /bin/passwd, що викликається для зміни пароля, належить користувачеві root, і у неї встановлена ознака setuid. Будь-який користувач, що запустив цю програму, отримує завдання, що має право модифікації призначеної для користувача бази даних, — файлів /etc/passwd і /etc/shadow. Проте, перш ніж виробити модифікацію, програма passwd перевіряє допустимість модифікації. Наприклад, при зміні пароля вона вимагає ввести
старий пароль (мал. 12.20). Змінити пароль користувачеві, який його забув, може лише root.
Іншим прикладом setuid-программы може служити програма /bin/ps (process status — стан процесів) в старих системах. До встановлення стандарту на псевдофайлову систему /proc, Unix не надавала штатних засобів для здобуття статистики про процеси, що виконуються. Програма /bin/ps в таких системах аналізувала віртуальну пам'ять ядра системи, доступну як файл пристрою /dev/kmem, знаходила в ній список процесів і виводила ті, що містяться в списку дані. Природно, лише привілейована програма може здійснювати доступ до /dev/kmem.

Мал. 12.20. Зміна ідентифікатора користувача в Unix

Механізм setuid був винайдений одним з отцов-основателей Unix, Деннісом Рітчи, і запатентований компанією AT&T в 1975 р. Через декілька місяців після здобуття патенту, йому був дан статус public domain. Офіційно AT&T пояснила це тим, що плату за використання даного патенту недоцільно робити високою, а збір невеликої плати з великого числа користувачів незручний і теж недоцільний.
Механізм setuid дозволяє видавати привілеї, доступні лише суперкористувачеві, як окремим користувачам (при цьому setuid-программа повинна явним чином перевіряти реальний ідентифікатор користувача і порівнювати його з власною базою даних), так і групам (при цьому досить передати setuid-программу відповідній групі і дати їй право виконання на цю програму), таким чином, частково компенсуючи недостатню гнучкість стандартної системи прав доступу і привілеїв в системі Unix.

Серверні агенти в Notes
До досконалості механізм setuid доведений в Lotus Notes (цей пакет відноситься до прикладних програм, а не операційних систем, але реалізує власні схеми аутентифікації і авторизації). У цій системі всі об'єкти бази даних, у тому числі і агенти (процедури, що зберігаються), забезпечені електронним підписом. Серверні агенти виконуються не від імені користувача, що ініціював операцію, а від імені того, ким агент підписаний. В даному випадку підпис коди означає, що або користувач сам займався розробкою агента, або він явним чином погодився узяти на себе відповідальність за результати його роботи. Підпис підроблювати практично неможливо (використовується алгоритм RSA з 631-бітовим ключем) [redbooks.ibm.com sg245341].