работа с зонами в Solaris 10
Зонная технология - это новый компонент Solaris 10 N1 Grid Computing Environment. Зоны позволяют системным администраторам разделить ОС Solaris на несколько виртуальных составляющих ОС, которые полностью изолированы друг от друга и даже не взаимодействуют. В отличие от ПО виртуальных машин, например VMWare, которые создают виртуальное железо, чтобы позволить составным ОС запускаться независимо на одной реальной машине, зоны Solaris позволяют создать виртуальную среду самого Solaris. Это позволяет нескольким частям среды Solaris запускаться в пределах одного ядра OS.
Зонная технология имеет много практических применений в управлении системными ресурсами и безопасностью. В этой статье я покажу достоинства зон в системной безопасности, а также основные процедуры, используемые для конфигурирования и управления зонами, практическую демонстрацию зонной технологии для изоляции содержания apache Web сервера. Хотя эта статья и рассматривает зоны с точки зрения безопасности, информация, приведенная в описании настройки и управления в основном приемлема для использования зон в любых целях.
cоздание виртуальной среды и безопасность
Основной целью при установке сетевого приложения безопасности на сервер считается снижение вероятности ущерба, если атакующий узнает это приложение. Представьте ситуацию, когда атакующий использует уязвимость в веб-сервере, например apache, чтобы получить локальный доступ к серверу. Теперь атакующий потенциально может копаться на сервере в поиске локальных уязвимостей для поднятия своих привилегий. При успехе атакующий может контролировать весь сервер и все данные и приложения, хостящиеся на нем.
В среде Unix часто используют утилиту chroot, позволяющую изолировать сетевое приложение от других ресурсов системы. Chroot дает возможность системному администратору закрыть процесс и все вызванные им другие процессы в «виртуальную» файловую систему. Chroot’ированный процесс имеет свою root’овую директорию, связанную с настоящим системным root, и защищен от доступа к файлам, расположенным вне. Чтобы реализовать chroot для какого-либо приложения, вам понадобятся все файлы (библиотеки, бинарники, файлы конфигурации), используемые приложением, которые должны быть продублированы в chroot-директории. Иногда это может оказаться сложной задачей.
Следует добавить, что хоть chroot и предотвращает попытки приложения обращаться к файловой системе, сами chroot’ированные процессы не изолированы от других ресурсов и процессов в системе. То есть процесс в chroot все еще может наблюдать и взаимодействовать с процессами не из chroot. К тому же уже опубликованы методы выхода из среды chroot, например -сайтЗонная технология Solaris предоставляет собой значительно усовершенствованный chroot. Использование зон Solaris позволит вам создавать полностью виртуальную ОС для изолирования процессов как на уровне файловой системы, так и не уровне процессов сети. Проще говоря, в Solaris 10 каждая система содержит одну зону, известную как глобальная зона, и неглобальные зоны (их может и не быть). Глобальная зона на самом деле мало чем отличается от среды настоящего Solaris 10. Глобальная зона используется для управления реальными устройствами и администрирования неглобальных зон.
Итак, неглобальная зона - это виртуальная среда ОС. Процессы, запущенные в ней, не могут обращаться или взаимодействовать с процессами из других зон. И даже информация о реальных устройствах, например, имена локальных дисков, является недоступной для процессов, запущенных в неглобальных зонах. Если защита неглобальной зоны повреждена, то другие зоны все равно находятся в безопасности. Кроме того, процессы в этих зонах работают под разными ограничениями. К примеру, они не могут осуществлять администрирование оборудования и загружать или выгружать модули ядра. Использование зон не избавляет от необходимости обновления операционных систем и приложений. Если атакующий добивается доступа с привилегиями root в неглоаблную зону, он сможет убивать процессы и удалять файлы в пределах зоны, а также перезапускать зону. Как бы то ни было, атакующий не сможет повредить данные и приложения, запущенные в других зонах на системе. Также, если зона взломана, прочистку ее после обнаружения вторжения будет осуществить очень легко. Неглобальные зоны могут быть перезапущены независимо от других зон, таким образом, зона может быть восстановлена или перестроена без необходимости выключения всей системы и остановки приложений в других зонах.
Некоторые разновидности Unix имеют возможности, похожие на зоны Solaris 10. Например, механизм Jail в FreeBSD, впервые появившийся в FreeBSD 4.0 (релиз 2000 года), предоставляет в принципе такие же возможности, как и зоны Solaris 10. СмотритесайтВ среде Linux существует проект Vserver - предлагается патч ядра и набор утилит для создания виртуальной среды Linux. Подробности в документесайт
построение зон в Solaris
Solaris 10 поддерживает до 8191 неглобальных зон в обычной поставке Solaris. Каждая неглобальная зона зависима от директории root глобальной зоны. К счастью, создание неглобальной зоны не требует дублирования всей операционки Solaris и файлов с библиотеками. Дублируются только несколько зависимых системных бинарников, плюс конфигурационные файлы. Большинство системных библиотек и бинарников используются совместно глобальной и неглобальной зоной. Директории /lib, /platform, /sbin и /usr доступны из глобальной зоны неглобальным зонам через loopback filesystem c разрешением «только чтение».
Неглобальной зоне может быть отведено один или несколько реальных сетевых интерфейсов, доступных в системе. К каждому физическому интерфейсу привязывается неглобальная зона, виртуальный сетевой интерфейс и уникальный IP-адрес. Процессы неглобальной зоны могут отправлять и получать трафик, используя только виртуальные сетевые интерфейсы, привязанные к этой зоне.
Процессы, запущенные в пределах неглобальной зоны, имеют различные ограничения. Например, нельзя загружать или выгружать модуль ядра из неглобальной зоны, даже имея root’овые привилегии. Кроме того, эти процессы не могут использовать интерфейс «сырых сокетов» (raw sockets) для протокола, отличного от ICMP. Этот запрет предотвращает возможность посылки ложных IP-пакетов (или просто спуфа).
системные требования зоны
В документации Sun сказано, что необходимое дисковое пространство для неглобальной зоны зависит от пакетов, установленных в глобальной зоне, и Sun рекомендует 100 МБ для неглобальной зоны, при условии что глобальная зона была установлена из стандартного пакета (standard Solaris packages).
Моя глобальная зона была установлена из пакета "Entire Distribution Plus OEM Support", и неглобальные зоны занимали около 85 МБ дискового пространства. Sun также рекомендует дополнительно 40 МБ RAM для каждой зоны, но это не требование, а просто рекомендация.
Моя тестовая система Solaris 10 была запущена в пределах сессии VMWare на машине Dell Precision 670 с 1 ГБ RAM и с двумя Pentium 4 Xeon процессоромами, с запущенной Windows XP как базовой ОС.
настройка зоны
Первым шагом в создании зоны является создание ее конфигурирование. Для начала, соберите следующую информацию:
- название физического Ethernet-адаптера, который будет использоваться неглобальной зоной;
- IP адрес неглобальной зоны;
- имя, которое будет присвоено неглобальной зоне, и путь к директории, которую зона будет использовать как свой root.
В моем случае: физическое Ethernet-устройство - pcn0; IP-адрес - 192.168.1.11, имя зоны "twilight, root моей зоны будет расположен в /zone/twilight.
С помощью утилиты zonecfg можно настраивать неглобальные зоны. Начинается настройка с запуска команды zonecfg с параметром –z. Теперь можно присвоить имя. После этого zonecfg предоставит интерактивный диалог в командной строке, из которого вы сможете настроить зону, используя несколько подкоманд.
После выполнения подкоманды create, присвойте значения параметрам zonepath и autoboot, используя команду set. zonepath – определение root- директории, параметром autoboot определяется, будет ли зона загружаться автоматически вместе с системой. Для указания сетевого интерфейса используйте подкоманду add net для определения физического сетевого устройства, а затем присвойте IP-адрес. Вот как выглядел диалог в моем случае:
# zonecfg -z twilight
twilight: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:twilight>create
zonecfg:twilight>set zonepath=/zone/twilight
zonecfg:twilight>set autoboot=true
zonecfg:twilight>add net
zonecfg:twilight:net>set address=192.168.1.11
zonecfg:twilight:net>set physical=pcn0
zonecfg:twilight:net>end
Можно просмотреть конфигурацию созданной зоны, использую подкоманду info. Заметьте, что строки "inherit-pkg-dir" отображаются при выводе результата выполнения команды. Как было упомянуто выше, такое поведение устанавливается по умолчанию для совместного использования этих файловых систем и их блоков глобальной и неглобальными зонами. Администратор может настраивать совместный доступ к дополнительным директориям (как будет показано позже).
zonecfg:twilight>info
zonepath: /zone/twilight
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 192.168.1.11
physical: pcn0
Для завершения настройки проверьте конфигурацию, подтвердите изменения и выйдите из программы:
zonecfg:twilight>verify
zonecfg:twilight>commit
zonecfg:twilight>exit
Solaris хранит информацию о настройках всех неглобальных зон в директории /etc/zones. Стартовый скрипт /etc/rc3.d/S99zones отвечает за запуск среды неглобальной зоны в момент загрузки системы.
инсталляция зоны
Второй шаг создания зоны – это ее «инсталляция». Этот процесс собирает зону посредством копирования необходимых бинарников и системных настроек в директорию root неглобальной зоны, а также инициализирует пакетную базу данных зоны. Команда zoneadm используется для инсталляции зоны:
# zoneadm -z twilight install
Preparing to install zone.
Creating list of files to copy from the global zone.
Copying<2860>files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize<765>packages on the zone.
Initialized<765>packages on zone.
Zoneis initialized.
The filecontains a log of the zone installation.
В процессе инсталляции Solaris помещает копии системных настроек (/etc/passwd, /etc/group, /etc/default/*, /etc/inet/inetd.conf и др.) в директорию root неглобальной зоны. Версии файлов, установленных в неглобальную зону, идентичны версиям файлов только что установленной ОС. Однако неглобальная зона не наследует версии этих файлов от глобальной зоны. Это означает, что любые изменения в настройках глобальной зоны должны быть продублированы вручную для каждой созданной неглобальной зоны.
Обычно, установка зоны занимает несколько минут. После окончания установки, необходимо загрузить зону, выполнив команду zoneadm из глобальной зоны с параметром boot:
# zoneadm -z twilight boot
>/tt>
После первой загрузки зоны вам необходимо залогиниться в ее консоль и завершить некоторые базовые установки. Чтобы залогиниться в неглобальную зону, используйте команду zlogin с параметром –C и укажите имя зоны:
# zlogin -e \@ -C twilight
Параметр –C указывает на зону. Параметр –e указывает на знак выхода и используется для отключения от консоли зоны. Если –e не указан, то zlogin использует знак «~» для выхода, но это приводит к конфликту с последовательностью выхода из SSH. Поэтому, лучше использовать альтернативный способ выхода из zlogin, если вы находитесь в сессии SSH.
После входу в новую зону в первый раз, вам будет предложено выполнить основные настройки, такие как язык, имя хоста, параметры безопасности Kerberos, имя конфигурации сервиса, время зоны и пароль на root. После этого зона готова к использованию
Для отключения от консоли неглобальной зоны нажмите "@" и "." одновременно. Это довольно-таки неудобно и придется потренироваться, чтобы научиться.
управление зоной
Настраивать неглобальную зону следует только из глобальной зоны. Большинство команд управления зоной будут возвращать ошибку при попытке выполнения их в неглобальной зоне:
# zonecfg -z twilight
Zonecfg can only be run from the global zone
Команды zoneadm, zlogin, zonename, и zonecfg позволяют настраивать все основные параметры зоны. Для просмотра всех зон, установленных на системе (глобальных и неглобальных), запустите команду zoneadm из глобальной зоны с использованием подкоманды list и параметра -v:
# zoneadm list –v
ID NAME STATUS PATH
0 global running /
1 twilight running /zone/twilight
Для отключения неглобальной зоны, используйте команду zlogin:
# zlogin twilight shutdown
Для полного удаления неглобальной зоны из системы, сначала остановите ее работу, затем проведите удаление зоны, и, наконец, отмените все ее настройки. Хочу вас предупредить заранее – удаление неглобальной приводит к полной потере файлов и данных, ассоциированной c этой зоной:
# zoneadm -z twilight halt
# zoneadm -z twilight uninstall
Are you sure you want to uninstall zone twilight (y/[n])? Y
# zonecfg -z twilight delete
Are you sure you want to delete zone twilight (y/[n])? Y
#
Наконец, команда zonename может быть запущена как из глобальной, так и из неглобальной зон, что дает возможность легко определить, в какой зоне вы сейчас находитесь:
# zonename
global
основные задачи администрирования зон
Большинство стандартных системных команд управления в Solaris были разработаны для поддержки концепции зон. Например, утилита df теперь поддерживает параметр –Z, которая отображает смонтированные диски во всех зонах (если запущена в глобальной зоне).
При запуске из глобальной зоны /usr/bin/ps с параметром –ef отображаются процессы, запущенные во всех зонах. Чтобы выделить зону, в которой запущен определенный процесс, добавьте параметр –Z. Это приведет к добавлению еще одной колонки в результат выполнения команды, в которой будет показано имя зоны и запущенные в ней процессы. Также для просмотра запущенных процессов в отедльной зоне можно использовать параметр –z, после чего указать имя зоны.
Единственная задача, которая не меняется – это завершение процессов. ID всех процессов уникальны во всех зонах, таким образом, используя команду kill, имя зоны указывать не нужно.
управление пакетами и патчами
Управление пакетами и патчами, возможно, самая сложная часть управления зонами Solaris. Не смотря на то, что все кажется понятным, существует несколько новых правил, которые следует запомнить.
Команда pkgadd запускается из глобальной зоны, причем ее выполнение действует на все зоны. Это позволяет легко устанавливать новые пакеты на глобальную и неглобальные зоны. Если же команда pkgadd запущенна с параметром –G, то результат ее выполнения повлияет только на глобальную зону. При наличии пакетов в глобальной зоне используется параметр –Z, что приводит к изменениям только в неглобальных зонах.
Выполнить эту команду для отдельной неглобальной зоны (или нескольких неглобальных зон) из глобальной зоны нельзя. Для этого нужно залогиниться в каждую неглобальную зону отдельно и уже оттуда выполнять команду pkgadd.
Команда pkgrm работает почти также как и pkgadd. Но здесь существует один нюанс. Когда pkgrm запущена из глобальной зоны с параметром –Z, пакет удаляется из всех неглобальных зон. К тому же, пакет не будет установлен во вновь создаваемые зоны.
Управлять патчами немного легче. При запуске утилит patchadd или patchrm из глобальной зоны, изменения подействуют на все зоны. Но при запуске этих команд в неглобальной зоне изменения вступят в силу только в той зоне, откуда производился запуск команд.
Остается сделать одну поправку касательно управления пакетами и патчами из неглобальных зон. При запуске утилит управления пакетом или патчем из неглобальной зоны операция пройдет успешно только в том случае, если на пакеты/патчи, уже используемые глобальной и неглобальными зонами, изменения не повлияют.
зона apache
Для наглядности использования зон я создам неглобальную зону, назову ее "webserver", служить она будет для хостинга apache 2.0.52. Для построения этой зоны я буду придерживаться следующих стратегий для построения этой зоны: сервер apache будет собран и установлен из глобальной зоны. Содержание веб-сервера будет также храниться в глобальной зоне. Код дерева и содержание apache будет совместно использоваться из глобальной зоны неглобальной зоной через смонтированное кольцевое соединение с доступом «только чтение» (read-only loop back). Это даст следующее преимущество: веб-контент будет защищен от изменений процессами из неглобальной зоны.
Первый шаг в сборке сервера apache. В глобальной зоне я создал раздел /web. Устанавливать apache я буду в /web/apache2. Вот последовательность команд для сборки и инсталляции сервера:
# cd /tmp
# gunzip -c httpd-2.0.52.tar.gz | tar xf -
# cd httpd-2.0.52
# ./configure --prefix=/web/apache2
# make
# make install
В глобальной зоне я также создам группу httpd для владения установкой apache:
# groupadd -g 99 httpd
# chmod -R root:httpd /web
# chmod -R 750 /web
По умолчанию apache будет писать логи и pid-файлы в свою установочную директорию. Вследствие того, что неглобальная зона подмонтирует директорию /web в режиме «только чтение», наш сервер не сможет записать какие-либо файлы в /web. Директивы PidFile, Lockfile, ErrorLog, и CustomLog в конфиге apache (/web/apache2/conf/httpd.conf) должны быть изменены и направлены в место, доступное для записи неглобальной зоной:
PidFile /var/run/httpd.pid
LockFile /var/run/accept.lock
ErrorLog /var/log/apache_error_log
CustomLog /var/log/apache_access_log
В целях безопасности я возложу работу apache на отдельный, непривилегированный акаунт. Для этого с момента запуска зоны я создам пользователя и группу httpd. Между тем, я исправлю файл конфигурации apache и укажу в директивах User и Group акаунт httpd:
User httpd
Group httpd
Установка apache завершена, и сейчас я создам неглобальную зону. Процесс настройки в принципе такой же, как было показано выше. В данном случае имя зоны - webserver, root-директория - /zone/webserver, IP-адрес - 192.168.1.12. Кроме того, для совместного использования директории /web глобальной и неглобальной зонами, я буду использовать команду add inherit-pkg-dir:
# zonecfg -z webserver
webserver: No such zone configured Use 'create' to begin
configuring a new zone.
zonecfg:webserver>create
zonecfg:webserver>set zonepath=/zone/webserver
zonecfg:webserver>set autoboot=true
zonecfg:webserver>add net
zonecfg:webserver:net>set address=192.168.1.12
zonecfg:webserver:net>set physical=pcn0
zonecfg:webserver:net>end
zonecfg:webserver>add inherit-pkg-dir
zonecfg:webserver:inherit-pkg-dir>set dir=/web
zonecfg:webserver:inherit-pkg-dir>end
zonecfg:webserver>info
zonepath: /zone/webserver
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
inherit-pkg-dir:
dir: /web
net:
address: 192.168.1.12
physical: pcn0
zonecfg:webserver>verify
zonecfg:webserver>commit
zonecfg:webserver>exit
Итак, зона настроена. Сейчас я проинсталлирую и загружу ее, как описано раннее в примере. После запуска зоны я создаю пользователя и группу httpd:
# groupadd -g 99 httpd
# useradd -d /www/apache2 -u 99 -g httpd httpd
Заметьте, что я использую тот же gid для группы httpd в неглобальной зоне, какой и в глобальной зоне. Это гарантирует, что группа httpd в неглобальной зоне будет иметь доступ к файлам директории /web/apache2, владеет которой группа httpd в глобальной зоне.
Наконец, я создаю стартовый скрипт rc для apache в неглобальной зоне, с именем /etc/init.d/apache_2_0_52 со следующим содержанием:
#! /bin/sh
APACHECTL=/web/apache2/bin/apachectl
case "$1" in
start) $APACHECTL start
;;
restart) $APACHECTL restart
;;
stop) $APACHECTL stop
;;
*) echo "usage: $0 start|restart|stop"
;;
esac
Следующие команды инсталлируют стартовый скрипт rc:
# chmod 744 /etc/init.d/apache_2_0_52
# ln /etc/init.d/apache_2_0_52 /etc/rc3.d/S99apache
Теперь сервер apache готов к запуску из неглобальной зоны. Эта конфигурация представляет один из возможных способов сборки неглобальной зоны для хостинга apache.
заключение
Будучи определенно полезным для изоляции приложений, использование зон не избавляет от необходимости улучшения безопасности систем и приложений. Использование зон снижает вероятность атакующего перехватить контроль над всей системой, которую будет эмитировать неглобальная зона. Даже если вы используете зоны, вам захочется усилить безопасность как глобальной, так и неглобальных зон, используя лучшие наработки, доступные в Центре Интернет Безопасности (The Center for Internet Security, cisecurity.org).
Некоторые другие функции зон не были рассмотрены в этой статье. Например, возможность устанавливать лимиты на использование системных ресурсов (ЦПУ и память) зонами. Дополнительную информацию можно найти в документации Sun.
Kevin Wenchel, перевод Войновича Андрея.
Зонная технология имеет много практических применений в управлении системными ресурсами и безопасностью. В этой статье я покажу достоинства зон в системной безопасности, а также основные процедуры, используемые для конфигурирования и управления зонами, практическую демонстрацию зонной технологии для изоляции содержания apache Web сервера. Хотя эта статья и рассматривает зоны с точки зрения безопасности, информация, приведенная в описании настройки и управления в основном приемлема для использования зон в любых целях.
cоздание виртуальной среды и безопасность
Основной целью при установке сетевого приложения безопасности на сервер считается снижение вероятности ущерба, если атакующий узнает это приложение. Представьте ситуацию, когда атакующий использует уязвимость в веб-сервере, например apache, чтобы получить локальный доступ к серверу. Теперь атакующий потенциально может копаться на сервере в поиске локальных уязвимостей для поднятия своих привилегий. При успехе атакующий может контролировать весь сервер и все данные и приложения, хостящиеся на нем.
В среде Unix часто используют утилиту chroot, позволяющую изолировать сетевое приложение от других ресурсов системы. Chroot дает возможность системному администратору закрыть процесс и все вызванные им другие процессы в «виртуальную» файловую систему. Chroot’ированный процесс имеет свою root’овую директорию, связанную с настоящим системным root, и защищен от доступа к файлам, расположенным вне. Чтобы реализовать chroot для какого-либо приложения, вам понадобятся все файлы (библиотеки, бинарники, файлы конфигурации), используемые приложением, которые должны быть продублированы в chroot-директории. Иногда это может оказаться сложной задачей.
Следует добавить, что хоть chroot и предотвращает попытки приложения обращаться к файловой системе, сами chroot’ированные процессы не изолированы от других ресурсов и процессов в системе. То есть процесс в chroot все еще может наблюдать и взаимодействовать с процессами не из chroot. К тому же уже опубликованы методы выхода из среды chroot, например -сайтЗонная технология Solaris предоставляет собой значительно усовершенствованный chroot. Использование зон Solaris позволит вам создавать полностью виртуальную ОС для изолирования процессов как на уровне файловой системы, так и не уровне процессов сети. Проще говоря, в Solaris 10 каждая система содержит одну зону, известную как глобальная зона, и неглобальные зоны (их может и не быть). Глобальная зона на самом деле мало чем отличается от среды настоящего Solaris 10. Глобальная зона используется для управления реальными устройствами и администрирования неглобальных зон.
Итак, неглобальная зона - это виртуальная среда ОС. Процессы, запущенные в ней, не могут обращаться или взаимодействовать с процессами из других зон. И даже информация о реальных устройствах, например, имена локальных дисков, является недоступной для процессов, запущенных в неглобальных зонах. Если защита неглобальной зоны повреждена, то другие зоны все равно находятся в безопасности. Кроме того, процессы в этих зонах работают под разными ограничениями. К примеру, они не могут осуществлять администрирование оборудования и загружать или выгружать модули ядра. Использование зон не избавляет от необходимости обновления операционных систем и приложений. Если атакующий добивается доступа с привилегиями root в неглоаблную зону, он сможет убивать процессы и удалять файлы в пределах зоны, а также перезапускать зону. Как бы то ни было, атакующий не сможет повредить данные и приложения, запущенные в других зонах на системе. Также, если зона взломана, прочистку ее после обнаружения вторжения будет осуществить очень легко. Неглобальные зоны могут быть перезапущены независимо от других зон, таким образом, зона может быть восстановлена или перестроена без необходимости выключения всей системы и остановки приложений в других зонах.
Некоторые разновидности Unix имеют возможности, похожие на зоны Solaris 10. Например, механизм Jail в FreeBSD, впервые появившийся в FreeBSD 4.0 (релиз 2000 года), предоставляет в принципе такие же возможности, как и зоны Solaris 10. СмотритесайтВ среде Linux существует проект Vserver - предлагается патч ядра и набор утилит для создания виртуальной среды Linux. Подробности в документесайт
построение зон в Solaris
Solaris 10 поддерживает до 8191 неглобальных зон в обычной поставке Solaris. Каждая неглобальная зона зависима от директории root глобальной зоны. К счастью, создание неглобальной зоны не требует дублирования всей операционки Solaris и файлов с библиотеками. Дублируются только несколько зависимых системных бинарников, плюс конфигурационные файлы. Большинство системных библиотек и бинарников используются совместно глобальной и неглобальной зоной. Директории /lib, /platform, /sbin и /usr доступны из глобальной зоны неглобальным зонам через loopback filesystem c разрешением «только чтение».
Неглобальной зоне может быть отведено один или несколько реальных сетевых интерфейсов, доступных в системе. К каждому физическому интерфейсу привязывается неглобальная зона, виртуальный сетевой интерфейс и уникальный IP-адрес. Процессы неглобальной зоны могут отправлять и получать трафик, используя только виртуальные сетевые интерфейсы, привязанные к этой зоне.
Процессы, запущенные в пределах неглобальной зоны, имеют различные ограничения. Например, нельзя загружать или выгружать модуль ядра из неглобальной зоны, даже имея root’овые привилегии. Кроме того, эти процессы не могут использовать интерфейс «сырых сокетов» (raw sockets) для протокола, отличного от ICMP. Этот запрет предотвращает возможность посылки ложных IP-пакетов (или просто спуфа).
системные требования зоны
В документации Sun сказано, что необходимое дисковое пространство для неглобальной зоны зависит от пакетов, установленных в глобальной зоне, и Sun рекомендует 100 МБ для неглобальной зоны, при условии что глобальная зона была установлена из стандартного пакета (standard Solaris packages).
Моя глобальная зона была установлена из пакета "Entire Distribution Plus OEM Support", и неглобальные зоны занимали около 85 МБ дискового пространства. Sun также рекомендует дополнительно 40 МБ RAM для каждой зоны, но это не требование, а просто рекомендация.
Моя тестовая система Solaris 10 была запущена в пределах сессии VMWare на машине Dell Precision 670 с 1 ГБ RAM и с двумя Pentium 4 Xeon процессоромами, с запущенной Windows XP как базовой ОС.
настройка зоны
Первым шагом в создании зоны является создание ее конфигурирование. Для начала, соберите следующую информацию:
- название физического Ethernet-адаптера, который будет использоваться неглобальной зоной;
- IP адрес неглобальной зоны;
- имя, которое будет присвоено неглобальной зоне, и путь к директории, которую зона будет использовать как свой root.
В моем случае: физическое Ethernet-устройство - pcn0; IP-адрес - 192.168.1.11, имя зоны "twilight, root моей зоны будет расположен в /zone/twilight.
С помощью утилиты zonecfg можно настраивать неглобальные зоны. Начинается настройка с запуска команды zonecfg с параметром –z. Теперь можно присвоить имя. После этого zonecfg предоставит интерактивный диалог в командной строке, из которого вы сможете настроить зону, используя несколько подкоманд.
После выполнения подкоманды create, присвойте значения параметрам zonepath и autoboot, используя команду set. zonepath – определение root- директории, параметром autoboot определяется, будет ли зона загружаться автоматически вместе с системой. Для указания сетевого интерфейса используйте подкоманду add net для определения физического сетевого устройства, а затем присвойте IP-адрес. Вот как выглядел диалог в моем случае:
# zonecfg -z twilight
twilight: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:twilight>create
zonecfg:twilight>set zonepath=/zone/twilight
zonecfg:twilight>set autoboot=true
zonecfg:twilight>add net
zonecfg:twilight:net>set address=192.168.1.11
zonecfg:twilight:net>set physical=pcn0
zonecfg:twilight:net>end
Можно просмотреть конфигурацию созданной зоны, использую подкоманду info. Заметьте, что строки "inherit-pkg-dir" отображаются при выводе результата выполнения команды. Как было упомянуто выше, такое поведение устанавливается по умолчанию для совместного использования этих файловых систем и их блоков глобальной и неглобальными зонами. Администратор может настраивать совместный доступ к дополнительным директориям (как будет показано позже).
zonecfg:twilight>info
zonepath: /zone/twilight
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
net:
address: 192.168.1.11
physical: pcn0
Для завершения настройки проверьте конфигурацию, подтвердите изменения и выйдите из программы:
zonecfg:twilight>verify
zonecfg:twilight>commit
zonecfg:twilight>exit
Solaris хранит информацию о настройках всех неглобальных зон в директории /etc/zones. Стартовый скрипт /etc/rc3.d/S99zones отвечает за запуск среды неглобальной зоны в момент загрузки системы.
инсталляция зоны
Второй шаг создания зоны – это ее «инсталляция». Этот процесс собирает зону посредством копирования необходимых бинарников и системных настроек в директорию root неглобальной зоны, а также инициализирует пакетную базу данных зоны. Команда zoneadm используется для инсталляции зоны:
# zoneadm -z twilight install
Preparing to install zone
Creating list of files to copy from the global zone.
Copying<2860>files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize<765>packages on the zone.
Initialized<765>packages on zone.
Zone
The filecontains a log of the zone installation.
В процессе инсталляции Solaris помещает копии системных настроек (/etc/passwd, /etc/group, /etc/default/*, /etc/inet/inetd.conf и др.) в директорию root неглобальной зоны. Версии файлов, установленных в неглобальную зону, идентичны версиям файлов только что установленной ОС. Однако неглобальная зона не наследует версии этих файлов от глобальной зоны. Это означает, что любые изменения в настройках глобальной зоны должны быть продублированы вручную для каждой созданной неглобальной зоны.
Обычно, установка зоны занимает несколько минут. После окончания установки, необходимо загрузить зону, выполнив команду zoneadm из глобальной зоны с параметром boot:
# zoneadm -z twilight boot
>/tt>
После первой загрузки зоны вам необходимо залогиниться в ее консоль и завершить некоторые базовые установки. Чтобы залогиниться в неглобальную зону, используйте команду zlogin с параметром –C и укажите имя зоны:
# zlogin -e \@ -C twilight
Параметр –C указывает на зону. Параметр –e указывает на знак выхода и используется для отключения от консоли зоны. Если –e не указан, то zlogin использует знак «~» для выхода, но это приводит к конфликту с последовательностью выхода из SSH. Поэтому, лучше использовать альтернативный способ выхода из zlogin, если вы находитесь в сессии SSH.
После входу в новую зону в первый раз, вам будет предложено выполнить основные настройки, такие как язык, имя хоста, параметры безопасности Kerberos, имя конфигурации сервиса, время зоны и пароль на root. После этого зона готова к использованию
Для отключения от консоли неглобальной зоны нажмите "@" и "." одновременно. Это довольно-таки неудобно и придется потренироваться, чтобы научиться.
управление зоной
Настраивать неглобальную зону следует только из глобальной зоны. Большинство команд управления зоной будут возвращать ошибку при попытке выполнения их в неглобальной зоне:
# zonecfg -z twilight
Zonecfg can only be run from the global zone
Команды zoneadm, zlogin, zonename, и zonecfg позволяют настраивать все основные параметры зоны. Для просмотра всех зон, установленных на системе (глобальных и неглобальных), запустите команду zoneadm из глобальной зоны с использованием подкоманды list и параметра -v:
# zoneadm list –v
ID NAME STATUS PATH
0 global running /
1 twilight running /zone/twilight
Для отключения неглобальной зоны, используйте команду zlogin:
# zlogin twilight shutdown
Для полного удаления неглобальной зоны из системы, сначала остановите ее работу, затем проведите удаление зоны, и, наконец, отмените все ее настройки. Хочу вас предупредить заранее – удаление неглобальной приводит к полной потере файлов и данных, ассоциированной c этой зоной:
# zoneadm -z twilight halt
# zoneadm -z twilight uninstall
Are you sure you want to uninstall zone twilight (y/[n])? Y
# zonecfg -z twilight delete
Are you sure you want to delete zone twilight (y/[n])? Y
#
Наконец, команда zonename может быть запущена как из глобальной, так и из неглобальной зон, что дает возможность легко определить, в какой зоне вы сейчас находитесь:
# zonename
global
основные задачи администрирования зон
Большинство стандартных системных команд управления в Solaris были разработаны для поддержки концепции зон. Например, утилита df теперь поддерживает параметр –Z, которая отображает смонтированные диски во всех зонах (если запущена в глобальной зоне).
При запуске из глобальной зоны /usr/bin/ps с параметром –ef отображаются процессы, запущенные во всех зонах. Чтобы выделить зону, в которой запущен определенный процесс, добавьте параметр –Z. Это приведет к добавлению еще одной колонки в результат выполнения команды, в которой будет показано имя зоны и запущенные в ней процессы. Также для просмотра запущенных процессов в отедльной зоне можно использовать параметр –z, после чего указать имя зоны.
Единственная задача, которая не меняется – это завершение процессов. ID всех процессов уникальны во всех зонах, таким образом, используя команду kill, имя зоны указывать не нужно.
управление пакетами и патчами
Управление пакетами и патчами, возможно, самая сложная часть управления зонами Solaris. Не смотря на то, что все кажется понятным, существует несколько новых правил, которые следует запомнить.
Команда pkgadd запускается из глобальной зоны, причем ее выполнение действует на все зоны. Это позволяет легко устанавливать новые пакеты на глобальную и неглобальные зоны. Если же команда pkgadd запущенна с параметром –G, то результат ее выполнения повлияет только на глобальную зону. При наличии пакетов в глобальной зоне используется параметр –Z, что приводит к изменениям только в неглобальных зонах.
Выполнить эту команду для отдельной неглобальной зоны (или нескольких неглобальных зон) из глобальной зоны нельзя. Для этого нужно залогиниться в каждую неглобальную зону отдельно и уже оттуда выполнять команду pkgadd.
Команда pkgrm работает почти также как и pkgadd. Но здесь существует один нюанс. Когда pkgrm запущена из глобальной зоны с параметром –Z, пакет удаляется из всех неглобальных зон. К тому же, пакет не будет установлен во вновь создаваемые зоны.
Управлять патчами немного легче. При запуске утилит patchadd или patchrm из глобальной зоны, изменения подействуют на все зоны. Но при запуске этих команд в неглобальной зоне изменения вступят в силу только в той зоне, откуда производился запуск команд.
Остается сделать одну поправку касательно управления пакетами и патчами из неглобальных зон. При запуске утилит управления пакетом или патчем из неглобальной зоны операция пройдет успешно только в том случае, если на пакеты/патчи, уже используемые глобальной и неглобальными зонами, изменения не повлияют.
зона apache
Для наглядности использования зон я создам неглобальную зону, назову ее "webserver", служить она будет для хостинга apache 2.0.52. Для построения этой зоны я буду придерживаться следующих стратегий для построения этой зоны: сервер apache будет собран и установлен из глобальной зоны. Содержание веб-сервера будет также храниться в глобальной зоне. Код дерева и содержание apache будет совместно использоваться из глобальной зоны неглобальной зоной через смонтированное кольцевое соединение с доступом «только чтение» (read-only loop back). Это даст следующее преимущество: веб-контент будет защищен от изменений процессами из неглобальной зоны.
Первый шаг в сборке сервера apache. В глобальной зоне я создал раздел /web. Устанавливать apache я буду в /web/apache2. Вот последовательность команд для сборки и инсталляции сервера:
# cd /tmp
# gunzip -c httpd-2.0.52.tar.gz | tar xf -
# cd httpd-2.0.52
# ./configure --prefix=/web/apache2
# make
# make install
В глобальной зоне я также создам группу httpd для владения установкой apache:
# groupadd -g 99 httpd
# chmod -R root:httpd /web
# chmod -R 750 /web
По умолчанию apache будет писать логи и pid-файлы в свою установочную директорию. Вследствие того, что неглобальная зона подмонтирует директорию /web в режиме «только чтение», наш сервер не сможет записать какие-либо файлы в /web. Директивы PidFile, Lockfile, ErrorLog, и CustomLog в конфиге apache (/web/apache2/conf/httpd.conf) должны быть изменены и направлены в место, доступное для записи неглобальной зоной:
PidFile /var/run/httpd.pid
LockFile /var/run/accept.lock
ErrorLog /var/log/apache_error_log
CustomLog /var/log/apache_access_log
В целях безопасности я возложу работу apache на отдельный, непривилегированный акаунт. Для этого с момента запуска зоны я создам пользователя и группу httpd. Между тем, я исправлю файл конфигурации apache и укажу в директивах User и Group акаунт httpd:
User httpd
Group httpd
Установка apache завершена, и сейчас я создам неглобальную зону. Процесс настройки в принципе такой же, как было показано выше. В данном случае имя зоны - webserver, root-директория - /zone/webserver, IP-адрес - 192.168.1.12. Кроме того, для совместного использования директории /web глобальной и неглобальной зонами, я буду использовать команду add inherit-pkg-dir:
# zonecfg -z webserver
webserver: No such zone configured Use 'create' to begin
configuring a new zone.
zonecfg:webserver>create
zonecfg:webserver>set zonepath=/zone/webserver
zonecfg:webserver>set autoboot=true
zonecfg:webserver>add net
zonecfg:webserver:net>set address=192.168.1.12
zonecfg:webserver:net>set physical=pcn0
zonecfg:webserver:net>end
zonecfg:webserver>add inherit-pkg-dir
zonecfg:webserver:inherit-pkg-dir>set dir=/web
zonecfg:webserver:inherit-pkg-dir>end
zonecfg:webserver>info
zonepath: /zone/webserver
autoboot: true
pool:
inherit-pkg-dir:
dir: /lib
inherit-pkg-dir:
dir: /platform
inherit-pkg-dir:
dir: /sbin
inherit-pkg-dir:
dir: /usr
inherit-pkg-dir:
dir: /web
net:
address: 192.168.1.12
physical: pcn0
zonecfg:webserver>verify
zonecfg:webserver>commit
zonecfg:webserver>exit
Итак, зона настроена. Сейчас я проинсталлирую и загружу ее, как описано раннее в примере. После запуска зоны я создаю пользователя и группу httpd:
# groupadd -g 99 httpd
# useradd -d /www/apache2 -u 99 -g httpd httpd
Заметьте, что я использую тот же gid для группы httpd в неглобальной зоне, какой и в глобальной зоне. Это гарантирует, что группа httpd в неглобальной зоне будет иметь доступ к файлам директории /web/apache2, владеет которой группа httpd в глобальной зоне.
Наконец, я создаю стартовый скрипт rc для apache в неглобальной зоне, с именем /etc/init.d/apache_2_0_52 со следующим содержанием:
#! /bin/sh
APACHECTL=/web/apache2/bin/apachectl
case "$1" in
start) $APACHECTL start
;;
restart) $APACHECTL restart
;;
stop) $APACHECTL stop
;;
*) echo "usage: $0 start|restart|stop"
;;
esac
Следующие команды инсталлируют стартовый скрипт rc:
# chmod 744 /etc/init.d/apache_2_0_52
# ln /etc/init.d/apache_2_0_52 /etc/rc3.d/S99apache
Теперь сервер apache готов к запуску из неглобальной зоны. Эта конфигурация представляет один из возможных способов сборки неглобальной зоны для хостинга apache.
заключение
Будучи определенно полезным для изоляции приложений, использование зон не избавляет от необходимости улучшения безопасности систем и приложений. Использование зон снижает вероятность атакующего перехватить контроль над всей системой, которую будет эмитировать неглобальная зона. Даже если вы используете зоны, вам захочется усилить безопасность как глобальной, так и неглобальных зон, используя лучшие наработки, доступные в Центре Интернет Безопасности (The Center for Internet Security, cisecurity.org).
Некоторые другие функции зон не были рассмотрены в этой статье. Например, возможность устанавливать лимиты на использование системных ресурсов (ЦПУ и память) зонами. Дополнительную информацию можно найти в документации Sun.
Kevin Wenchel, перевод Войновича Андрея.
Сетевые решения. Статья была опубликована в номере 06 за 2005 год в рубрике sysadmin
