Руководство пользователя Xen v3.0 Часть 2

Продолжение статьи Руководство пользователя Xen v3.0 Часть 1

Поддержка virtual Trusted Platform Module (vTPM)Поддержка virtual Trusted Platform Module (vTPM)

Паравиртуализированным доменам можно предоставить доступ к виртуализированной версии TPM. Это даёт возможность приложениям в этих доменах использовать TPM-устройства, например, через TSS-стек Trousers TSS stack . В репозитории Xen есть все необходимые компоненты для обеспечения доступа к TPM. Поддержка выполняется за счёт нескольких вещей. Во-первых, модифицирован эмулятор TPM, для того чтобы он мог обеспечивать функциональность TPM для подсистемы виртуального TPM. Во-вторых, создан менеджер виртуального TPM, для того чтобы он мог координировать действия виртуальных TPM, управлять их созданием и provides protected key storage using the TPM. В-третьих, есть пара драйверов для XenLinux, представляющих TPM frontend и TPM backend. Драйверы нужны для передачи TPM-команд от домена менеджеру виртуального TPM, который отправляет их дальше программному TPM. Поскольку TPM Manager полагается на HW TPM для protected key storage, поэтому нужен аппаратный TPM, поддерживаемый Linux. Для разработчиков доступен эмулятор TPM, который можно использовать на платформах без аппаратной поддержки TPM.

Установка на этапе компиляции

Для включения доступа к virtual TPM, драйвер backend’а virtual TPM должен быть вкомпилирован в привилегированный домен (домен 0). В XenLinux необходимый драйвер можно выбрать в конфигурационной секции Xen. За исключением случая, когда драйвер вкомпилирован в ядро, для того чтобы активировать модуль необходимо дать следующую команду:

# modprobe tpmbk

Аналогичным образом, для поддержки функциональности TPM нужно вкомпилировать в ядро драйвер TPM fontend. Драйвер можно выбрать при конфигурировании ядра в меню Device Driver / Character Devices / TPM Devices. Вместе с этим драйвером нужно выбрать и TPM driver for the built-in TPM. Если драйвер виртуального TPM был скомпилирован как модуль, его нужно активировать с помощью команды:

# modprobe tpm_xenu

Далее, нужно откомпилировать менеджер виртуального TPM и программный TPM. Для этого нужно внести изменения в конфигурацию сборки Xen. Нужно сдобавить следующую сторку в файл Config.mk в корневом каталоге дистрибутива Xen:

VTPM_TOOLS ?= y

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

# vtpm_managerd# vtpm_migratord

Как только VTPM менеджер работает, получить доступ к нему можно, загрузив драйвер в гостевой домен.
Разработка и тестирование эмулятора TPM
Для разработки и тестирования платформ без поддержки TPM, в качестве замены платформы TPM можно использовать эмулятор TPM.
Во-первых, запись в файле tools/vtpm/Rules.mk должна выглядеть следующим образом:

BUILD_EMULATOR = y

Во-вторых, запись в файле tool/vtpm_manager/Rules.mk должна быть раскомментирована:

# TCS talks to fifo's rather than /dev/tpm. TPM Emulator assumed on fifosCFLAGS += -DDUMMY_TPM

Перед запуском менеджера virtual TPM, необходимо запустить эмулятор в домене dom0 с помощью такой команды:

# tpm_emulator clear

Конфигурирование vTPM Frontend’а
Для предоставления функциональности TPM домену пользователя, нужно добавить в конфигурационный файл виртуального TPM строку в следующем формате:

vtpm = ['instance=<instance number>, backend=<domain id>']

Параметр instance number это номер предпочитаемого виртуального TPM, который должен быть ассоциирован с доменом. Если указанный экземпляр уже ассоциирован с другим доменом, система автоматически выберет следующий доступный экземпляр. Обязательно должен быть указан номер экземпляра больший чем 0. Можно вообще не указывать параметр instance в конфигурационном файле.

