root, группы и права доступа


Система безопасности UNIX считается в некотором смысле грубой, поскольку один суперпользователь, root, может делать все, что угодно. Другие пользователи — безропотные пеоны, покорно носящие кандалы, в которые их заковал root. Проблема в том, что у суперпользователя не такой уж широкий выбор кандалов, и он не может подбирать их индивидуально для каждого пользователя. Это в общем так, но приличный администратор может комбинированием групп и прав доступа решать почти все вопросы безопасности.

Пароль root

Для некоторых действий нужен полный контроль над системой, в том числе возможность манипулировать ключевыми системными файлами, такими как файлы ядра, драйверов устройств и файлы системы аутентификации. Учетная запись root разработана как раз для выполнения таких действий.

Для использования пароля root надо либо войти в систему с консоли как root, либо, если вы — член группы wheel, выполнить команду смены пользователя (switch user) su(1). (Группы будут обсуждаться ниже, в этом же разделе.) Я рекомендую su; информация о пользователях, выполнивших su, заносится в протокол. Кроме того, su можно применять на удаленной системе. Выполнить эту команду очень просто:

# su
Password:
#

Проверьте текущее имя пользователя с помощью команды id(1):

# id
uid=0(root) gid=0(wheel) groups=0(wheel), 5(operator)
#

Теперь вы владеете системой — да, она в вашей власти. Будьте внимательны при каждом нажатии клавиши; небрежность может превратить жесткий диск в неформатированный кусок металла — такой же чистый, каким он был изначально. Если уж использовать пароль root, то ответственно, ибо каждый, кто знает пароль root, может причинить непоправимый вред системе.

Не забывайте, только пользователи из группы wheel могут воспользоваться паролем root, чтобы получить привилегии этого пользователя с помощью команды su(1). И любой может воспользоваться паролем root с консоли, вот почему так важно обеспечить физическую защиту системы. Если пароль root попадет в руки обычного пользователя, не имеющего физического доступа к консоли, он может вводить команду su, пока не надоест, — команда все равно работать не будет.

Естественно, возникает вопрос: «А кому нужен доступ с правами root?» Для большинства действий по конфигурированию, обсуждаемых в этой книге, необходим пароль root. Но как только система настроена должным образом, доступ к паролю root можно значительно сократить и даже приостановить. Для решения остальных задач, которые требуют привилегий пользователя root, я рекомендую использовать sudo (/usr/ports/security/sudo). Один из самых простых способов уменьшить необходимость передачи прав root состоит в правильном использовании групп.

Группы пользователей

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

Любой пользователь может определить свою принадлежность к группам с помощью команды id(1). В предыдущем примере видно, что пользователь root входит в состав групп wheel и operator. Однако root — это специальный пользователь, он может делать все, что пожелает. Ниже приводится моя учетная запись, более похожая на запись обычного среднего пользователя:

# id
uid=1001(mwlucas) gid=1001(mwlucas) groups=1001(mwlucas), O(wheel), 68(dialer), 1006(cvsup)

Мой идентификатор пользователя (UID) равен 1001, а имя учетной записи — mwlucas. Идентификатор моей основной группы (GID) равен 1001, а моя основная группа также называется mwlucas. Это типичный пример первого созданного пользователя, но и последующие пользователи будут отличаться друг от друга только числовыми идентификаторами пользователя и группы. Гораздо интереснее узнать, для чего я назначил остальные группы: помимо своей основной группы я вхожу также в группы wheel, dialer и cvsup. Члены группы wheel могут использовать пароль root, чтобы получить привилегии root, члены группы dialer могут пользоваться программой tip(1) без необходимости получать права суперпользователя, а члены группы cvsup могут пользоваться репозиторием CVS в локальной системе. В моей системе каждая из этих групп имеет особые привилегии и как член этих групп, я наследую эти привилегии.

Информация о группах находится в файле /etc/group.

/etc/group

Файл /etc/group содержит информацию о всех группах, за исключением основных групп пользователей (которые определяются вместе с учетными записями в файле /etc/master.passwd). Каждая строка в файле /etc/group содержит четыре поля, разделенных двоеточиями: имя группы, пароль группы, числовой идентификатор группы и список членов группы. Ниже приводится пример записи:

wheel:*:0:root,mwlucas,gedonner

Имя группы — это понятное для человека название группы. Данная группа называется wheel. Имена групп могут быть совершенно произвольными. При желании группу можно назвать, например, minions (любимчики). Впрочем, имена для групп лучше выбирать, исходя из их предназначения. Вы можете запомнить, что члены группы minions могут редактировать веб-страницы, но догадаются ли об этом ваши коллеги?

Второе поле содержит пароль группы. Пароли групп способствовали укоренению плохих, с точки зрения безопасности, привычек, поэтому в большинстве современных систем UNIX они не поддерживаются. Однако прежние программы написаны в расчете на присутствие этого поля, поэтому вместо того, чтобы оставить это поле пустым или удалить его, используйте звездочку (*) в качестве «заполнителя».

