Ключевые слова:solaris, chroot, virtual, zone, (найти похожие документы)
From: Войнович Андрей <dukenuk@mail.ru.>
Date: Wed, 2 Aug 2007 18:21:07 +0000 (UTC)
Subject: Зонная Защита Solaris 10
Оригинал: http://www.securitylab.ru/54881.html
Автор Kevin Wenchel, перевод Войновича Андрея
Зонная технология это новый компонент Solaris 10 N1 Grid Computing
Environment. Зоны позволяют системным администраторам разделить ОС
Solaris на несколько виртуальных составляющих ОС, которые полностью
изолированы друг от друга и даже не взаимодействуют. В отличие от ПО
виртуальных машин, например VMWare, которые создают виртуальное
железо, чтобы позволить составным ОС запускаться независимо на одной
реальной машине, зоны Solaris позволяют создать виртуальную среду
самого Solaris. Это позволяет нескольким частям среды Solaris
запускаться в пределах одного ядра OS.
Зонная технология имеет много практических применений в управлении
системными ресурсами и безопасностью. В этой статье я покажу
достоинства зон в системной безопасности, а также основные процедуры,
используемые для конфигурирования и управления зонами, практическую
демонстрацию зонной технологии для изоляции содержания Apache Web
сервера. Хотя эта статья и рассматривает зоны с точки зрения
безопасности, информация, приведенная в описании настройки и
управления в основном приемлема для использования зон в любых целях.
Создание Виртуальной Среды и Безопасность
Основной целью при установке сетевого приложения безопасности на
сервер считается снижение вероятности ущерба, если атакующий узнает
это приложение. Представьте ситуацию, когда атакующий использует
уязвимость в Web сервере, например Apache, чтобы получить локальный
доступ к серверу. Теперь атакующий потенциально может копаться на
сервере в поиске локальных уязвимостей для поднятия своих привилегий.
При успехе атакующий может контролировать весь сервер и все данные и
приложения, хостящиеся на нем.
В среде Unix часто используют утилиту chroot(1M), позволяющую
изолировать сетевое приложение от других ресурсов системы. Chroot дает
возможность системному администратору закрыть процесс и все вызванные
им другие процессы в <<виртуальную>> файловую систему. Chroot'анный
процесс назначается root'овой директорией, связанной с настоящим
системным root, и защищен от доступа к файлам, расположенным вне.
Чтобы провести chroot какому-либо приложению, вам понадобятся все
файлы (библиотеки, бинарники, файлы конфигурации), используемые
приложением, которые должны быть продублированы в chroot директории.
Иногда это может оказаться сложной задачей.
Следует добавить, что хоть chroot и предотвращает попытки приложения
обращаться к файловой системе, сами chroot'анные процессы не
изолированы от других ресурсов и процессов в системе. Т.е. процесс
chroot все еще может наблюдать и взаимодействовать с процессами не из
chroot. К тому же уже опубликованы методы выхода из среды chroot [1].
Смотрите ссылку:
http://www.bpfh.net/simes/computing/chroot-break.html
Зонная технология Solaris предоставляет собой значительно
усовершенствованный chroot. Использование зон Solaris позволит вам
создавать полностью виртуальную ОС для изолирования процессов как на
уровне файловой системы, так и не уровне процессов сети. Проще говоря,
в Solaris 10, каждая система содержит одну зону, известную как
глобальная зона, и неглобальные зоны (их может и не быть). Глобальная
зона на самом деле мало чем отличается от среды настоящего Solaris 10.
Глобальная зона используется для управления реальными устройствами и
администрирования неглобальных зон.
Итак, неглобальная зона это виртуальная среда ОС. Процессы, запущенные
в ней не могут обращаться или взаимодействовать с процессами из других
зон. И даже информация о реальных устройствах, например, имена
локальных дисков, является недоступной для процессов, запущенных в
неглобальных зонах. Если защита неглобальной зоны повреждена, то
другие зоны все равно находятся в безопасности. Кроме того, процессы в
этих зонах работают под разными ограничениями. К примеру, они не могут
осуществлять администрирование оборудования и загружать или выгружать
модули ядра.
Использование зон не избавляет от необходимости обновления
операционных систем и приложений. Если атакующий добивается доступа с
привилегиями root в неглоаблную зону, он сможет убивать процессы и
удалять файлы в пределах зоны, а также перезапускать зону. Как бы то
ни было, атакующий не сможет повредить данные и приложения, запущенные
в других зонах на системе. Также, если зона взломана, прочистку её
после обнаружения вторжения будет осуществить очень легко.
Неглобальные зоны могут быть перезапущены независимо от других зон,
таким образом, зона может быть восстановлена или перестроена без
необходимости выключения всей системы и остановки приложений в других
зонах.
Некоторые разновидности Unix имеют возможности, похожие на зоны
Solaris 10. Например, механизм Jail в FreeBSD [2], впервые появившийся
в FreeBSD 4.0 (релиз 2000 года), предоставляет в принципе такие же
возможности, как и зоны Solaris 10. Смотрите:
http://phk.freebsd.dk/pubs/sane2000-jail.pdf
Также в среде Linux, проект Vserver [3], предлагается ядерный патч и
набор утилит для создания виртуальной среди Linux; Смотрите:
http://linux-vserver.org/Linux-VServer-PaperОсуществление Зон Solaris
Solaris 10 поддерживает до 8,191 неглобальных зон в обычной поставке
Solaris. Каждая неглобальная зона зависима от директории root
глобальной зоны. К счастью, создание неглобальной зоны не требует
дублирования всей операционки Solaris и файлов с библиотеками.
Дублируются только несколько зависимых системных бинарников, плюс
конфигурационные файлы. Большинство системных библиотек и бинарников
используются совместно глобальной и неглобальной зоной. Директории
/lib, /platform, /sbin и /usr доступны из глобальной зоны неглобальным
зонам через кольцевую (loopback) файловую систему c разрешением
<<только чтение>>.
Неглобальной зоне может быть отведено один или несколько реальных
сетевых интерфейсов, доступных в системе. К каждому физическому
интерфейсу привязывается неглобальная зона, виртуальный сетевой
интерфейс и уникальный IP адрес. Процессы неглобальной зоны могут
только отправлять и получать трафик, используя виртуальные сетевые
интерфейсы, привязанные к этой зоне.
Процессы, запущенные в пределах неглобальной зоны, имеют различные
ограничения. Например, нельзя загружать или выгружать модуль ядра из
неглобальной зоны, даже имея root'овые привилегии. Кроме того, эти
процессы не могут использовать интерфейс <<сырых сокетов>> (raw
sockets) для протокола, отличного от ICMP. Запрет на использование
интерфейса сырых сокетов для посылки данных по TCP и UDP предотвращает
возможность посылки ложных IP пакетов (или просто спуфа).
Системные Требования Зоны
В документации Sun [4] (http://docs.sun.com/app/docs/doc/817-1592)
сказано, что необходимое дисковое пространство для неглобальной зоны
зависит от пакетов, установленных в глобальной зоне, и Sun рекомендует
100 МБ для неглобальной зоны, при условии что глобальная зона была
установлена из стандартного пакета (standard Solaris packages).
Моя глобальная зона была установлена из пакета "Entire Distribution
Plus OEM Support", и неглобальные зоны занимали около 85 МБ дискового
пространства. Sun также рекомендует дополнительно 40 МБ RAM для каждой
зоны, как регулярное правило, но это не требование.
В момент написания, релиз Solaris 10 еще не был доступен. Все тесты
проводились на Solaris 10 x86 b63 Beta (датирован 14 Августа 2004
года). Моя тестовая система 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, так root моей зоны будет расположен в /zone/twilight.
С помощью утилиты zonecfg(1M) можно настраивать неглобальные зоны.
Начинается настройка с запуска команды zonecfg с параметром -z. Теперь
можно присвоить имя. После этого zonecfg предоставит интерактивный
диалог в командной строке, из которого вы сможете настроить зону,
используя несколько подкоманд.
После выполнения подкоманды create, присвойте значения параметрам
zonepath и autoboot, используя команду set. zonepath - определение
root'a директории, параметром 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(1M)
используется для инсталляции зоны:
# zoneadm -z twilight install
Preparing to install zone <twilight>.
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 <twilight> is initialized.
The file </zone/twilight/root/var/sadm/system/logs/install_log> \
contains a log of the zone installation.
В процессе инсталляции Solaris помещает копии системных настроек
(/etc/passwd, /etc/group, /etc/default/*, /etc/inet/inetd.conf и др.)
в директорию root неглобальной зоны. Версии файлов, установленных в
неглобальную зону, являются идентичными с версиями файлов только что
установленной ОС. Неглобальная зона не наследует версии этих файлов от
глобальной зоны. Это означает, что любые изменения в настройках
глобальной зоны должны быть продублированы вручную для каждой
созданной неглобальной зоны.
Обычно, установка зоны занимает несколько минут. После окончания
установки, необходимо загрузить зону, выполнив команду zoneadm из
глобальной зоны с параметром boot:
# zoneadm -z twilight boot
После загрузки зоны впервые вам необходимо залогиниться в её консоль и
завершить некоторые базовые установки. Чтобы залогиниться в
неглобальную зону, используйте команду zlogin(1) с параметром -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 Web
server. Для построения этой зоны я буду придерживаться следующих
стратегий для построения этой зоны: сервер Apache будет собран и
установлен из глобальной зоны. Содержание Web сервера будет также
храниться в глобальной зоне. Код дерева и содержание Apache будет
совместно использоваться из глобальной зоны неглобальной зоной через
смонтированное кольцевое соединение с доступом <<только чтение>>
(read-only loop back). Это даст следующее преимущество: Web содержание
будет защищено от изменений процессами из неглобальной зоны.
Первый шаг в сборке сервера 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 Web server в
неглобальной зоне, с именем /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.
Заключение
Будучи определенно полезными для изоляции приложений, использование
зон не избавляет от необходимости улучшения безопасности систем и
приложений. Использование зон снижает вероятность атакующего
перехватить контроль над всей системой, которую будет эмитировать
неглобальная зона. Даже если вы используете зоны, вам захочется
усилить безопасность как глобальной так и неглобальных зон также, как
и Web серверов, используя лучшие наработки, доступные в Центре
Интернет Безопасности (The Center for Internet Security [5]): http://cisecurity.org
Некоторые другие функции зон не были рассмотрены в этой статье.
Например, возможность устанавливать лимиты на использование системных
ресурсов (ЦПУ и память) зонами. Дополнительную информацию можно найти
в документации Sun.
Cсылки
1. "Breaking out of a chroot() padded cell." 23 Nov. 2004 --
http://www.bpfh.net/simes/computing/chroot-break.html
2. Kamp, Poul-Henning, Robert N.M. Watson. "Jails: Confining the
omnipotent root." 18 Nov. 2004 --
http://phk.freebsd.dk/pubs/sane2000-jail.pdf
3. Potzl, Herbert. "Linux-Vserver-Paper." 18 Nov. 2004 --
http://linux-vserver.org/Linux-VServer-Paper
4. "System Administration Guide: N1 Grid Containers, Resource
Management, and Solaris Zones." 18 Nov. 2004 --
http://docs.sun.com/app/docs/doc/817-1592
5. "Center for Internet Security -- Standards." 18 Nov. 2004 --
http://cisecurity.org
