Предоставление другим пользователям прав суперпользователя

Предоставление другим пользователям прав суперпользователя

Меня нередко просят предоставить обычным пользователям право выполнять привилегированные операции, разрешенные только администратору. Это может быть опасно, и здесь требуется большая осторожность.

В UNIX/Linux есть утилита sudo, позволяющая системному администратору предоставить пользователю возможность выполнить какую-нибудь команду под видом другого пользователя. Это очень строгая утилита, и она требует, чтобы системный администратор четко указал, какой пользователь (пользователи) какую команду (команды) будет выполнять от имени какого пользователя.

Например, вы можете сконфигурировать утилиту так, что конкретный пользователь сможет выполнить некоторую команду от имени root. He сомневайтесь, что sudo позволит только этому человеку выполнять от имени root только эту команду, но важно, чтобы эта утилита проверяла параметры и не запрещала привилегированным пользователям выполнять разрешенные им операции.

? Очень рискованно создавать систему, в которой «обычным» пользователям разрешено выполнять «привилегированные» операции. В истории компьютерной безопасности полно случаев, когда добросовестные программисты случайно создавали в системе безопасности «дыры», позволяющие любому пользователя выполнять любую команду от имени пользователя root или administrator.

Если вы испытываете сомнения, прочитайте книгу по безопасности или поищите ответы в FAQ.

Предположим, что UNIX-команду mount для обращения к CD-ROM можно выполнять только пользователю root. Недопустимо конфигурировать sudo так, чтобы рядовой пользователь мог выполнить команду mount с любыми параметрами от имени root. Так он сможет вызвать сбой в работе системы или нарушить ее безопасность. Гораздо лучше, если вы разрешите пользователю выполнять от имени root некую новую команду (скажем, mountсd). Эта команда убедится, что пользователь указал именно те дисководы, к которым ему разрешено обращаться (с учетом умолчаний), и выполнит необходимые действия. Вероятно, вы предоставите этому пользователю и команду unmountсd.

Автоматизируя операции, выполняемые другими пользователями, я предпочитаю строить три уровня:

• Уровень 1. Программа, выполняющая основную задачу.

• Уровень 2. Программа, которую пользователь запустит при помощи sudo. Она примет входные данные, проверит их, убедится, что он не пытается выполнить подозрительные действия, и вызовет первую программу.

• Уровень 3. Дружественный пользователю интерфейс доступа к предыдущим слоям, например веб-интерфейс или программа с меню.

Приведу пример. В одной фирме, где я работал, имелась процедура публикации новой версии веб-сайта фирмы в Интернете. В процедуре были задействованы три веб-сервера (на самом деле это были виртуальные серверы на двух компьютерах, но эти подробности несущественны).

www-draft.example.com

Здесь разрабатывалась новая версия нашего веб-сайта.

www-qa.example.com

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

www.example.com

Это был собственно сайт, который видела публика.

Веб-дизайнеры просили системных администраторов скопировать новую версию на www-qa.example.com. Отдел контроля качества, одобрив сайт, сообщал системным администраторам, что его можно опубликовать.

Выполнение каждой из этих двух операций было автоматизировано командами:

readyforqa

Копировала эскиз сайта на сайт отдела контроля качества. golive

Копировала сайт отдела контроля качества на сайт в Интернете.

Отделу маркетинга требовался способ внесения экстренных изменений, когда сотрудники отдела контроля качества были вне досягаемости. Мы создали еще одну команду:

emergency-draft-to-live

Она копировала эскиз сайта на сайт в Интернете после того, как несколько раз переспрашивала «Are you sure?» (Вы уверены?).

Эти три сценария образовали Уровень 2, который я упомянул выше. Уровнем 1 был сценарий, который фактически копировал данные с одного сайта на другой, попутно создавая резервную копию и устанавливая запрет на запись в файлы (а также меняя владельцев файлов). Уровень 1 был доступен только из учетной записи root, потому что он менял владельцев файлов и обращался к серверам по защищенным каналам.

Команда sudo была запрограммирована так, как показано в табл. 13.1.

Таблица 13.1. Таблица разрешений на обновление веб-сайта

Мы приложили определенные усилия, чтобы заставить руководство подписаться под этой схемой, т. е. поставить свои реальные подписи для гарантии того, что они понимают схему, с которой согласны на словах. Процесс получения подписей, как правило, шел очень туго. Он длился неделями. Представление информации в виде схемы облегчило руководству принятие решений. Менеджеры могли изучать ее и вносить изменения, сколько захотят. Преобразование окончательного варианта в файл конфигурации sudo было делом техники.

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

Меню работало без всякий привилегий (т. е. не под sudo), но вызывало программы Уровня 2 с помощью sudo, если это требовалось.