Третье поле содержит уникальный числовой идентификатор группы (GID). Для идентификации групп в большинстве внутренних программ FreeBSD применяются именно GID, а не имена. Группа wheel имеет числовой идентификатор, равный 0, а максимальное значение GID равно 65 535.

Последнее поле — список всех пользователей, входящих в эту группу. Имена пользователей разделяются запятыми. В этом примере в состав группы wheel входят пользователи root, mwlucas и gedonner.

Изменение состава групп

Для добавления пользователя в группу добавьте имя его учетной записи в конец строки с определением требуемой группы. Например, в группу wheel входят пользователи, которые обладают правом пользоваться паролем root. В следующем примере я добавил пользователя rwatson в группу wheel:

wheel:*:0:root,mwlucas,gedonner,rwatson

Конечно, мои шансы убедить пользователя rwatson (президент фонда FreeBSD Foundation) взять на себя обязанности по администрированию любой из моих систем находятся в диапазоне от ничтожно малых до вообще никаких, но попробовать стоит.

Создание групп

Чтобы создать новую группу, достаточно иметь имя группы и числовой идентификатор группы. Технически вам даже не нужно иметь членов группы — некоторые программы работают с правами группы, и сама система FreeBSD использует привилегии группы для управления такими программами точно так же, как это делают пользователи.

Традиционно в качестве значения GID выбирается первое свободное число, превышающее максимальное значение GID в списке имеющихся групп. Вообще говоря, числовые идентификаторы групп со значениями ниже 1000 зарезервированы для нужд операционной системы. Программы, которым требуется отдельное значение GID, обычно используют одно из чисел в этом диапазоне. Значения идентификаторов групп для учетных записей пользователей начинаются с числа 1001. Идентификаторы некоторых специализированных групп начинают получать значения от 65 535 и ниже.

Использование групп во избежание передачи пароля root

Кроме проблемы обеспечения безопасности, передача пароля суперпользователя может вызвать разногласия в любой организации. Многие системные администраторы не торопятся передавать пароль root тем, кто отвечает за сопровождение отдельных частей системы, но, не предлагая альтернативы, они тем самым препятствуют тому, чтобы люди выполняли свои обязанности. Другие системные администраторы бесконтрольно раздают пароль root почти всем желающим, а потом жалуются, что система стала нестабильной. В конечном итоге оба варианта малопригодны. Будучи пользователем, я совсем не претендую на получение пароля root, но я настаиваю, чтобы системный администратор создал группу, которая обладала бы достаточными привилегиями для решения поставленных задач. Хотя это довольно удобно — обладать привилегиями суперпользователя, тем не менее не нести ответственность за нарушения в работе системы еще удобнее.

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

Системные учетные записи

В операционной системе FreeBSD некоторые учетные записи резервируются для встроенных программ. Например, сервер имен работает под учетной записью с именем bind и в группе bind. He нужно входить в систему под учетной записью программного пользователя, чтобы выполнять такого рода работу! Если злоумышленник взломает сервер имен, он получит доступ к системе всего лишь с привилегиями пользователя bind.

Более того, не допускайте, чтобы системные учетные записи и системные группы выступали владельцами файлов, созданных специально для таких программ. Создайте отдельного пользователя и группу, которые будут владеть файлами программ. В этом случае наш гипотетический взломщик сервера имен не сможет даже отредактировать файлы, которые используются сервером DNS, благодаря чему сводятся к минимуму возможные разрушения. Если программа регулярно обновляет файлы (например, файлы базы данных), то необходимо дать программе право на запись, но при этом вполне возможно, что человеку никогда не потребуется редактировать такие файлы. Точно так же нет никаких причин, по которым сервер базы данных должен иметь право на запись в свои собственные конфигурационные файлы.

Создание административных групп

Самый простой способ создать группу, которая будет владеть файлами, — это создать нового пользователя с помощью adduser(8) и затем использовать основную группу этого пользователя для назначения выбранным файлам привилегий этой группы. Так как у нас уже есть пользователь bind, мы создадим административного пользователя dns. Имя учетной записи не играет большой роли, но лучше выбирать такие имена, которые лучше запоминаются.

В качестве командной оболочки для этого пользователя укажите nologin, что соответствует интерпретатору /sbin/nologin. Это предотвратит попытки войти в систему под этой учетной записью.

При желании для пользователей этой категории можно выбирать определенные значения UID и GID. Я выбираю такие значения UID и GID, которые напоминали бы числовые идентификаторы учетных записей, используемых соответствующими системными службами. Например, UID и GID пользователя bind имеют значение 53. Для простоты запоминания я мог бы присвоить UID пользователя dns значение 10053. В других случаях я присваиваю административным группам числовые идентификаторы, начиная с 65535 и далее вниз.