Параметр domain id — идентификатор домена, в котором работает драйвер backend’а виртуального TPM и сам TPM. В настоящий момент он всегда должен устанавливаться равным нулю.

Примеры записей vtpm в конфигурационном файле:

vtpm = ['instance=1, backend=0']

и

vtpm = ['backend=0'].

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

Доступ к функциональности TPM обеспечивается fontend-драйвером виртуального TPM. Этот драйвер предоставляет базовую информацию о состоянии TPM через файловую систему sysfs, точно так же как это делают существующие драйверы аппаратных TPM. В пользовательских доменах Xen эти записи sysfs можно найти в /sys/devices/xen/vtpm-0.
Отправлять команды virtual TPM можно с помощью символьного устройства /dev/tpm0 (major 10, minor 224).

Управление хранилищами и файловыми системами

Дисковые хранилища для виртуальных машин можно сделать по-разному. В этой главе рассматриваются некоторые возможные конфигурации.
Наиболее простой и прямой способ это экспортировать физическое блочное устройство (жесткий диск или раздел) из домена 0 в гостевой домен как виртуальное блочное устройство (Virtual Block Device, VBD).
Хранилище может быть также экспортировано из файла-образа файловой системы, как основанное на файле устройство (file-backed VBD).
Кроме того, для предоставления хранилищ виртуальным машинам могут использоваться стандартные сетевые протоколы, такие как NBD, iSCSI и NFS.

Экспорт физических устройств как VBD

Одна из самых простых конфигураций — напрямую экспортировать отдельные дисковые разделы из домена 0 в другие домены. Для это используется ключевое слово phy: в конфигурационном файле домена. Например:

disk = ['phy:hda3,sda1,w'] 

Эта строка указывает, что раздел /dev/hda3 домена 0 должен быть экспортирован в режиме чтение/запись в новый домен как /dev/sda1. С таким же успехом при желании можно было экспортировать его как /dev/hda или /dev/sdb5.

Помимо дисков и разделов можно экспортировать любые другие устройства, к которым Linux относится как к дискам. Например, если у вас есть диск iSCSI или том GNBD импортированный в домен 0, можно экспортировать его с помощью того же синтаксиса phy:. Например:

disk = ['phy:vg/lvm1,sda2,w'] 

Если блочное устройство используется совместно несколькими доменами, то это должно быть в режиме только-для-чтения, иначе модуль файловой системы ядра Linux может очень удивиться, когда увидит, что структура файловой системы, с которой он работает, не соответствует его ожиданиям (если один и тот же раздел дисковой системы, отформатированный под ext3, смонтировать в режиме чтение/запись дважды, почти наверняка это приведёт к непоправимым последствиям). Демон Xend пытается защитить вас от такой ошибки, проверяя не смонтирована ли уже какая-то файловая система в режиме чтение/запись или в самом домене 0, или в гостевых доменах. Если требуется разделение в режиме чтение/запись, нужно или экспортировать соответствующий каталог через NFS из домена 0 или использовать кластерные файловые системы, такие как GFS или ocfs2.

Использование виртуальных блочных устройств основанных на файлах

В качестве основного хранилища для виртуальной машины можно использовать файл в домене 0. Это удобно, а кроме того виртуальное блочное устройство может быть разряжённым — пространство будет действительно выделяться, только по мере использования файла. Если виртуальная машина использует, скажем, половину своего дискового пространства, тогда файл займёт только половину заданного размера.
Например, для того чтобы создать разрежённое файловое устройство размером 2GB (в действительности потребляет только 1 KByte дискового пространства):

# dd if=/dev/zero of=vm1disk bs=1k seek=2048k count=1 

Создайте в файле файловую систему:

# mkfs -t ext3 vm1disk 

(в ответ на вопрос о подтверждении введите y)
Наполните файловую систему, например, путём копирования из корневого каталога.

