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

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

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

Альтернативой тюрьме chroot является виртуальный сервер; это сервер, реализованный поверх виртуального ядра. Поскольку все виртуальные ядра, работающие на одном и том же компьютере, изолированы друг от друга, виртуальный сервер обеспечивает лучшие безопасность и гибкость по сравнению с тюрьмой chroot (некоторые современные операционные системы предоставляют собственные реализации виртуальных серверов). Впервые механизм виртуализации в Linux был реализован в виде системы User-Mode Linux (Linux пользовательского режима, или UML), которая является стандартной частью ядра версии 2.6. Подробности о UML можно найти по адресу user-mode-linux.sourceforge.net. Более современные проекты виртуальных ядер основаны на системах Xen (www.cl.cam.ac.uk/Research/SRG/netos/xen/) и KVM (kvm.qumranet.com).

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

Особенно остро эта проблема стоит в случае с сигналами, которые останавливают процесс (например, SIGTSTP и SIGSTOP). Возможен следующий сценарий.

1. Программа, устанавливающая пользовательский идентификатор, определяет некоторые сведения о среде выполнения.

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

3. Пользователь возобновляет процесс с помощью сигнала SIGCONT. На этом этапе программа продолжит работу, оперируя ложными данными о среде выполнения, что может привести к дыре в безопасности.

Описанная выше ситуация на самом деле является всего лишь частным случаем состояния гонки вида «время проверки ко времени использования» (англ. time-of-check-to-time-of-use, или TOCTTOU). Привилегированный процесс не должен выполнять операции, основываясь на ранее проведенных проверках, которые могли потерять свою актуальность (конкретный пример приводится в подразделе 15.4.4, в котором обсуждается системный вызов access()). Эта рекомендация относится даже к тем случаям, когда пользователь не может отправлять процессу сигналы. Возможность остановить процесс просто позволяет увеличить интервал между моментом проверки и моментом использования.

Остановить программу в момент между проверкой данных и их использованием не так-то просто, но злоумышленник может предпринять множество попыток, применяя параллельно скрипт командной оболочки, который постоянно шлет программе сигналы остановки и изменяет среду выполнения. Это значительно увеличивает его шансы на успешный взлом программы.

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

• Атрибут umask процесса (см. подраздел 15.4.6) должен иметь значение, которое запрещает ему создавать файлы, открытые для публичной записи, поскольку они могут быть отредактированы злоумышленником.