Не добавляйте таких административных пользователей в другие группы. И уж ни при каких обстоятельствах не добавляйте их в привилегированные группы, такие как wheel! Каждый пользователь должен иметь домашний каталог. Для административного пользователя вполне подойдет каталог с именем /nonexistent. В конце концов, файлы этого пользователя находятся в другом месте. И, наконец, в программе adduser(8) нужно сделать учетную запись неактивной. Хотя выбранный командный интерпретатор предотвратит возможность входа, но дополнительная защита не помешает.

Теперь, после создания административного пользователя и группы можно назначить этого пользователя владельцем требуемых файлов. Каждому файлу поставлены в соответствие пользователь и группа, владеющие им. Увидеть права доступа к файлу и владельца можно с помощью команды ls -l. (Если вы не помните, как используются права доступа в UNIX, прочитайте страницы руководства ls(1) и chmod(1).) Многие системные администраторы уделяют самое пристальное внимание правам доступа для владельца файла, чуть меньше — для всех остальных и весьма поверхностное — правам доступа для группы.

# ls -l
total 3166
-rw-r----- 1 mwlucas mwlucas 79552 Nov 11 17:58 rndc.key
-rw-rw-r-- 1 mwlucas mwlucas 3131606 Nov 11 17:58 absolutefreebsd.com.db

Для этого примера были созданы два файла. Первый файл, rdnc.key, доступен для чтения и записи пользователю mwlucas, для чтения — всем, кто входит в состав группы mwlucas, все остальные не имеют никаких прав доступа к этому файлу. Файл absolutefreebsd.com.db доступен для чтения и записи пользователю mwlucas и всем, кто входит в состав группы mwlucas, все остальные имеют только право на чтение. Если вы входите в состав группы mwlucas, вы сможете редактировать файл absolutefreebsd.com.db и вам для этого совершенно не нужны привилегии пользователя root.

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

# chown dns:dns rndc.key
# chown dns:dns absolutefreebsd.com.db
# ls -l
total 3166
-rw-r----- 1 dns dns 79552 Nov 11 17:58 rndc.key
-rw-rw-r-- 1 dns dns 3131606 Nov 11 17:58 absolutefreebsd.con.db

Теперь этими файлами владеют пользователь dns и группа dns. Любой, кто входит в состав группы dns, сможет редактировать файл absolutefreebsd.com.db, не используя пароль root. Наконец, этот файл доступен для чтения серверу имен, работающему с привилегиями пользователя bind. Теперь стоит добавить администраторов DNS в группу dns, в файле /etc/group, и они тут же смогут приступить к выполнению своих обязанностей.

Администраторы могут думать, что для перезапуска сервера имен им необходимо знать пароль root. Однако это легко решается с помощью rndc(8). Другие задачи могут решаться с помощью заданий в сгоп или с помощью программы sudo(8).

Интересные группы, создаваемые по умолчанию

В состав FreeBSD входит несколько групп, создаваемых по умолчанию. Большая часть из них используется системой и не требует к себе внимания системного администратора — вам достаточно знать об их существовании. Тем не менее здесь представлены самые полезные, интересные и необычные группы по умолчанию (табл. 7.2). Добавление собственных новых групп упрощает администрирование, однако примите к сведению, что в каждой системе FreeBSD есть группы, приведенные в этом списке.

Таблица 7.2. Интересные группы FreeBSD

Имя группы Назначение
audit Группа, обладающая правом доступа к информации audit(8)
authpf Группа аутентификации фильтра пакетов PF
bin Группа, владеющая основными двоичными файлами и программами в системе
bind Группа для встроенного сервера DNS (глава 14)
daemon Группа, используемая различными системными сервисами, например системой печати
_dhcp Группа для выполнения операций с клиентами DHCP
dialer Группа пользователей, имеющих доступ к последовательным портам; удобна для работы с модемами и программой tip(1)
games Группа для игровых программ и файлов
guest Группа для гостей системы (практически никогда не используется)
kmem Группа для программ, обращающихся к памяти ядра, например fstat(1), netstat(1) и т. д.
mail Группа для системы электронной почты (глава 16)
mailnull Группа по умолчанию для Sendmail (глава 16)
man Группа, владеющая страницами руководства
network Группа, владеющая программами для работы с сетью, такими как ррр(8)
news Группа для программ, предоставляющих доступ к Usenet (если установлено)
nobody Основная группа для пользователя nobody, не имеющего никаких привилегий
nogroup Группа без привилегий
operator Группа, имеющая доступ к приводам; обычно используется для выполнения резервного копирования
_pflogd Группа для ведения протокола PF
proxy Группа для FTP-прокси в фильтре пакетов PF
smmsp Группа для Sendmail Submission User (глава 16)
sshd Владелец сервера SSH (глава 15)
staff Администраторы системы
sys Системная группа для прочих нужд
tty Группа для программ, имеющих право вывода на терминалы, таких как wall(1)
uucp Группа для программ, использующих протокол UNIX-to-UNIX Copy Protocol
wheel Пользователи, которые имеют право использовать пароль root
www Группа для программ веб-сервера (но не для веб-файлов)

Комментарии запрещены.