# mount -o loop vm1disk /mnt# cp -ax /{root,dev,var,etc,usr,bin,sbin,lib} /mnt# mkdir /mnt/{proc,sys,home,tmp}

Нужно доделать систему: отредактировать файл /etc/fstab, /etc/hostname. Нужно редактировать файлы на смонтированной новой файловой системе, а не на старой из домена 0, поэтому пути будут такими: /mnt/etc/fstab вместо /etc/fstab. Для нашего примера в fstab должна появится запись /dev/sda1 для корневого раздела.
После этого размонтируйте (это важно):

Читайте также:  Как в Linux разрешить права доступа к папке?

# umount /mnt 

В конфигурационном файле нужно установить:

disk = ['tap:aio:/full/path/to/vm1disk,sda1,w'] 

По мере того как виртуальная машина будет писать на свой диск, разреженный файл будет наполяться и потреблять больше места, вплоть до заданных 2GB.
Замечание: Пользователям, которые работали с базирующимися на файлах виртуальными блочными устройствами в Xen предыдущих версий, будет интересно узнать, что сейчас поддержка этой функции выполняется с помощью драйвера blktap вместо loopback как раньше. В результате этих изменений файловые устройства стали более производительными, масштабируемыми и более надежными для хранения данных виртуальных блочных устройств. Для того чтобы использовать blktap вместо loop, достаточно изменить записи в конфигурационных файлах, с таких:

disk = ['file:/full/path/to/vm1disk,sda1,w'] 

на такие:

disk = ['tap:aio:/full/path/to/vm1disk,sda1,w'] 

Файловые виртуальные блочные устройства, работающие через loopback (устарело)
Замечание: Как сказано выше, виртуальные блочные устройства, монтирующиеся через VBD заменены устройствами, базирующими на blktap. В этом разделе приводится информация, которая может быть полезна при чтении конфигурационных файлов Xen более старых версий.
Файл с образом для виртуального блочного устройства можно подключить к виртуальной машине с помощью драйвера loopback в Linux. Единственное отличие от директив конфигурационного файла, описанных выше, в том что нужно указывать ключевое слово file:

disk = ['file:/full/path/to/vm1disk,sda1,w'] 

Следует иметь в виду, что виртуальные блочные устройства, работающие через loopback, могут не подойти для использования в доменах с интенсивным вводом/выводом. При таком подходе возможны существенные потери производительности при больших величинах потоков ввода/вывода, связанные с тем как loopback-устройства обрабатывают ввод/вывод. Поддержка loopback-устройств оставлена для совместимости со старыми инсталляциями Xen; новым пользователям настоятельно рекомендуется использовать поддержку устройств, базирующихся на blktap (используя »tap:aio» как показано выше).
И ещё, Linux по умолчанию поддерживает только максимум 8 работающих через loopback блочных устройств для всех доменов вместе взятых. Этот предел можно статически увеличить параметром max_loop для модуля loop, при условии, что модуль скомпилирован отдельно от ядра (CONFIG_BLK_DEV_LOOP=M) или с помощью опции max_loop переданной непосредственно ядру при загрузке, в том случае, если модуль вкомпилирован в ядро (CONFIG_BLK_DEV_LOOP=Y). И здесь также пользователю рекомендуется использовать blktap, поскольку он масштабируется до намного большего количества активных VBD.
Использование виртуальных блочных устройств основанных на томах LVM
Особо привлекательной выглядит возможность хранения файловых систем домена на томах LVM, поскольку с их помощью можно легко увеличивать/уменьшать размеры томов, создавать снимки файловых систем (filesystem snapshots) и делать другие полезные вещи.
Для того чтобы иницииализировать поддержку LVM-томов дисковым разделом, нужно сделать с ним следующее:

# pvcreate /dev/sda10

Создайте группу томов (volume group), названную vg на физическом разделе (точнее, создайте группу томов, в которую будет входить физический том, созданный на предыдущем шаге):

# vgcreate vg /dev/sda10

Создайте догический том размером 4G, названный «myvmdisk1»:

