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

Представляйте себе эффективный идентификатор пользователя как исполнителя, а реальный идентификатор — как владельца. Реальный идентификатор пользователя определяет того пользователя, который может взаимодействовать с запущенным процессом, и, что наиболее важно, пользователя, который может прерывать процесс и отправлять ему сигналы. Если, например, пользователь А запускает новый процесс от имени пользователя B (на основе разрешений setuid), то пользователь A по-прежнему владеет этим процессом и может его прервать.

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

$ ps -eo pid,euser,ruser,comm

Чтобы создать исключение только для того, чтобы увидеть различные значения в столбцах, попробуйте поэкспериментировать: создайте setuid-копию команды sleep, запустите эту копию на несколько секунд, а затем выполните приведенную выше команду ps в другом окне, прежде чем копия прекратит работу.

Чтобы усугубить путаницу, в дополнение к реальному и эффективному идентификаторам пользователя есть также сохраненный идентификатор пользователя (для которого обычно не используют сокращение). Во время выполнения процесс может переключить свой эффективный идентификатор пользователя на реальный или сохраненный. Чтобы вещи стали еще более сложными, в системе Linux присутствует идентификатор пользователя файловой системы (fsuid), который определяет пользователя, имеющего доступ к файловой системе. Однако этот идентификатор используется редко.

Типичное поведение команды setuid. Идея, заложенная в реальный идентификатор пользователя, может противоречить вашему предшествующему опыту. Почему вам не приходится часто иметь дело с другими идентификаторами пользователя? Например, если после запуска процесса с помощью команды sudo вам необходимо его остановить, вы также используете команду sudo; обычный пользователь не может остановить процесс. Не должен ли в таком случае обычный пользователь обладать реальным идентификатором пользователя, чтобы получить правильные права доступа?

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

примечание

Если вам интересны подробности и правила, относящиеся к переключению идентификаторов пользователя, прочитайте страницу руководства setuid(2), а также загляните на страницы, перечисленные в секции SEE ALSO («см. также»). Для различных ситуаций существует множество разных системных вызовов.

Некоторым командам не нравится корневой реальный идентификатор пользователя. Чтобы запретить команде sudo изменение реального идентификатора пользователя, добавьте следующую строку в файл /etc/sudoers (и остерегайтесь побочных эффектов на другие команды, которые вы желаете запускать с корневыми правами!):

Defaults      stay_setuid

Привлечение функций безопасности. Поскольку ядро Linux обрабатывает все переключения между пользователями (и как результат права доступа к файлам) с помощью команд setuid и последующих системных вызовов, системные программисты и администраторы должны быть исключительно внимательны по отношению:

• к командам, у которых есть права доступа к setuid;

• к тому, что эти команды выполняют.

Если вы создадите копию оболочки bash, которая будет наделена корневыми правами setuid, любой локальный пользователь сможет получить полное управление системой. Это действительно просто. Более того, даже специальная команда, которой предоставлены корневые права setuid, способна создать риск, если в ней есть ошибки. Использование слабых мест программы, работающей с корневыми правами, является основным методом вторжения в систему, и количество попыток такого использования очень велико.

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

7.9. Идентификация и аутентификация пользователей

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

Когда дело доходит до идентификации пользователя, ядро системы Linux знает только численный идентификатор пользователя для процесса и владения файлами. Ядро знает о правилах авторизации, относящихся к тому, как запускать исполня­емые файлы setuid и как совершать системные вызовы из семейства setuid(), чтобы выполнить переход от одного пользователя к другому. Однако ядро ничего не знает об аутентификации: именах пользователей, паролях и т. п. Практически все, что относится к аутентификации, происходит в пространстве пользователя.

В подразделе 7.3.1 мы рассматривали соответствие между идентификаторами пользователей и паролями. Сейчас я объясню, как пользовательские процессы получают доступ к этому соответствию. Начнем с предельно упрощенного случая, при котором пользовательский процесс желает узнать свое имя пользователя (имя, которое соответствует эффективному идентификатору пользователя). В традиционной системе Unix процесс мог бы выполнить для этого что-либо подобное.

1. Процесс спрашивает у ядра свой эффективный идентификатор пользователя с помощью системного вызова geteuid().

2. Процесс открывает файл /etc/passwd и начинает его чтение с самого начала.

3. Процесс читает строки в файле /etc/passwd. Если читать больше нечего, попытка поиска имени пользователя завершается неудачей.

4. Процесс выполняет анализ строки по полям (вытаскивая все, что находится между двоеточиями). Третье поле является идентификатором пользователя в текущей строке.

5. Процесс сравнивает идентификатор, полученный на четвертом шаге, с тем, который был получен на первом шаге. Если они совпадают, первое поле, найденное на четвертом шаге, является искомым именем пользователя; процесс может прекратить поиски и воспользоваться данным именем.

6. Процесс переходит к следующей строке файла /etc/passwd и возвращается к третьему шагу.

Процедура довольно длинная, а в реальности она обычно гораздо более сложная.

Применение библиотек для получения информации о пользователе. Если каждому разработчику, которому потребовалось узнать текущее имя пользователя, приходилось бы создавать весь код, который вы только что видели, система стала бы ужасающе несвязной, раздутой и совершенно неуправляемой. К счастью, мы можем использовать стандартные библиотеки, чтобы выполнять повторя­ющиеся задачи. Чтобы узнать имя пользователя, необходимо лишь вызвать функцию вроде getpwuid() из стандартной библиотеки после получения ответа от команды geteuid(). Обратитесь к страницам руководства по этим вызовам, чтобы узнать о том, как они работают.