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

Системный вызов chroot() не был задуман как абсолютно защищенный механизм для создания клетки. Начнем с того, что существуют различные способы, с помощью которых привилегированная программа может последовательно применять дальнейший вызов chroot() для выхода из клетки. Например, программа с привилегиями CAP_MKNOD может задействовать системный вызов mknod(), чтобы создать файл запоминающего устройства (подобный файлу /dev/mem), предоставляя доступ к содержимому оперативной памяти, после чего становится возможным все. В целом, рекомендуется не размещать программы set-user-ID-root внутри файловой системы с клеткой chroot.

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

• Вызов chroot() не меняет текущий рабочий каталог процесса. Следовательно, системный вызов chroot(), как правило, предваряется или завершается вызовом chdir() (то есть chdir("/") после вызова chroot()). Если это не выполнено, процесс может использовать относительные имена путей для доступа к файлам и каталогам вне клетки. (В некоторых BSD-ветках такая возможность предотвращается: если текущий рабочий каталог расположен вне нового дерева корневого каталога, то системный вызов chroot() делает его таким же, как корневой.)

• Если процесс удерживает открытый файловый дескриптор каталога, расположенного вне клетки, то можно воспользоваться комбинацией вызовов fchdir() и chroot(), чтобы выйти за ее пределы, как показано в следующем примере кода:

int fd;

fd = open("/", O_RDONLY);

chroot("/home/mtk"); /* Внутри клетки */

fchdir(fd);

chroot("."); /* Вне клетки */

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

• Но даже такого устранения описанных возможностей оказывается недостаточно для того, чтобы запретить произвольной непривилегированной программе (то есть такой, чьей работой мы не можем управлять) выход из клетки. Заключенный в нее процесс может использовать сокет домена UNIX для получения файлового дескриптора (от другого процесса), указывающего на каталог вне клетки. (Принцип передачи файловых дескрипторов между процессами с помощью сокета вкратце описан в подразделе 57.13.3.) Указав данный дескриптор при вызове fchdir(), программа может определить для себя текущий рабочий каталог вне клетки, а затем осуществлять доступ к любым файлам и каталогам с помощью относительных имен путей.

В отдельных BSD-ветках присутствует системный вызов jail(), устраняющий проблемы, описанные выше, а также ряд других за счет создания клетки, которая является защищенной даже для привилегированного процесса.

18.13. Анализ имени пути: функция realpath()

Библиотечная функция realpath() разыменовывает все символические ссылки в аргументе pathname (который является строкой с завершающим нулем) и выполняет анализ всех ссылок на /. и /… чтобы выдать строку с завершающим нулем, содержащую соответствующее абсолютное имя пути.

Результирующая строка размещается в буфере, указанном в аргументе resolved_path, который должен быть символьным массивом, содержащим по меньшей мере PATH_MAX байт. При успешном завершении функция realpath() также возвращает указатель на эту проанализированную строку.

#include

char *realpath(const char *pathname, char *resolved_path);

При успешном завершении возвращает указатель на проанализированное имя пути или NULL при ошибке

Функция realpath(), реализованная в библиотеке glibc, позволяет вызывающему процессу указать для аргумента resolved_path значение NULL. В таком случае функция realpath() выделяет буфер размером до PATH_MAX байт для проанализированного имени пути и возвращает указатель на данный буфер. (Вызывающий процесс должен освободить этот буфер с помощью вызова free().) В стандарте SUSv3 не описано такое расширение возможностей, но оно есть в стандарте SUSv4.

Программа в листинге 18.4 задействует вызов readlink() и функцию realpath() для чтения содержимого символической ссылки и для ее анализа с преобразованием в абсолютное имя пути. Ниже приведен пример использования этой программы:

$ pwd Где мы находимся?

/home/mtk

$ touch x Создаем файл

$ ln — s x y и символическую ссылку на него

$ ./view_symlink y

readlink: y — > x

realpath: y — > /home/mtk/x

Листинг 18.4. Чтение и анализ символической ссылки

irs._links/view_symlink.c

#include

#include  /* Для определения PATH_MAX */

#include "tlpi_hdr.h"

#define BUF_SIZE PATH_MAX

int

main(int argc, char *argv[])

{

struct stat statbuf;

char buf[BUF_SIZE];

ssize_t numBytes;

if (argc!= 2 || strcmp(argv[1], " — help") == 0)