Теорія операційної системи

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Условия получения красного диплома Если же ваши оценки оставляют желать лучшего, то вы можете купить настоящий диплом у нас и самостоятельно проставить нужные вам оценки. А условия получения красного диплома вы можете узнать в вашем университете, а также на сайте Министерства образования и науки России. Красный диплом значительно повышает шансы трудоустроиться на престижную работу.

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

  Ти прийшли до мене вранці, ти сіла на ліжко
Ти запитала, чи є у мене дозвіл
дихати
І чи дійсний мій пропуск
Щоб вийти в кіно
Б. Гребенщиков

У чистому вигляді модель авторизації на основі повноважень реалізована в системах 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 файлу, це жодні вплине на права процесів, що відкрили файл до цієї модифікації.

 

:: Реклама ::

продажа пиломатериала оптовая в Твере

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017