Пример 2. Внешняя и внутренняя зоны

Понятно, что рассмотренный выше случай удобен для хостинга, позволяя пользователю самостоятельно выполнять очень многое, вплоть до установки нужных программ. Но когда речь идёт об использовании jail как средства повышения безопасности (например, для разделения системы на «внешнюю» и «внутреннюю» области), здесь есть один недостаток – дублирование всех системных файлов. Помимо нерационального расходования дискового пространства, это также усложняет и сопровождение системы – патчи в случае выявления уязвимости нужно устанавливать во всех «тюрьмах», обновлять несколько одинаковых деревьев ports и т. д.

Но есть способ свести дублирование информации к минимуму, который и рассмотрим на данном примере: пусть у нас есть один физический сервер и требуется реализовать на нём «внешнюю» систему, которая будет предоставлять услуги абонентам, такие как электронная почта, FTP-сервер и т. д. (своего рода DMZ, но в пределах одного физического сервера), и «внутреннюю», обеспечивающую некоторыми услугами пользователей локальной сети.

Поскольку локальную сеть можно считать менее опасной, чем Интернет, то для предоставления «внутренних» услуг будем использовать основную систему, в то время как все «внешние» службы перенесём в jail-окружение (см. рис. 2).

Рисунок 2. Внешние сервисы вынесены в jail

В отличие от предыдущего примера, здесь не предполагается, что какой-то пользователь внутри jail будет выполнять модификацию системы. Поэтому львиную долю всех файлов можно сделать «только для чтения». А раз так, то вместо копирования всех системных файлов в jail можно попробовать предоставить те же файлы, которые используются основной системой. Ссылки не подойдут, поскольку суперпользователь внутри «тюрьмы» сможет выставить на файлы нужные права, так что в случае компрометации jail-системы могут быть повреждены и системные файлы.

Избежать этого позволяет механизм монтирования. Если, скажем, в каталог /bin смонтировать файловую систему только для чтения, то из jail повредить её будет нельзя. Вы же помните, что в jail операции монтирования запрещены? А раз так, то и перемонтировать на чтение-запись эту файловую систему не удастся.

Итак, что мы можем смонтировать в jail с опцией ro? Во-первых, системные файлы – каталоги /bin, /sbin, /usr/bin и т. д. Во-вторых, каталог настроек – /etc. Ведь большую часть параметров можно будет установить и из  основной системы, где запись можно оставить разрешённой. Единственное, каталог /etc всё же лучше создать отдельный и монтировать уже его – иначе вы не сможете гибко разделять настройки основной и jail-систем. То есть в данном случае ro-монтирование выполняется не для экономии дискового пространства, а исключительно по соображениям безопасности.

Каталог портов /usr/ports можно будет монтировать (но на чтение-запись, поскольку это нужно для работы) только на время установки нового ПО. По большому счёту, можно вообще выполнять установку из основной системы, указав нужный PREFIX. Разве что некоторые действия придётся доделывать вручную (например, регистрацию в jail-системе нужных пользователей, поскольку при такой инсталляции они будут созданы в основной).

Теперь самое интересное – для монтирования всех этих каталогов их не нужно размещать на отдельных разделах. В FreeBSD есть очень удобный механизм mount_nullfs, позволяющий монтировать обычные каталоги. Например, ручное монтирование дерева портов может выглядеть таким образом: