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

4. Если нулевому пользовательскому идентификатору файловой системы присваивается ненулевое значение, из действующего набора удаляются следующие возможности, связанные с файлами: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (начиная с Linux 2.6.30), CAP_MAC_OVERRIDE и CAP_MKNOD (начиная Linux 2.6.30). И наоборот — если ненулевое значение пользовательского идентификатора файловой системы меняется на 0, все эти возможности, если они входят в разрешенный набор, становятся действующими. Это делается для того, чтобы сохранить традиционную семантику работы с пользовательскими идентификаторами файловой системы, характерную для Linux.

39.7. Программное изменение возможностей процесса

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

1. Если действующий набор процесса не содержит возможности CAP_SETPCAP, новый наследуемый набор должен быть подмножеством сочетания разрешенного и существующего наследуемого наборов.

2. Новый наследуемый набор должен быть подмножеством сочетания ограничивающего и существующего наследуемого наборов.

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

4. Новый действующий набор может содержать только те возможности, которые находятся в новом разрешенном наборе.

Программный интерфейс libcap

Вплоть до этого момента не приводился прототип системного вызова capset() или его собрата capget(), который возвращает возможности процесса. Дело в том, что их использование является нежелательным. Вместо них следует применять функции из библиотеки libcap. Эти функции предоставляют интерфейс, который соответствует бывшему проекту стандарта POSIX 1003.1e и имеет несколько расширений, характерных для Linux:

Для экономии места программный интерфейс libcap не будет описан во всех подробностях. Нужно только отметить, что программы, которые его применяют, обычно выполняют следующие действия.

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

2. Используют функцию cap_set_flag() для изменения структуры, полученной на предыдущем шаге, чтобы включить (CAP_SET) или выключить (CAP_CLEAR) возможности в разрешенном, действующем и наследуемом наборах.

3. Используют функцию cap_set_proc(), чтобы вернуть ядру вышеупомянутую структуру и изменить тем самым возможности процесса.

4. Используют функцию cap_free(), чтобы удалить структуру, которая была создана интерфейсом libcap в самом начале.

На момент написания этой книги создавалась новая, улучшенная библиотека для работы с возможностями под названием libcap-ng. Подробности можно найти на странице freshmeat.net/projects/libcap-ng.

Пример программы

В листинге 8.2 была представлена программа, которая принимает имя пользователя и пароль и затем выполняет аутентификацию на основе стандартной базы данных паролей. Мы отмечали, что файл с паролями (/etc/shadow) защищен от чтения со стороны обычных пользователей (которые не входят в группу shadow), поэтому для доступа к нему требуются повышенные привилегии. Традиционный механизм получения привилегий подразумевает выполнение этой программы от имени администратора или установки ей нулевого пользовательского идентификатора. Здесь мы рассмотрим измененную версию этого примера, в котором задействуются возможности и программный интерфейс libcap.

Чтобы прочитать файл /etc/shadow от имени обычного пользователя, нам необходимо обойти стандартные проверки прав доступа. Если просмотреть содержимое табл. 39.1, можно увидеть, что подходящей возможностью в нашем случае является CAP_DAC_READ_SEARCH. Модифицированная версия нашей программы для аутентификации представлена в листинге 39.1. Прямо перед доступом к файлу с паролями она применяет интерфейс libcap, чтобы включить возможность CAP_DAC_READ_SEARCH в свой действующий набор; выполнив чтение, она немедленно сбрасывает эту возможность. Чтобы к этой программе смог обратиться обычный пользователь, мы должны установить эту возможность в разрешенном наборе ее исполняемого файла, как показано в следующем листинге сессии:

$ sudo setcap "cap_dac_read_search=p" check_password_caps

root's password:

$ getcap check_password_caps