# lvcreate -L4096M -n myvmdisk1 vg

Появится устройство /dev/vg/myvmdisk1. Создайте файловую систему, смонтируйте её и заполните нужными файлами, например так:

# mkfs -t ext3 /dev/vg/myvmdisk1# mount /dev/vg/myvmdisk1 /mnt# cp -ax / /mnt# umount /mnt

После этого измените конфигурацию виртуальной машины:

disk = [ 'phy:vg/myvmdisk1,sda1,w' ]

LVM позволяет увеличивать размер логических томов, но нужно ещё изменить размер и соответствующей файловой системы, для того чтобы можно было использовать новое пространство. Некоторые файловые системы (например, ext3) уже поддерживают изменения размеров в горячем режиме. Подробности можно найти в документации по LVM.
Кроме этого можно использовать LVM для создания copy-on-write (CoW) клонов томов LVM (в терминологии LVM известные также как зaписываемые постоянные снимки, writeable persitent snapshots). Это средство появилось в Linux 2.6.8, и оно ещё не стало достаточно стабильным и зрелым. В частности, использование большого количества LVM-дисков требует много памяти домена 0, а также обработка ошибочных условий, таких как переполнение диска, выполняется не очень хорошо. Есть надежда, что ситуация изменится в будущем.
Создать два клона copy-on-write вышеуказанных файловых систем можно с помощью следующих команд:

# lvcreate -s -L1024M -n myclonedisk1 /dev/vg/myvmdisk1# lvcreate -s -L1024M -n myclonedisk2 /dev/vg/myvmdisk1

Каждый из них может увеличиваться до тех пор пока не наберётся 1G отличий от основного тома. Увеличить величину пространства для хранения отличий можно с помощью команду lvextend, например:

# lvextend +100M /dev/vg/myclonedisk1

Нельзя позволять томам разницы заполняться, иначе LVM начинает сбиваться. Можно автоматизировать процесс расширения с помощью программы dmsetup, котороя наблюдает за томом, и как только он заполняется — вызывает программу lvextend с целью его расширения.
В принципе, можно продолжать запись на том, который был склонирован (изменения не будет видны клонам), но это не рекомендуется: пусть лучше этот том будет нетронутым, и пусть он не монтируется ни одной из виртуальных машин.

Использование корневой файловой системы NFS
Сначала нужно наполнить каталог сервера, соответствующий корневой файловой системе домена. Сервером может быть выделенная машина или, например, виртуальная машина, работающая на том же узле.

После этого нужно изменить конфигурацию NFS-сервера так чтобы он экспортировал эту файловую систему по сети. Для этого в файл /etc/exports нужно добавить, например, такие строки:

/export/vm1root      1.2.3.4/24 (rw,sync,no_root_squash)

Последнее, нужно сконфигурировать домен для использования корневой файловой системы NFS. В дополнение к обычным переменным нужно установить ещё следующий переменные в конфигурационном файле домена:

root       = '/dev/nfs'nfs_server = '2.3.4.5'       # substitute IP address of servernfs_root   = '/path/to/root' # path to root FS on the server

Домену нужен сетевой доступ во время загрузки, поэтому нужно или статически задать IP-адрес и прочие настройки с помощью переменных ip, netmask, gateway, hostname; или же включить DHCP (dhcp=’dhcp’).

Следует иметь в виду, что NFS в качестве корневой файловой системы в Linux имеет проблемы со стабильностью при больших нагрузках (эта проблема не специфична для Xen), так что такую конфигурацию лучше не использовать для критически важных серверов.

Управление ресурсом процессора

Xen позволяет ассоциировать виртуальные процессоры домена с одним или более процессорами хоста. Это может помочь распределить ресурсы системы между гостевыми средами или сделать более оптимальным использование ресурсов в двухядерных процессорах и процессорах с гипертредингом (hyperthreading) и другими продвинутыми технологиями.
Xen нумерует процессоры «сначала в глубину». Для многоядерных процессоров с поддержкой гипертрединга сначала будут пронумерованы гипертреды (hyperthreads) в пределах ядра, затем все ядра, а потом гнезда. Например, если в системе два двухъядерных процессора с поддержкой гипертрединга, нумерация будет такой:
+—————————-+——————————-+

