Продолжение 1: Искусство Sudo
http://iboxjo.ru
В компьютерной индустрии работает множество действительно умных людей, которые смогли расширить классическую модель управления привилегиями UNIX. Одним из способов является использование флагов setuid и setgid. Обычно, программы работают с привилегиями того пользователя который ими управляет, программы с установленными флагами setuid и setgid изменяют действующее значение UID и GID на какое-то другое. Вы можете выполнять программу с флагом setuid работающую с привилегиями root. Например изменение пароля требует редактирование защищённых файлов расположенных в директории /etc/, по этой причине команда passwd - setuid. Однако, злоумышленники очень любят программы с флагами setuid и setgid. Ошибки в таких программах могут в полной мере использоваться для доступа к root. В связи с этим, большинство операционных систем не позволяют использовать флаг setuid на скриптах оболочки, а только на программах.
Кроме этого, существует несколько разновидностей списков контроля доступа (Access control lists - ACL), значительно расширяющих модель пользователь-группа-прочие (user-group-others). Списки ACL позволяют сделать заявление вида "этот человек владеет файлом, но эти группы и пользователи могут его изменять, с некоторыми исключениями, эти группы и пользователи могут его выполнять, в то время как другие могут только читать его данные, за исключением..." и тому подобное. В этой точке системный администратор обретает дополнительную головную боль и подумывает сменить работу. И уж конечно, различные реализации ACL являются частично не совместимыми друг с другом. Очень немногие могут правильно реализовать списки ACL на одной платформе, и не факт что смогут распространить на иную платформу. Однако списки ACL имеют место в системном администрировании, и если они действительно вам необходимы - они бесценны. Печальный факт в том, что большинство из нас не нуждаются в них.
К сожалению, списки контроля доступа хороши на столько на сколько хорошими они получаются. За исключением sudo.
Что такое Sudo?
Sudo это программа управляющая доступом к выполнению команд иот имени root или другого пользователя. Владелец системы создаёт список привилегированных команд, которые может выполнять каждый пользователь. Когда пользователю требуется выполнить команду которой необходимы привилегии на уровне root, он просит sudo выполнить эту команду для него. sudo проверяет свои права по заранее установленному списку. Если пользователь имеет разрешение на выполнение этой команды, он может её выполнить. Если такового разрешения нет, sudo сообщает пользователю об этом. Запуск sudo не требует пароля root, а только собственный пароль пользователя (либо иной способ аутентификации).
Системный администратор может делегировать привилегии уровня root для конкретных пользователей выполняющих очень специфические задачи не выдавая при этом пароль root. Он может указать sudo требовать проверки подлинности для некоторых пользователей или команд и не требовать этого для других. Он может разрешить пользователям доступ на некоторых машинах и запретить доступ на других основываясь на едином, общем файле конфигурации.
Некоторые приложения, в частности, большие базы данных предприятия, работают под управлением конкретной выделенной учётной записи. Пользователям необходимо переключиться на эту учётную запись для управления программным обеспечением. Вы можете настроить sudo позволяя пользователям выполнять определённые команды от имени этой учётной записи. Возможно, что младшим администраторам баз данных требуется только выполнять резервное копирование, в то время как главный администратор базы данных должен иметь полный доступ к оболочке базы данных. Sudo позволяет решить эту проблему.
Наконец, sudo регистрирует все выполняемые действия. Можно даже воспроизвести содержимое индивидуальной sudo-сессии, чтобы разобраться кто и что нарушил.
Что же не так с sudo?
Если sudo такой прекрасный инструмент, почему он не используется повсеместно?
Sudo добавляет ещё один уровень администрирования системы. Добавления этого уровня требует затраты времени, энергии и внимания. Это требует внимательного изучения ещё одной опасной программы, в то время когда у вас и так полно работы. Если вы отвечаете ра работу системы предприятия с несколькими группами администраторов, вложения в sudo снижает нагрузку. Но вам требуется научиться использовать его правильно.
Некоторые коммерческие UNIX не включают sudo, поскольку уже имеют собственную систему управления привилегиями. Системы на базе OpenSolaris имеют pfexec и контроль доступа на основе ролей (role-based access control - RBAC). HP имеет pbrun. Если бы вы были коммерческим вендором UNIX, потратившим уйму средств на развитие системы контроля привилегий базирующейся на ACL, вы бы поощряли включение и использование вместо неё более простого инструментария? Я бы наверное мог, но я не продаю UNIX :).
Многие UNIX-подобные системы с открытым кодом включают sudo в базовую систему. Некоторые из них, такие как Ubuntu и OS X, полностью отключают учётную запись root и разрешают привилегированный доступ только посредством sudo. Это крен в правильном направление, но большинство пользователей не умеют правильно использовать sudo.
Как можно неправильно использовать sudo? Во первых sudo не заменяет su. Sudo это не способ полностью избежать требования аутентификации для получения привилегированного доступа. Sudo не является инструментом который сделает за вас что-то. Правильная настройка sudo упрощает управление системой. Неправильная настройка sudo позволяет злоумышленникам и не авторизованным пользователям быстрее и проще испортить и уничтожить вашу систему.
"Правильное использование sudo" не означает использование сложных и обширных политик. Я видел системы в которых администраторы писали сложные политики sudo, а пользователи вальсировали мимо их ограничений. Иногда пользователи даже не подозревали о наличии этих ограничений. Sudo имеет свои пределы. После того, как вы поймёте эти ограничения, вы сможете принимать реалистичные решения о том как правильно развернуть sudo.
Проблемы которые я часто наблюдаю в связи с sudo не имеют ничего общего с самим программным обеспечением. Правильное развёртывание sudo в сложной организации требует сплочённой команды системного администрирования, в которой каждый знает кем является и за что отвечает. Sudo связывает обязанности и ответственность в своём файле конфигурации. Файл конфигурации является достаточно гибким и пользователи не могут превышать привилегий указанных в нём.
Каковы границы ваших обязанностей? какими разрешениями вы должны обладать чтобы выполнять свою работу и какие задачи должен решать кто-то ещё? Задумываться об этих вещах может быть неудобно и это может привести к конфликтам внутри организации. Однако после чёткого аргументирования конфликтность должна снизиться. Не должно возникать склоки о том, кто, что, когда и как сделал. Все знают, что команда администрирования базы данных не должна форматировать файловые системы, web-администраторы не должны перезапускать базу данных - журналы sudo однозначно показывают кто выполнял привилегированные операции. Наличие аудита повышает стабильность системы. Когда пользователи знают, что система регистрирует привилегированные действия и что им придётся нести ответственность за возникшие проблемы - проблемы начинают возникать реже. Странно да?
(продолжение будет :)
Примечание переводчика: Я всегда говорил и буду говорить, что только системное администрирование не решает проблемы. Изначально, администрировать необходимо физический мир и вырабатывать чёткую систему мер и наказаний. Только затем отражать её на цифровую реальность.