| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Как обойтись без прав root. Часть 1 Статья является переводом текста Michael Lucas доступного . Суперпользовательский пароль может стать причиной конфликтов в любой организации. Большинство системных администраторов категорически против передачи пароля, даже если он требуется людям, отвечающим за обслуживание некоторых частей системы. Если такой системный администратор не знает как разрешить это противоречие, он может помешать людям выполнять их работу. Немало администраторов: раздают суперпользовательский пароль всем желающим, а затем плачутся окружающим на нестабильную работу системы. Система UNIX имеет широкие возможности для устранения необходимости отдавать административный пароль в чужие руки. В этом цикле статей мы всесторонне рассмотрим вопрос минимизации использования суперпользовательского аккаунта для выполнения целого ряда задач администрирования. В данной статье мы остановимся на методике объединения пользователей в административные группы. Наиболее типичная ситуация выглядит так: младший администратор отвечает за администрирование определенной части системы. Под моим руководством состоит несколько администраторов DNS. Им не приходится устанавливать программное обеспечение, перекомпилировать ядро и вообще решать низкоуровневые административные задачи. Их задача – отвечать на запросы электронной почты, вносить изменения в файлы описания зон и после этого перезапускать named. Обычно, младшему администратору, недавно принятому на работу, кажется что для этого ему необходимы полномочия суперпользователя. Однако правильное использование механизма групп вкупе с несложным планированием позволят вам вообще отказаться от выдачи кому-либо суперпользовательского пароля. В этой статье мы воспользуемся групповой системой безопасности для администрирования файлов DNS зон. Подобная техника может применяться для управления многими другими составными частями системы. UNIX подразделяет пользователей на группы, каждая группа состоит из людей, которые выполняют определенные административные функции. У вас может быть создана группа web, членами которой будут пользователи, имеющие право редактировать содержимое веб-страничек, или группа dns, в которую включены люди, администрирующие ваш DNS-сервер. В зависимости от используемой вами системы, она может как иметь, так и не иметь по умолчанию группы с подобными именами. Например, операционные системы NetBSD и OpenBSD создают при установке пользователя и группу с именем named, а FreeBSD называет их bind, во всех случаях они предназначены для использования сервером имен. Предопределенные группы и пользователи широко используются разнообразными системными программами. Например, веб-сервер обычно выполняется с правами пользователя www. Для пользователей, которым нужен доступ к используемым этими программами файлам, нам необходимо создать отдельную группу. Однако у нас нет необходимости создавать пользователя с именем, совпадающим с названием этой группы. Информация о группах содержится в файле /etc/group. Каждая строка в этом файле состоит из четырех колонок, разделенных двоеточием. В первой колонке содержится название группы. Название может быть любым, если вам хочется, назовите группу администраторов DNS-сервера «losers» (неудачники). Однако в целом разумно давать группе имя, соответствующее ее предполагаемому использованию, так если сегодня вы решите объединить администраторов почтового сервера в группу «xyzzy», то вспомните ли вы, для чего нужна эта группа, скажем, через шесть месяцев? Поэтому всегда выбирайте название группы имеющее какой-то смысл. Второе поле содержит зашифрованный пароль группы. Групповые пароли плохо защищены и их использование является небезопасным, поэтому большинство современных UNIX систем их вообще не поддерживают. Однако существует немало UNIX'ов, в которых они до сих пор применяются, поэтому мы о них и упоминаем. Вместо того, что бы оставлять это поле пустым, для его заполнения, мы воспользуемся символом «звездочка». В третьем столбце хранится уникальный идентификатор группы (GID). Масса системных программ во FreeBSD пользуется именно идентификаторами, а не именами групп. Файл /etc/group сортируется в порядке возрастания GID. В последнем поле содержится список имен пользователей, которые входят в группу. Для того что бы добавить пользователя в группу, просто добавьте его имя в этот список. Имена в списке отделяются друг от друга запятыми. Для того что бы создать группу, вы должны выбрать число, которое будет ее уникальным идентификатором. Это число не должно использоваться другими пользователями и программами. Для таких групп, как создаваемая нами группа «dns», я обычно выбираю GID на единицу отличающийся от идентификатора родственной системной группы. Например во FreeBSD группа «bind» имеет идентификатор равный 53 (53-й порт используется для работы с сервером имен). Поэтому пусть создаваемая нами группа имеет GID, равный 54. В эту группу я добавлю пользователей «chris», «phil» и «michael», так что наша новая запись в файле /etc/group будет выглядеть следующим образом:
После того как мы отредактировали файл /etc/group, неплохо было бы проверить, не сделали ли мы ошибки. Для этого во FreeBSD включена утилита chkgrp, которая проверяет корректность файла /etc/group. Если ее запуск произошел без вывода на экран каких-либо сообщений, то все в порядке. (Для того что бы не мучиться выбором уникального GID и вообще решить все проблемы разом, во FreeBSD существует утилита pw, которую удобно использовать для создания, удаления и модификации групп. Для создания аналогичной группы напечатайте:
Если вас не интересует номер GID группы (как меня например), то можно отказаться от использования ключа -g:
Уверяю, что если вы даже мельком взглянете на man pw вы не останетесь внакладе. В операционной системе Linux так же имеется набор программ для управления пользователями и группами. Это утилиты useradd, usermod, userdel, groupadd, groupmod, groupdel. Их использование убережет вас от массы неприятностей. – прим. переводчика.) Теперь, когда группа создана, ее можно использовать в качестве «владельца». Каждый файл в системе имеет владельцев – пользователя и группу. Вы можете узнать владельцев файла при помощи команды ls -l. Большинство неопытных администраторов обращают внимание только на владельца файла, забывая о «групповых» правах доступа.
Из этого листинга видно, что к файлу file1 может обратиться только суперпользователь. file2 может читать суперпользователь и все члены группы wheel. Более того, если вы присутствуете в группе wheel, то вам не обязательно становиться суперпользователем, для того что бы отредактировать (т.е. писать) этот файл. Просто откройте его в редакторе, и вперед! Для изменения группы владельцев файла применяется команда chgrp (а так же более общая команда chown, в таком виде: chown :groupname filename – прим. переводчика):
В BSD-системах wheel используется в качестве системной группы. Ее члены имеют право на использование пароля суперпользователя (имеется в виду, что при наличии этого пароля, пользователи группы wheel могут, воспользовавшись командой su повысить свои права до суперпользовательских – прим. переводчика). В большинстве случаев нет никакой необходимости давать доступ на запись для группы wheel, поскольку это резко противоречит принципу «минимальных привилегий». Аналогично, группа bind используется для выполнения программ DNS-сервера. Ему совершенно необязательно иметь возможность записи в файлы зон (разумеется если у вас не используется динамический DNS – прим. переводчика), поскольку иначе, если злоумышленник проникнет в ваш DNS-сервер, он сможет записать что-нибудь на диск. Этого нельзя допускать. Давайте рассмотрим следующую схему прав доступа, используемую для файлов зон на сайте blackhelicopters.org:
Поскольку я главный администратор, я являюсь владельцем этого файла, кроме меня, все члены группы «dns» имеют возможность записи в этот файл. (На вашей системе в качестве владельца вы можете установить другого пользователя.) Таким образом члены группы «dns» имеют права для чтения и записи этого файла без использования пароля суперпользователя. И, наконец, этот файл может быть прочитан DNS-сервером (поскольку для всех пользователей системы установлен атрибут доступа на чтение – прим. переводчика). Однако есть одна вещь, для которой все-таки необходимо знание пароля суперпользователя, он нужен для перезапуска DNS-сервера (так как без перезапуска сервер не узнает о произошедших изменениях в файле зоны – прим. переводчика). Простейшим решением проблемы будет перезапуск сервера по расписанию при помощи демона cron. Однако несмотря на это у администраторов DNS может остаться желание в определенных случаях перезапускать сервер вручную. В следующей статье цикла мы рассмотрим, как это реализовать. |
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|