|                socket0               |              socket1                       |

|————-+—————+—————-+—————+

|   core0        |     core1        |      core0          |     core1        |

|————-+—————+—————-+—————+

| ht0 ht1       | ht0 ht1         |  ht0 ht1          |      ht0 ht1   +

Читайте также:  Генерация SSL сертификата в Linux

|————-+—————+—————-+—————+

#0    #1      #2      #3      #4      #5      #6      #7
Если привязать несколько виртуальных процессоров, принадлежащих одному домену, к одному и тому же процессору, скорее всего производительность будет низкой.
Если выполняется задача, требующая интенсивного ввода-вывода, чаще всего лучше выделить целиком одни гипертред (или ядро) для домена 0 и назначить остальные домены так, чтобы процессор 0 гостевыми доменами не использовался. Если рабочая нагрузка является преимущественно вычислительной, возможно, стоит назначить процессоры так, чтобы все физические процессоры были доступны для гостевых доменов.

Миграция доменов

Сохранение и восстановление доменов

У администратора Xen есть возможность сохранить текущее состояние на диск домена 0, чтобы затем продолжить его выполнение позже.
Например, сохранить домен VM1 на диск можно командой:

# xm save VM1 VM1.chk

Домен будет остановлен, а его состояние записано в файле VM1.chk.
Для того чтобы продолжить выполнение домена, используется команда restore:

# xm restore VM1.chk

Эта команда восстановит состояние домена и продолжит его выполнение. Домен будет выполняться как и раньше, а к его консоли можно будет подключиться с помощью вышеописанной команды xm console.

Миграция и живая миграция

Миграция используется для перемещения доменов между физическими хостами. Существует две разновидности миграции: обычная и живая. При обычной миграции для перемещения машины она останавливается, содержимое её памяти копируется на другой хост, после чего работа машины возобновляется на новом хосте. При живой миграции выполняются те же действия, только не нужно останавливать работу машины. Во время выполнения живой миграции домен продолжает работать как и обычно и, с точки зрения пользователя, заметить её невозможно.

Для выполнения живой миграции необходимо чтобы обе системы работали под управлением Xen, и в них был запущен xend. На системе, куда переносится домен, должно быть достаточно ресурсов (в частности, памяти) для перенесённого домена. В настоящий момент также требуется чтобы обе системы находились на канальном уровне в одной сети.
В настоящий момет при миграции домена не существует возможности автоматического удалённого доступа к локальным файловым системам. Администратор должен выбрать соответствующее хранилище (SAN, NAS и т.д.) для того чтобы доменная файловая система была доступна на обоих хост-системах. Хороший способ экспортировать том с одной машины на другую — это GNBD. iSCSI может делать похожую работу, но его сложнее настраивать.

Когда мигрирует домен, его MAC и IP адрес мигрируют вместе с ним, поэтому миграция возможна только в пределах одной сети на канальном уровне. Если узел, на который переносится домен, находится в другой сети, нужно настроить туннелирование IP-пакетов на удалённый хост.

Миграция выполняется с помощью команды xm migrate. Для того чтобы выполнить живую миграцию на другую машину, нужно использовать команду:

# xm migrate --live mydomain destination.ournetwork.com

Без ключа —live xend просто останавливает домен, копирует его образ по сети и запускает его заново. Поскольку у домена может быть большой объём памяти, перенос может потребовать достаточно много времени даже в гигабитной сети. С ключом —live xend пытается перенести домен в работающем состоянии. Простои при переносе составляют время порядка 60-300 мс.

