FreeBSD Jail (англ. jail — «тюрьма») — механизм виртуализации в системе FreeBSD, позволяющий создавать внутри одной операционной системы FreeBSD несколько независимо работающих FreeBSD на том же ядре операционной системы, но совершенно независимо настраиваемых с независимым набором установленных приложений.

В основу FreeBSD Jail вошёл системный вызов chroot(2), при котором для текущего процесса и всех его потомков, корневой каталог переносится в определённое место на файловой системе. При этом это место для процесса становится корневым каталогом. Таким образом, изолированный процесс может иметь доступ только к низлежащему дереву каталогов.

Однако FreeBSD Jail также имеет поддержку на уровне ядра, что позволяет ограничивать доступ к сети, общей памяти, переменным ядра sysctl и ограничивать видимость процессов вне jail.

Процесс, заключённый в Jail может иметь доступ только к определённому IP-адресу операционной системы и использовать определённый hostname. Такой процесс называется «изолированный процесс» или «Jailed-процесс».

Таким образом, создаётся безопасная «клетка», внутри которой можно исполнять даже потенциально опасное программное обеспечение, которое не сможет никак повредить основной системе или другим таким же «клеткам». Впрочем, кое как всё-таки можно изнутри «клетки» повлиять на процессы вне её — FreeBSD Jail не контролирует использование ресурсов (как это делает, например, OpenVZ под Linux). Существуют патчи для версии 8.0-CURRENT, которые позволяют ограничивать ресурсы ЦП, ОП, число процессов и число файловых дескрипторов.^[1][2] и коммерческая разработка VDSManager, развивающая технологию Jails - более жесткое разграничение программ, запускаемых внутри jails по доступу к ресурсам и предоставляющая средства управления на базе web-интерфейса.

На уровне sysctl системы настраиваются привилегии Jailed-процессов:

Использование

Наиболее частое использование FreeBSD Jail — создание изолированных безопасных виртуальных машин. В этом случае с помощью jail(8) запускается инициализирующий скрипт /etc/rc, который инициализирует запуск отдельной изолированной виртуальной системы. В случае даже самого деструктивного взлома виртуальной системы и вывода её функциональности из строя, остальных запущенных виртуальных систем это не коснется.

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

Особенности использования виртуальных машин

FreeBSD Jail, при использовании в качестве виртуальной машины для запуска произвольного программного обеспечения, потребует полной эмуляции окружения системы, включая:

• Системное окружение утилит (создаётся с помощью make world DESTDIR=/path/to/jail)
• Настроенная конфигурация системы в /etc (временная зона, база данных пользователей и пр.)
• Примонтированный DevFS (mount_devfs devfs /path/to/jail/dev)

Каждая виртуальная машина на хостовой системе (до версии FreeBSD 7.2) обязательно потребует выделения одного IP-адреса для своего запуска. Теоретически, можно использовать один IP-адрес для нескольких машин, но при этом службы на этих виртуальных машинах не должны использовать одинаковые TCP/UDP порты.

Более подробно об установке и использовании FreeBSD Jail можно прочитать в страницах man jail(8) или в официальной документации.^[3]

Недостатки реализации Jail (во FreeBSD 7.1 и более ранних версиях)

• Невозможно использовать несколько IP-адресов для одного JAIL (без использования стороннего патча);
• Отсутствие разграничения системных лимитов между родительской и гостевой системой (без использования стороннего патча);
• Использование прямого доступа к устройствам (tcpdump и пр) возможно только через devfs.rules добавлением записи типа:

add path 'bpf*' unhide

Преимущества и недостатки реализации Jail (во FreeBSD 7.2)

• id пользователя в JAIL системе соответствует ID пользователя в родительской системе;
• Использование прямого доступа к устройствам (tcpdump и пр) по прежнему возможно только через devfs.rules добавлением записи типа:

add path 'bpf*' unhide

Примечания