Linux API. Исчерпывающее руководство

Теперь мы станем употреблять слово «привилегированный» в двух разных смыслах. Первый мы определили ранее: это процесс с действующим идентификатором пользователя со значением 0, у которого имеются все полномочия, присущие пользователю по имени root. Но, когда речь заходит о set-user-ID-программе, владельцем которой является другой, не root-пользователь, то мы называем процесс наделенным полномочиями, соответствующими идентификатору пользователя set-user-ID-программы. Какой именно смысл вкладывается в понятие «привилегированный», в каждом случае будет понятно из контекста.

По причинам, объясняемым в разделе 38.3, биты полномочий set-user-ID и set-group-ID не оказывают никакого влияния на используемые в Linux сценарии оболочки.

В качестве примеров часто используемых в Linux set-user-ID-программ можно привести passwd(1), изменяющую пользовательский пароль, mount(8) и umount(8), которые занимаются монтированием и размонтированием файловых систем, и su(1), которая позволяет пользователю запускать оболочку под различными UID. В качестве примера программы с полномочиями setgid можно привести wall(1), которая записывает сообщение на все терминалы, владельцами которых является группа tty (обычно она является владельцем каждого терминала).

В разделе 8.5 уже отмечалось, что программа из листинга 8.2 должна быть запущена под учетной записью root, чтобы получить доступ к файлу /etc/shadow. Эту программу можно сделать запускаемой любым пользователем, назначив ее set-user-ID-root-программой:

$ su

Password:

# chown root check_password Закрепление владения этой программой за root

# chmod u+s check_password С установленным битом set-user-ID

# ls — l check_password

— rwsr-xr-x 1 root users 18150 Oct 28 10:49 check_password

# exit

$ whoami Это непривилегированный пользователь

mtk

$ ./check_password Но теперь мы можем получить доступ к файлу

Username: avr теневых паролей, используя эту программу

Password:

Successfully authenticated: UID=1001

Технология set-user-ID/set-group-ID является полезным и эффективным средством, но при недостаточно тщательно спроектированных приложениях может создать бреши в системе безопасности. Практические наработки, которых следует придерживаться при написании программ с полномочиями setuid и setgid, перечисляются в главе 38.

9.4. Сохраненный set-user-ID и сохраненный set-group-ID

Сохраненный установленный идентификатор пользователя (set-user-ID) и сохраненный установленный идентификатор группы (set-group-ID) предназначены для применения с программами с полномочиями setuid и setgid. При выполнении программы наряду со многими другими происходят и следующие действия.

1. Если у исполняемого файла установлен бит полномочий set-user-ID (set-group-ID), то действующий пользовательский (групповой) ID процесса становится таким же, что и у владельца исполняемого файла. Если у исполняемого файла не установлен бит полномочий set-user-ID (set-group-ID), то действующий пользовательский (групповой) ID процесса не изменяется.

2. Значения для сохраненного set-user-ID и сохраненного set-group-ID копируются из соответствующих действующих идентификаторов. Это копирование осуществляется независимо от того, был ли у выполняемого на данный момент файла установлен бит set-user-ID или бит set-group-ID.

Рассмотрим пример того, что происходит в ходе вышеизложенных действий. Предположим, что процесс, чьи пользовательские идентификаторы — реальный, действительный и сохраненный set-user-ID — равны 1000, выполняет set-user-ID-программу, владельцем которой является root (UID равен 0). После выполнения пользовательские идентификаторы процесса будут изменены следующим образом:

real=1000 effective=0 saved=0 (реальный=1000 действующий=0 сохраненный=0)

Различные системные вызовы позволяют set-user-ID-программе переключать ее действующий пользовательский идентификатор между значениями реального UID и сохраненного set-user-ID. Аналогичные системные вызовы позволяют программе с полномочиями setgid изменять ее действующий GID. Таким образом, программа может временно сбросить и восстановить любые полномочия, связанные с пользовательским (групповым) идентификатором исполняемого файла. (Иными словами, она может перемещаться между состояниями потенциальной привилегированности и фактической работы с полномочиями.) При более подробном рассмотрении вопроса в разделе 38.2 выяснится, что требования безопасного программирования гласят: программа должна работать под непривилегированным (реальным) ID до тех пор, пока ей на самом деле не понадобятся права привилегированного (то есть сохраненного установленного) ID.