Сейчас пока нужно соединяться заново с консолью домена на новой машине с помощью команды xm console. Если у мигрирированного домена были какие-то сетевые соединения, они сохранятся, поэтому SSH соединения не имеют указанного ограничения.

Безопасность Xen

В этой главе рассматривается как повысить безопасность Xen-системы. Описан ряд сценариев и хороших примеров. Начинается глава разделом, который посвящён общим вопросам безопасности Xen.

Рекомендации по безопасности Xen

При внедрении Xen системы нужно быть уверенным, что домен 0 находится в максимальной безопасности. Если взломан управляющий домен, все остальные домены автоматически оказываются под угрозой. Рекомендации для домена 0:

Запускать как можно меньшее число сервисов, ничего лишнего. Чем меньше вещей присутствует в управляющем домене, тем лучше.Использовать брандмауэр для ограничения трафика к управляющему домену. Брандмауэр с правилами по умолчанию настроенными на запрет поможет предотвратить атаки на управляющий домен.Не допускать пользователей к домену 0. Известно, что существуют локальные эксплоиты для ядра Linux, позволяющие получить права root’а. Если у обычных (даже не обязательно привилегированных) пользователей есть возможность работать внутри домена 0, из-за локальных эксплоитов ядра существует риск для всех доменов системы.

Драйверные домены и безопасность

Драйверные домены используются для решения проблем с безопасностью, связанных с использованием драйверов устройств. Во многих операционных системах в настоящее время драйверы работают в пространстве ядра, с тем же уровнем привилегий, что и само ядро. Механизмов, которые могли бы защитить ядро от неверно ведущего себя (читай «глючного») или злонамеренного драйвера, мало, или они вообще отсутствуют. Драйверные домены нужны чтобы помочь изолировать драйвер устройства внутри собственной виртуальной машины, где он не может повлиять на стабильность и целостность других доменов. Если драйвер начинает сбоить, вместо того чтобы перезагружать всю систему, можно перезагрузить только драйверный домен. Драйверы, написанные третьими лицами, не обладающими достаточным уровнем доверия, можно изолировать от других. Драйверные домены решают часть проблем безопасности и стабильности, связанных с драйверами устройств.

Однако, из-за ограничения существующего оборудования, при использовании драйверных доменов нужно иметь в виду несколько вещей (этот список не полный):

  1. Без IOMMU оборудование может выполнять прямое обращение к памяти (DMA) к областям памяти за пределами управляющего домена. Уязвимыми являются архитектуры, у которых нет модуля IOMMU, позволяющего ограничивать использование DMA (т.е. большинство x86-платформ). Устройство, которое может читать и изменять произвольные участки памяти, может читать и писать данные, находящиеся за пределами своего домена. Злонамеренный или работающий с ошибками домен может использовать подконтрольное ему устройство для записи или чтения данных в произвольных местах памяти другого домена.
  2. Разделяемые шины могут прослушиваться. Устройства, использующие совместно шину данных, могут прослушивать (или даже подменять) данные друг друга. Устройство A, назначенное домену A, может прослушивать данные, которые домен B передаёт устройству B, и передавать их домену A.
  3. Устройства, которые используют линии прерываний совместно с другими, могут при желании или помешать получению прерываний другим устройствам, или, наоборот, генерировать бесполезные прерывания.Устройства, совместно использующие level-triggered прерывания (например, PCI устройства) могут вызывать прерывания и никогда их не сбрасывать. Это блокирует для других устройств, которые используют эту же линию прерывания, возможность передачи сигнала о необходимости обслуживания своим управляющим драйверам. Устройства, использующие совместно линии прерываний любого типа, могут постоянно вызывать прерывания, что приведёт (причём в нескольких гостевых системах) к необходимости вызова процедур обработки прерываний (что потенциально может привести к тому, что другие процессы внутри соответствующего гостевого домена вообще не получат управления). Архитектура, в которой у каждого устройства может быть своя собственная линия прерываний (например, Message Signaled Interrupts шины PCI), подвержена этой проблеме в меньшей степени.
  4. Устройства могут совместно использовать адресное пространство ввода/вывода. Xen может ограничивать доступ к устройствам ввода/вывода только с определённым уровнем гранулярности. Для линий прерываний и портов ввода/вывода уровень гранулярности очень высокий (с точностью до одной линии или одного порта). Однако, что касается адресного пространства ввода/вывода, ограничение может выполняться только по границам страниц. Если несколько устройств совместно используют страницу в пространстве ввода/вывода, домены, которым принадлежат эти устройства, будут иметь возможность доступа к адресному пространству устройств друг друга.
