Читаем Linux API. Исчерпывающее руководство полностью

На предыдущих страницах были описаны методики временного и постоянного отказа от привилегий. Теперь мы добавим несколько общих замечаний касательно их использования.

• Семантика некоторых системных вызовов, которые изменяют права доступа для процессов, варьируется в зависимости от системы. Кроме того, эта семантика также зависит от того, имел ли вызывающий процесс повышенные привилегии (действующий пользовательский идентификатор равный 0). Подробности ищите в главе 9, особенно в подразделе 9.7.4. Ввиду этих расхождений [Tsafrir et al., 2008] для изменения привилегий процесса рекомендуется использовать нестандартные системные вызовы, так как во многих случаях они имеют более простую и последовательную семантику, чем их стандартные аналоги. В Linux это означает применение вызовов setresuid() и setresgid(), которые изменяют пользовательские и групповые привилегии. И хотя они поддерживаются не во всех системах, их применение, скорее всего, будет менее подвержено ошибкам (в книге [Tsafrir et al., 2008] предлагается библиотека функций, которая выполняет изменение привилегий с помощью наиболее подходящих интерфейсов, доступных на каждой платформе).

• В Linux, даже если действующий пользовательский идентификатор вызывающего процесса равен 0, системные вызовы, изменяющие привилегии, могут демонстрировать неожиданное поведение, если программа явно ограничила свои возможности. Например, в результате отключения возможности CAP_SETUID попытки изменения UID процесса завершаются неудачей (или, что еще хуже, приводят к изменению только некоторых из запрашиваемых идентификаторов).

• Учитывая риски, описанные в двух предыдущих пунктах, крайне рекомендуется (см. [Tsafrir et al., 2008]) не только проверять успешность системного вызова для изменения прав доступа, но и следить за тем, чтобы внесенные изменения действительно вступили в силу. Например, если мы временно отказываемся от идентификатора привилегированного пользователя или заново его получаем, применяя seteuid(), нам следует после этого сделать вызов geteuid(), чтобы узнать, соответствует ли действующий UID нашим ожиданиям. Аналогично после окончательного отказа от привилегий следует проверить, принадлежат ли реальный, действующий и сохраненный идентификаторы непривилегированному пользователю. К сожалению, стандартные вызовы позволяют получить только реальный и действующий UID, но не сохраненный. В Linux и нескольких других реализациях для этого предусмотрены вызовы getresuid() и getresgid(); в остальных системах могут понадобиться нетривиальные методики — например, разбор информации в файлах /proc.

• Некоторые права доступа могут быть изменены только процессом, чей действующий UID равен 0. Следовательно, при изменении нескольких идентификаторов (GID, дополнительного GID и UID) в последнюю очередь следует отказываться от действующего UID привилегированного пользователя. И наоборот — при получении привилегий действующий UID привилегированного пользователя должен быть первым.

38.3. Будьте осторожны при выполнении программы

Следует соблюдать осторожность при запуске внешней программы из своего приложения — либо напрямую, с помощью exec(), либо опосредованно, применяя вызовы system(), popen() или аналогичные.

Полностью отказывайтесь от привилегий перед запуском другой программы

Если приложение, устанавливающее пользовательский или групповой идентификатор, запускает другую программу, оно должно сбросить все свои UID и GID к значению реального идентификатора пользователя (группы), чтобы новая программа не унаследовала повышенные привилегии и не смогла их самостоятельно получить. Один из способов, как этого можно достичь, заключается в сбрасывании всех идентификаторов до выполнения exec(), применяя методики, описанные в разделе 38.2.

Тот же результат достигается путем вызова setuid(getuid()), предшествующего exec(). И хотя setuid() изменяет действующий идентификатор пользователя только в процессе, чей UID не равен 0, привилегии все равно сбрасываются, потому что (как было описано в разделе 9.4) успешный вызов exec() делает сохраненный UID таким же, как и действующий (если же exec() завершается неудачей, сохраненный идентификатор остается без изменений; это может пригодиться в ситуациях, когда после неудачного вызова exec() программе приходится выполнять другие привилегированные операции).

Аналогичный подход (то есть вызов setgid(getgid())) можно применить к программам, устанавливающим идентификатор группы, поскольку вызов exec() делает сохраненный GID таким же, как и действующий.

Представьте, к примеру, что у нас есть программа, владелец которой имеет идентификатор 200. Если ее запустит пользователь с UID 1000, пользовательские идентификаторы итогового процесса будут выглядеть так:

реальный=1000 действующий=200 сохраненный=200

Если данная программа впоследствии выполнит вызов setuid(getuid()), пользовательские идентификаторы процесса изменятся следующим образом: