Искусство Sudo: Контроль доступа пользователей для реальных людей

Содержание
Глава 1: Введение в sudo
Глава 2: sudo и sudoers (файл /etc/sudoers)
Глава 3: Редактирование и тестирование sudoers
Глава 4: Списки и псевдонимы
Глава 5: Опции и значения по умолчанию
Глава 6: Экранирующая оболочка, редакторы и политики sudoers
Глава 7: Конфигурирование sudo
Глава 8: Среда пользователя против sudo
Глава 9: Sudo для обнаружения вторжений
Глава 10: Распространение sudoers и сложные политики
Глава 11: Политики безопасности в LDAP
Глава 12: Журналирование и отладка в sudo
Глава 13: Аутентификация
Послесловие

Для затравки 🙂

Глава 1: Введение в sudo

Контроль доступа пользователя к привилегированным программам и файлам, как правило, является головной болью. Ни одна из систем, которые создавались для отражения привилегий реального мира на цифровое пространство, не работает достаточно хорошо. Лучшие системы контроля доступа просто менее болезненны чем прочие.

Unix-подобные системы управляют доступом к программам и файлам посредством системы пользователей и групп. Каждый пользователь имеет уникальный идентификатор передаваемый ему как имя пользователя или идентификационного номера пользователя (user ID — UID). Пользователи помещаются в однозначно идентифицированных группах которым присваиваются идентификационные номера груп (group ID — GID). Отдельные пользователи и группы имеют разрешение на доступ к определённым файлам и программам.

В начале развития UNIX этой схемы было вполне достаточно. Большой университет мог иметь несколько UNIX-серверов. Сотни пользователей, зарегистрированные на каждом почтовом сервере, сервере новостей и в приложениях интенсивных вычислений. Студенты определялись в одну группу, аспиранты в другую, затем профессора и так далее. Индивидуальные классы и департаменты могли иметь свои собственные группы.

Владелец системы имел специальную учётную запись — root. Она предоставляет полный контроль над системой. В целях безопасности и стабильности, UNIX-подобные системы ограничивают определённые операции, и только root имеет право на их выполнение. Только root может выполнять конфигурирование сети, монтировать новые файловые системы и перезапускать программы присоединённые к привилегированным сетевым портам.
Это имело смысл, когда у вас было два сервера для всего кампуса — реконфигурирование сети или подключение нового диска является серьёзной задачей в этой среде. Работа по управлению системами многомиллионной стоимостью должна была оставаться в надёжных руках.

В 21-веке, UNIX-подобные системы стали дёшевы и многочисленны. Группы людей могут разделять административные задачи управления системой или один человек может иметь полный контроль над ней или может сущетсвовать нечто среднее. Ситуация может полностью изменять свои требования к безопасности относительно прошлого века.

Крупные организации часто делят обязанности по администрированию системы между несколькими квалифицированными лицами. Один человек может нести ответственность работу самой системы, в то время как другой может заниматься ослуживанием приложения работающего на сервере. Сервер поддерживает приложения, приложения существуют на сервере, но людям требуется выполнение задач для которых требуются привилегии корневого уровня. Однако передача привилегий root — это решение из категории «всё или ничего». Здесь нет никакой разницы между «доступом к изменению ядра» и «доступом для запуска привилегированного приложения». Если администратор приложения имеет root-доступ, он может произвести изменения ядра. Вы всегда можете рассчитывать на джентельменские соглашения касаться только своей ответственной части системы, но когда в вашей организации работает команда системных администраторов и команда администраторов баз данных, поддерживающих десятки или сотни серверов, подобные джентельменские соглашения быстро приводят к кровопролитию. Такие организации нуждаются в более тонком разграничении доступа к управлению системой чем может предоставить root.

Модель «всё или ничего» становится ещё более ущербной когда у каждого имеется UNIX-подобная система. Не беря в расчёт множество телефонов и планшетов имеющих дополнительное ПО делающее их более удобными в использовании, многие используют UNIX-подобные системы на настольном ПК или ноутбуке. Каждый раз когда им требуется доступ к USB диску или настройка беспроводной сети, им потребуется привилегированный доступ к системе на уровне root. Использование прав суперпользователя нельзя назвать страшно обременительной процедурой — войдите в свою учётную запись, используйте команду su для переключения пользователя, введите пароль root, выполните необходимые команды которые требуют привилегий и выйдите из учётной записи root. Однако, когда необходимость в получение привилегий возникает постоянно, на мелких рутинных операциях это быстро начинает раздражать…