Читайте также:  Подавляем stdout и stderr в Linux

Сценарии

Изолированная управляющая сеть

В этом сценарии у каждого узла есть две сетевые карты. Одна из них выходит во внешний мир, а вторая — в физически изолированную управляющую сеть, предназначенную специально для Xen.
До тех пор пока все управляемые части имеют одинаковый уровень доверия, это наиболее безопасный сценарий. Никакой дополнительной конфигурации он не тербует, за исключением того, что Xend для перемещения должен быть привязан к управляющему интерфейсу.

Подсеть за брандмауэром

В этом сценарии у каждого узла есть только одна сетевая карта, но весь кластер находится за брандмауэром. В этом случае брандмауэр должен делать как минимум следующее:
Предотвращать IP-spoofing снаружи сети.Предотвращать доступ к порту перемещения (relocation) на всех узлах для всех, кроме самого кластра. Такие правила можно использовать на каждом узле для запрета миграции снаружи сети, если главный брандмауэр не выполняет запрет:

# эта команда закрыват любой доступ к порту

# перемещения (relocation) Xen

iptables -A INPUT -p tcp --destination-port 8002 -j REJECT

# этак команда разрешает перемещение (relocation) 

# только из определенной подсети

iptables -I INPUT -p tcp --source 192.168.1.1/8 \    --destination-port 8002 -j ACCEPT

Узлы в небезопасных сетях

В текущих версиях Xen миграция в небезопасных сетях также является небезопасной. Можно выполнять миграцию поверх безопасных туннелей VPN и SSH. Единственный безопасный вариант (за исключением туннелей) это отключение миграции как таковой. Проще всего это сделать с помощью iptables:

# эта команда закрыват любой доступ к порту

# перемещения (relocation) Xen

iptables -A INPUT -p tcp --destination-port 8002 -j REJECT

Управление доступом sHype/Xen

Framework принудительного контроля доступа (mandatory access control) это реализация sHype Hypervisor Security Architecture (www.research.ibm.com/ssd_shype). Она разрешает или запрещает обмен информацией и доступ к ресурсам на основе политики безопасности. Механизмы принудительного контроля доступа дополняют основные механизмы управления Xen, такие как механизмы защиты памяти. Они спроектированы таким образом, чтобы быть незаметными в ходе нормальной работы домена (policy-conform behavior), но в случае выхода домена за границы допустимого поведения быть готовыми вмешаться и ограничить его. В этой главе описывается как с помощью механизмов контроля доступа в Xen предотвратить распространение вирусов между доменами и утечку информации из одних нагрузок в другие. sHype/Xen зависит от правильного поведения домена 0.

Преимущества sHype/ACM в Xen:

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

Эти преимущества являются чрезвычайно ценными, поскольку нынешние операционные системы стали очень сложными, и в них часто не хватает механизмов принудительного контроля доступа (механизмы дискреционного контроля доступа, поддерживаемые в большинстве операционных систем, недостаточно эффективны против вирусов и неверно ведущих себя программ). Там где принудительный контроль доступа существует (например, SELinux), он обычно сопряжён со сложными и трудными для понимания политиками безопасности. Кроме того, в многоуровневых приложения для бизнес-сред обычно требуется совместная работа нескольких операционных систем (например, AIX, Windows, Linux), которые нельзя сконфигурировать так чтобы они использовали совместимые политики безопасности. Связанные распределённые транзакции и нагрузки нельзя простым способом защитить на уровне операционной системы. Framework контроля доступа Xen предлагает хотя и крупноблочный, но достаточно зрелый уровень безопасности в том случае если безопасность на уровне операционной системы отсуствует или недостаточная.

Чтобы контролировать совместное использование ресурсов доменами, Xen регулирует как междоменное взаимодействие (разделяемая память, события), так и обращение доменов к дискам. Так, Xen может держать в заданных рамках распределённые нагрузки, позволяя совместное использование ресурсов доменам выполняющим нагрузку одного типа и запрещая его для доменов выполняющих нагрузку разных типов. Будем исходить из предположения, что с точки зрения Xen только один тип нагрузки работает в одном пользовательском домене. Чтобы Xen мог ассоциировать домены и ресурсы с типами нагрузок, к доменам и ресурсам прикрепляются метки безопасности (включая типы нагрузок). Эти метки и sHype-контроль гипервизора нельзя обойти, и они являются эффективными даже против злонамеренных доменов.

Обзор

В этом разделе проводится обзор того как framework принудительного контроля доступа sHype может выполнять защиту нагрузок в Xen. На рисунке показаны необходимые для активации защиты нагрузок в Xen. Эти шаги подробно описаны здесь.

Обзор процесса активации защиты нагрузок sHype в Xen

Во-первых, средство управления доступом sHype/ACM должно быть собрано и проинсталлировано. Во-вторых, для того чтобы включать политику безопасности Xen, она сначала должна быть создана и внедрена. Политика определяет различные виды нагрузок, по которым делаются разграничения в ходе управления доступом. Кроме этого, она определяет различные правила, которые сравнивают типы нагрузок доменов и ресурсов и, основываясь на этом, принимают решение о разрешении или запрете доступа. Типы нагрузок представлены метками безопасности, которые могут прикрепляться к доменам и ресурсам. Защита sHype/Xen в действии продемонстрирована на простом примере. В этом разделе детально описывается синтаксис и семантика политики безопасности sHype/Xen, а также делается небольшое введение в использование программ, предназначенных для создания политик безопасности.

В следующем разделе описываются все шаги, необходимые для того чтобы создать, внедрить и проверить простую политику защиты нагрузки. С их помощью можно быстро попробовать механизм защиты нагрузки sHype/Xen. Те, кто хочет узнать больше о том, как работает контроль доступа sHype в Xen и как его настроить с помощью XML-политики безопасности, должны прочитать этот раздел. Этот раздел завершает главу обзором существующих ограничений реализации sHype в Xen.
Пошаговое руководство по защите нагрузок Xen

Процедура состоит из следующих шагов:

  • сконфигурировать и проинсталлировать sHype/Xen;
  • создать простую политику безопасности защиты нагрузки;
  • внедрить политику безопасности sHype/Xen;
  • ассоциировать домены и ресурсы с метками нагрузок;
  • проверить как выполняется защита нагрузок.

Важные команды, необходимые для создания и внедрения политики безопасности sHype/Xen, встречающиеся в следующих разделах, пронумерованы. Если вам понадобится быстрое руководство, или надо будет на скорую руку выполнить те действия, которые здесь описываются, просто ищите пронумерованные команды и применяйте их в соответствующем порядке.

Включение поддержки sHype в Xen

Прежде всего нужно настроить модуль контроля доступа в Xen и проинсталлировать гипервизор с поддержкой ACM. На этом шаге устанавливаются инструменты безопасности и sHype/ACM вкомпилируется в гипервизор.

Для того чтобы включить поддержку sHype/ACM в Xen, нужно отредактировать файл Config.mk в корневом каталоге дистрибутива Xen.

(1) In Config.mkChange: ACM_SECURITY ?= nTo: ACM_SECURITY ?= y

После этого нужно проинсталлировать Xen обычным способом:

(2) # make world# make install

Взято тут

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *