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

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

Создание политики нагрузки в три шага с помощью ezPolicy

Для быстрого создания политик, защищающих нагрузки, мы будем использовать программу ezPolicy. Для запуска этой программы требуются Python и wxPython. Для того чтобы запускать программу из домена Domain0, можно скачать wxPython с сайта www.wxpython.org или воспользоваться командой yum install wxPython в Redhat/Fedora. Если выполнять программу ezPolicy под Windows, также нужно будет скачать пакет Python с сайта www.python.org. После того как все необходимые пакеты установлены, запустите ezPolicy с помощью команды:

  (3) # xensec_ezpolicy

На рисунке показан скриншот программы. Создать политику, показанную на рисунке, можно с помощью таких шагов. Справка доступна в любой момент с помощью комбинации <CTRL>-h. Маркеры (a), (b) и (c) на рисунке указывают на кнопки, которые используются в ход создания политики «в три шага»:

  • описание нагрузки;
  • описание конфликтов;
  • преобразование описания нагрузки в политику sHype/Xen.

Описание нагрузок

Нагрузки определяются для каждой организации и отделения, которое вводится в левую панель. С помощью кнопки »New Org» (a) создайте организации »Avis», »Hertz», »CocaCola» и »PepsiCo».

Можно доработать описание организаций — сделать чтобы нагрузки их различных подразделений различались. Для этого нужно щёлкнуть правой кнопкой мыши на организации и выбрать «Add Department» (или выбрать организацию и нажать Ctrl-A). Создайте подразделения »Intranet», »Extranet», »HumanResources» и »Payroll» для организации »CocaCola» и подразделения »Intranet» и »Extranet» для организации »PepsiCo». Итоговый вид должен быть похожим на левую панель, показанную на рисунке.

Определение конфликтов времени исполнения

Нагрузки, которым нельзя работать одновременно на платформе с одним гипервизором, сгруппированы в »Run-time Exclusion rules» (Правила исключения времени исполнения) на правой панели окна.

Для того чтобы избежать одновременного исполнения нагрузок PepsiCo и CocaCola (включая нагрузки на подразделения) на одном и том же гипервизоре, выберите организацию »PepsiCo», а затем, с нажатой клавишей Ctrl, выберите организацию »CocaCola». Теперь нажмите клавишу (b) с названием »Create run-time exclusion rule from selection» (создать правило исключения времени выполнения основываясь на текущем выделении). Правило появится на правой панели. Имя используется только для удобства и никак не затрагивает политики гипервизора.

Повторите процесс для создания правил исключения времени исполнения для нагрузок отделений CocaCola.Extranet и CocaCola.Payroll.

Итоговый вид окна с описанием нагрузок и правилами исключения времени исполненияИтоговое окна должно быть похоже на то, что показано на рисунке. Нужно сохранить это определение нагрузки, выбрав »Save Workload Definition as …» в меню »File» (c). Впоследствии при необходимости это определение можно будет доработать.

Преобразование определения нагрузки в политику sHype/Xen

Для того чтобы превратить определение нагрузки в политики контроля доступа, понятную Xen, выберите пункт »Save as Xen ACM Security Policy» (сохранить как политику безопасности ACM) в меню »File» (c). Введите следующее имя политики в появившемся окне: example.chwall_ste.test-wld. Если ezPolicy работает в домене 0, итоговый файл политики test-wld_security-policy.xml автоматически попадёт в правильный каталог /etc/xen/acm-security/policies/example/chwall_ste. Если программа запущена не в домене 0, нужно вручную скопировать полученный файл в домен 0, а затем продолжить.

Внедрение политики защиты нагрузки

Для того чтобы внедрить политику, созданную выше, создаётся файл-представление политикии (test-wld.bin), который можно загрузить в гипервизор Xen. Мы именно так и сконфигурируем Xen, чтобы он загружал политику при старте.
Приведённая ниже команда преобразует исходный файл представления политики в файл, который может быть загружен в Xen с поддержкой sHype/ACM. Детали — в man-странице по xm.

  (4) # xm makepolicy example.chwall_ste.test-wld

Самый простой способ инсталлировать политику для Xen — это включить её в загрузочную последовательность. Это делает следующая команда:

(5) # xm cfgbootpolicy example.chwall_ste.test-wld

Как вариант, если команда не сработает (например, из-за того, что она не сможет идентифицировать загрузочную запись Xen), можно вручную, в два шага, установить политику вручную. Во-первых, нужно скопировать бинарный файл политики в каталог /boot/:

# cp /etc/xen/acm-security/policies/example/chwall_ste/test-wld.bin \  /boot/example.chwall_ste.test-wld.bin

Во-вторых, нужно вручную добавить строку загрузки модуля в секцию Xen конфигурационного файла загрузчика GRUB:

 title Xen (2.6.16.13) root (hd0,0) kernel /xen.gz dom0_mem=2000000 console=vga module /vmlinuz-2.6.16.13-xen ro root=/dev/hda3 module /initrd-2.6.16.13-xen.img module /example.chwall_ste.test-wld.bin

Загрузитесь по этой записи, чтобы активировать политику и использовать гипервизор Xen с повышенной безопасностью.

(6) # reboot

После перезагрузки, проверьте, включена ли безопасность:

# xm list --label Name        ID Mem(MiB) VCPUs State  Time(s)  Label Domain-0     0     1949     4 r-----   163.9  SystemManagement

Если метка безопасности в конце строки выглядит как «INACTIV», безопасность не включена. В этом случае нужно убедиться, что предыдущие шаги были выполнены верно. Примечание: Домену Domain0 назначена метка по умолчанию. Остальные домены, должны быть помечены для того чтобы работать с гипервизором поддерживающим sHype/ACM (ниже описывается как ставить метки на домены и ресурсы).

Пометка доменов

Конфигурационный файл домена должен выглядеть как показано ниже. Этот конфигурационный файл описывает домен domain1: (Примечание. Сайты www.jailtime.org и www.xen-get.org это хорошее место, где можно поискать примеры образов domU)

 # cat domain1.xm kernel = "/boot/vmlinuz-2.6.16.13-xen" memory = 128 name = "domain1" vif = [ '' ] dhcp = "dhcp" disk = ['file:/home/xen/dom_fc5/fedora.fc5.img,sda1,w', \ 'file:/home/xen/dom_fc5/fedora.swap,sda2,w'] root = "/dev/sda1 ro"

Если попробовать запустить домен, возникнет следующее сообщение об ошибке:

# xm create domain1.xm Using config file "domain1.xm". domain1: DENIED --> Domain not labeled Checking resources: (skipped) Security configuration prevents domain from starting

Каждый домен, перед тем как быть запущенным на sHype/Xen, должен быть ассоциирован с меткой безопасности. Без этого sHype/Xen не сможет обеспечить целостность политики. Следующая команда показывает все метки доступные в активной политике:

# xm labels type=dom Avis CocaCola CocaCola.Extranet CocaCola.HumanResources CocaCola.Intranet CocaCola.Payroll Hertz PepsiCo PepsiCo.Extranet PepsiCo.Intranet SystemManagement

Теперь domain1 получит метку CocaCola, а домен domain2 — метку PepsiCo.Extranet. Подробности в man xen.

(7) # xm addlabel CocaCola dom domain1.xm      # xm addlabel PepsiCo.Extranet dom domain2.xm

Если попробовать запустить домен снова:

# xm create domain1.xm Using config file "domain1.xm".    file:/home/xen/dom_fc5/fedora.fc5.img: DENIED    --> res:__NULL_LABEL__ (NULL)    --> dom:CocaCola (example.chwall_ste.test-wld)    file:/home/xen/dom_fc5/fedora.swap: DENIED    --> res:__NULL_LABEL__ (NULL)    --> dom:CocaCola (example.chwall_ste.test-wld) Security configuration

prevents domain from starting

Эта ошибка показывает, что domain1, если его запустить, не сможет получить доступ к своему образу и файлу подкачки, поскольку они не имеют соответствующих меток. Это имеет смысл, поскольку для того чтобы ограничить нагрузку, доступ доменов к ресурсам должен контролироваться. В противном случае, домены которым запрещено взаимодействоваать или работать одновременно, могли бы совместно использовать какие-то данные с помощью хранилищ.

Пометка ресурсов

Список доступных меток ресурсов можно посмотреть с помощью команды xm labels.
Назначим метку ресурса CocaCola файлы образу домена domain1, представляющему /dev/sda1, и файлу, представляющему раздел подкачки домена:

  (8) # xm addlabel CocaCola res \           file:/home/xen/dom_fc5/fedora.fc5.img      Resource file not found, creating new file at:      /etc/xen/acm-security/policies/resource_labels      # xm addlabel CocaCola res \           file:/home/xen/dom_fc5/fedora.swap

Запуск домена пройдёт успешно:

# xm create domain1.xm# xm list --labelName           ID Mem(MiB) VCPUs State  Time(s)  Labeldomain1         1      128     1 r-----     2.8  CocaColaDomain-0        0     1949     4 r-----   387.7 

SystemManagement

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

# xm resourcesfile:/home/xen/dom_fc5/fedora.swap policy: example.chwall_ste.test-wld label:  CocaColafile:/home/xen/dom_fc5/fedora.fc5.img policy: example.chwall_ste.test-wld label: 

CocaCola

Сейчас, если помеченный ресурс перемещён в другое место, нужно вручную удалять метку и затем повторно её ставить с помощью команд xm rmlabel и xm addlabel соответственно.
(9) Поставьте метку PepsiCo.Extranet на ресурсы домена domain2.   Пока что, не выполняйте запуск домена.

Проверка защиты нагрузки Xen

Проверить как работает защита нагрузки можно убедившись что:

домены с конфликтующими нагрузками не могут работать одновременно;домен не может получить доступ к ресурсам других нагрузок;домены не могут обмениваться сетевыми пакетами, если они не ассоциированы с нагрузками одного типа.Test 1: Правила исключения времени выполнения
Предположим, что домен domain1 с меткой CocaCola всё ещё работает. Правила исключения времени исполнения нашей политики говорят, что пока домен domain1 работает, домен domain2 не может быть запущен, поскольку метка домена domain1 включает CHWALL тип CocaCola, а метка домена domain2 включает CHWALL тип PepsiCo. Правила исключения времени исполнения говорят, что PepsiCo и CocaCola не могут работать в одно и то же время на платформе одного и того же гипервизора. Как только домен domain1 остановлен или сохранён, можно запускать домен domain2, но теперь нельзя уже восстановить domain1. Программа ezPolicy, когда создаёт Chinese Wall типы для меток нагрузок, гарантирует то, что нагрузки подразделений наследуют типы соответствующих организаций (и вместе с этим исключения организаций).

# xm list --labelName           ID Mem(MiB) VCPUs State  Time(s)  Labeldomain1         2      128     1 -b----     6.9  CocaColaDomain-0        0     1949     4 r-----   273.1  SystemManagement
# xm create domain2.xmUsing config file "domain2.xm".Error: (1, 'Operation not permitted')
# xm destroy domain1# xm create domain2.xmUsing config file "domain2.xm".Started domain domain2
# xm list --labelName           ID Mem(MiB) VCPUs State  Time(s)  Labeldomain2         4      164     1 r-----     4.3  PepsiCo.ExtranetDomain-0        0     1949     4 r-----   298.4  SystemManagement
# xm create domain1.xmUsing config file "domain1.xm".Error: (1, 'Operation not permitted')
# xm destroy domain2# xm listName           ID Mem(MiB) VCPUs State  Time(s)Domain-0        0     1949     4 r-----   391.2

Можно убедиться, что домены с меткой Avis могут работать вместе с доменами помечеными как CocaCola, PepsiCo или Hertz.

Test 2: Доступ к ресурсам

В этом тесте мы поставим на swap-файл домена domain1 ресурсную метку Avis. Домен domain1 больше не сможет даже запуститься, поскольку у него теперь нед доступа к этому ресурсу. Это тест проверяет возможности доменов по совместному доступу, которые описываются в компоненте Simple Type Enforcement.

# xm rmlabel res file:/home/xen/dom_fc5/fedora.swap# xm addlabel Avis res file:/home/xen/dom_fc5/fedora.swap# xm resourcesfile:/home/xen/dom_fc5/fedora.swap    policy: example.chwall_ste.test-wld    label:  Avisfile:/home/xen/dom_fc5/fedora.fc5.img    policy: example.chwall_ste.test-wld    label:  CocaCola
# xm create domain1.xmUsing config file "domain1.xm".   file:/home/xen/dom_fc4/fedora.swap: DENIED   --> res:Avis (example.chwall_ste.test-wld)   --> dom:CocaCola (example.chwall_ste.test-wld)Security configuration prevents domain from starting

Test 3: Обмен информацией

В этом тесте выполняется такая проверка: могут ли два домена с метками Hertz и Avis обмениваться информацией по сети. Проверка делается с помощью ping. Он также имеет отношение к политике STE. Примечание: sHype/Xen не контролирует прямое взаимодействие между доменами. Однако, в настоящее время домены, ассоциированные с разными нагрузками, могут обмениваться информацией через сеть домена 0. Ведётся работа над механизмами управления sHype/ACM для локального и удалённого сетевого трафика. Дополнительная информация об этом может появитсья в списке рассылки xen-devel.

Политика контроля доступа Xen

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

Политика управления доступом Xen состоит из двух компонентов. Первый компонент, называемый политикой Chiness Wall (CHWALL), контролирует какие домены могут работать одновременно на одной виртуализированной платформе. Второй компонент, называемой политикой Simple Type Enfotcement (STE), управляет организацией совместного доступа между доменами, т.е. обменом информацией между ними или доступом к ресурсам. Компоненты CHWALL и STE могут работать по-одиночке, но в нашем примере оба компонента политик сконфигурированы вместе, и они дополняют друг друга. XML файл политики содержит всю информацию необходимую для приведения политик в действие.

В этой политики выделены две нагрузки: CocaCola и PepsiCo, а также определены метки, необходимые для того чтобы ассоциировать домены и ресурсы c этими нагрузками. XML-политика состоит из таких частей:

Заголовок политики, включая её имя;Блок Simple Type Enforcement (простого применения типов);Блок политики Chinese Wall;Блок определения меток.
Пример XML-файла политики безопасности — Часть I: Определение типов и правилЗаголовок и имя политики

Строки 1-2 включают обычный XML-заголовок. Описание политики безопасности начинается со строки 3. Оно соответствует схеме политики. XML-схема для описания политик безопасности может быть найдена в файле /etc/xen/acm-security/policies/security-policy.xsd. В каталоге examples/ c примерами есть примеры политик безопасности. Каталог acm-security/ единственный из проинсталлированных, в том случае, если безопасность ACM сконфигурирована в процессе инсталляции.

Заголовок политики покрывает строки 4-7. Он включает поле даты и определяет имя политики example.chwall_ste.test. Также он может включать необязательные поля, которые не показаны здесь, и которые предназначаются для будущего использования (см. описание схемы).

Имя политики нужно для двух вещей. Во-первых, оно собственно задаёт уникальное имя для политики безопасности. Это имя экспортируется гипервизором в управляющие утилиты Xen для того чтобы быть уверенным, что во всех случаях речь идёт об одном и том же. Планируется расширение имени политики цифровым отпечатком содержимого политики для лучшей защиты связи имени и содержимого. Во-вторых, оно неявно указывает утилите xm местоположение, где в системе хранится XML-политика. Заменив в названии политики двоеточия (точки?) на символы /, можно получить полный путь к файлу политики относительно каталога /etc/xen/acm-security/policies. Последняя часть имени политки это префикс для XML-файла политики, за которым следует -security_policy.xml. Например, политика с именем example.chwall_ste.test будет находиться в файле test-security_policy.xml, который находится в каталоге example/chwall_ste/ в каталоге политик.

Компонент политики Simple Type Enforcement

Политика Simple Type Enforcement (STE) контролирует какие домены могут обмениваться информацией и осуществлять совместный доступ к ресурсам. С помощью этого компонента, Xen может ограничивать типы нагрузок, ограничивая домены, которые выполняют соответствующие нагрузки. Применение политки происходит, когда домены используют различные пути обмена информацией (разделяемая память, события, разделямые ресурсы, такие как блочные устройства). Она строится на базе изоляции гипервизора, что ограничивает взаимодействие по явным каналам. STE не защищает и даже не пытается защищать от обмена информацией по скрытым каналам в гипервизоре или железе; это ортогональная проблема, которую можно смягчить правилами исключения времени выполнения, описанными выше, или исправив соответствующую ошибку в гипервизоре.
Xen управляет совместным доступом доменов на уровне доменов и ресурсов, посколько эта абстракция, является для гипервизора и управляющих утилит естественной. И хотя управляемые элементы получаются весьма крупными, такой подход оказывается достаточно надёжным и требует минимальный изменений гипервизора для внедрения в него возможностей принудительного контроля доступа (mandatory access control). Он включает возможность организации многоуровневой безопасности, не зависящей от платформы и операционной системы.

Строки 9-15 определяют компонент политики Simple Type Enforcement. По сути, они определяют типы нагрузок SystemManagement, PepsiCo и CocaCola, доступные в компоненте STE политики. Правила политики неявные: Xen позволяет доменам обмениваться информацией между собой только в том случае, если домены имеют одинаковый тип STE. Xen позволяет домену обращаться к ресурсу только в том случае, если метка домена и ресурса имеют одинаковый тип нагрузки STE.

Компонент политики Chinese Wall

Политики Chinese Wall (Китайская стена) в интерпретации sHype позволяет пользователяем предотвратить одновременное выполнение нагрузок от одновременного исполнения на платформе одного гипервизора. Правила исключения времени выполнения (Runtime Exclusion Rules, RER), также называемые множествами конфликтов (Conflict Sets), определяют множество типов нагрузок, которым нельзя выполняться одновременно. Из всех нагрузок, определённых в правилах исключения времени выполнения, максимум одна может выполняться на платформе одного и того же гипервизора в любой момент времени. RER реализуют менее жёсткий вариант оригинального компонента безопасности Chinese Wall. В них не реализовано *-свойство политики, которое потребовало бы ограничить типы, которые не являются частью правила исключения, как только они задействованы вместе с типами в правиле исключения (дополнительную информацию о том, что такое политика Chinese Wall вообще.
Xen при выполнении правил исключений времени исполнения учитывает ту часть метки, которая относится к ChineseWallTypes. Будет некорректно определять метки, включающие конфликтующие типы Chinese Wall’ов.
Строки 17-30 определяют компонент политики Chinese Wall. Строки 17-22 описывают известные типы Chinese Wall, которые здесь совпадают с STE типами, определёнными выше. Так бывает, если критерии для совместного использования доменами и совместного использования аппаратной платформы одинаковы. Строки 24-29 определяют одно правило исключения времени выполнения:

        <Conflict name="RER1">          <Type>CocaCola</Type>          <Type>PepsiCo</Type>        </Conflict>

Основываясь на этом правиле, Xen разрешит домену только одного типа, CocaCola или PepsiCo, работать с одним гипервизором в каждый момент времени. Например, как только запущен домен с назначенным ему типом нагрузки CocaCola, домен с типом нагрузки PepsiCo стартовать не сможет. Когда предыдущий домен завершится, а других доменов такого типа запущено не будет, сможет стартовать домен PepsiCo.

Для того чтобы отследить, какие нагрузки используются, Xen отслеживает количество ссылок на каждый тип нагрузки. Каждый раз когда домен стартует или возобновляет работу, количество ссылок на тип Chinese Wall, на который ссылается доменная метка, увеличивается. Каждый раз когда домен уничтожается или сохраняется, количество соответствующих ссылок уменьшается. sHype в Xen поддерживает миграцию и живую миграцию, которая обрабатывается также как сохранение на одной платформе и последующее возобновление на другой платформе работы домена.

Причины, из-за которых может потребоваться ограничить список разрешённого к использованию доменом или нагрузкой оборудования:
Несовершенство механизмов управления ресурсами может привести к тому, что из-за одного некорректно ведущего себя домена ресурсов не будет другим домена и нагрузкам, работающим в них.Запасные домены могут выполнять ту же нагрузку для повышения отказоустойчивости. Такие домены не должны работать на одном и том же оборудовании, чтобы избежать узких мест.Из-за несовершенной изоляции доменов два злонамеренных домена могут обмениваться мужде собой данными. Таким образом, они обходят механизмы контроля доступа Xen. Эта проблема не может быть устранена полностью. Она является результатом компромисса между безопасностью и другими требованиями архитектуры. Такие же скрытые каналы могут быть между нагрузками, выполняющимися на различных платформах, при условии, что они соединены с помощью сети. Политика Xen Chinese Wall обеспечивает приблизительную реализацию этого несовершенного «зазора» между выбранными типами нагрузок.

Метки безопасности

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

Пример XML-файла политики безопасности — Часть II: Определение метокСтроки 32-89 определяют шаблон SecurityLabelTemplate, включающий метки, которые могут быть прикреплены к доменам и ресурсам, когда политика активна. Доменные метки включают в свой состав типы Chinese Wall, а метки ресурсов — нет. Строки 33-65 определяют метки

SubjectLabels, которые могут быть назначены доменам. Например, метка виртуальной машины CocaCola (строки 56-64) ассоциируют соответствующий домен с типом нагрузки CocaCola.

Атрибут bootstrap именует метку SystemManagement. Xen во время загрузки назначает эту метку домену Domain0. Метки для всех остальных доменов назначаются в соответствии с конфигурационным файлом домена. Строки 67-88 определяются метки объектов ObjectLabels. Когда политика активна, эти метки могут назначаться ресурсам.
Вообще, пользовательским доменам можно назначать метки, у которых есть только один тип нагрузки SimpleTypeEnforcement. В таком случае, нагрузка оказывается ограниченной, даже если пользовательский домен начинает вести себя некорректно. В любом домене, которому назначена метка с несколькими типами STE, можно доверять в том смысле, что информация принадлежащая различным STE типам будет разделена. Например, домен Domain0 имеет метку SystemsManagement, которая включает все известные STE типы. Это означает, что домен должен беспокоиться о том чтобы не допускать неавторизованного обмена информацией (например, через блочные устройства или виртуальную сеть) между доменами или ресурсами, которым назначены разные типы STE.

Для того чтобы ассоциировать метку с доменом, администратор безопасности просто использует имя метки, указанное в поле <Name>. Типы внутри метки испольщуются Xen’ом для выполнения контроля доступа. Имя метки может быть каким-угодно (главное, чтобы оно было уникальным), но рекомендуется выбирать его так, чтобы оно соответствовало включенным в метку типам безопасности. XML-представление показанной выше метки может показаться излишне гибким, как мы увидим в примере ниже, в общем случае метки могут состоять из множества типов.

Предположим, что нагрузки PepsiCo и CocaCola пользуются виртуальными дисками, которые предоставляет виртуальный домен ввода/вывода, использующий физическое устройство хранения, и у этого домена такая метка:

        <VirtualMachineLabel>          <Name>VIO</Name>          <SimpleTypeEnforcementTypes>              <Type>CocaCola</Type>              <Type>PepsiCo</Type>          </SimpleTypeEnforcementTypes>          <ChineseWallTypes>              <Type>VIOServer</Type>          </ChineseWallTypes>        </VirtualMachineLabel>

Этот виртуальный домен ввода/вывода (Virtual I/O domain, VIO) экспортирует свои виртуализированные диски общаясь с обоими доменами: с меткой PepsiCo и с меткой CocaCola. Для этого нужно чтобы у VIO домена были обе метки: PepsiCo и CocaCola. В этом примере разграничения нагрузок PepsiCo и CocaCola зависит от домена, который должен держать данные этих двух разных нагрузок разделёнными. Виртуальные диски тоже помечены и enforcement функции VIO домена должны гарантировать, что метки виртуального диска и домена, монтирующего виртуальный диск, имеют одинаковый тип STE. VIO метка со своим CHWALL типом VIOServer позволяет VIO серверу, к которому есть доверие, выполнять одновременно нагрузки PepsiCo и CocaCola.

Как вариант, система у которой есть два жестких диска может не использовать VIO домен, а может непосредственно назначить каждое устройство отдельным нагрузкам (если у платформы есть IO-MMU). Организация совместного использования железа с помощью виртуализации это компромисс между объёмом безопасного (trusted) кода (т.е. размером trusted computing base) и допустимой величиной дополнительных мер предосторожности. Это относится как периферии, так и к самой системной платформе.
Инструменты для создания политик безопасности sHype/Xen

Для создания политик безопасности для Xen могут использоваться такие инструменты:

ezPolicy GUI tool — начало написания политик;xensec_gen tool — доводка политик, созданных с помощью ezPolicy;текстовый или XML-редактор.В этом примере для того чтобы быстро создать политику защиты нагрузки использозвался ezPolicy. При желании можно загрузить полученный файл в xensec_gen и доработать его. Его же можно непосредственно доработать с помощью редактора XML. Каждый XML-файл при трансляции проверяется на соответствие схеме политики безопасности.

Существующие ограничения

Работа над sHype/ACM для Xen продолжается. Сейчас идёт работа по организации защиты виртуализированных ресурсов и планируется организация защиты удалённых ресурсов и доменов. Ниже описываются ограничения существующие ограничения механизма управления доступом, над устранением которых ведётся работа.

Сетевой трафик

Локальный и удалённый сетевой трафик не контролируется. Существуют решения по наложению ограничений sHype/ACM на виртуальную сеть, но их нужно обсудить прежде чем сделать частью Xen. Ведётся разработка возможности подчинения внешнего сетевого трафика политикам ACM. Сейчас требуется ручная установка фильтров в домене 0, но этот подход не очень хорошо масштабируется.

Контроль доступа и использования ресурсов

Ведётся работа над возможностью распространению политики безопасности на несколько гипервизоров и ресурсы, к которым выполняется доступ по сети. Ведётся работа по расширению управления доступом к новым видам ресурсов (например, сетевым хранилищам).

На отдельной Xen-системе информация о связи ресурсов и меток безопасности хранится в файле /etc/xen/acm-security/policy/resource_labels. В этом файле полным путям к ресурсам поставлены в соответствие метки. Связь является слабой, и она разрывается в том случае, если ресурсы перемещаются или перименовываются без соответствующих изменений в файле. Работы над механизмами управления и ограничения на использование ресурсов в Xen продолжаются.

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

Метки доменов сохраняются при миграции. Гипервизор-получатель прежде чем разрешить ми миграцию должен убедиться, что метка правильная, и домен имеет право работать (с учётом правил политики Chinese Wall). Тем не менее, сеть между гипервизорами должна быть безопасной. Существуют архитектуры и прототипы, обеспечивающие защиту сети и гарантирующие целостность политик контроля доступа, однако соответствующие патчи пока не включены в основной дистрибутив.

Скрытые каналы

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

Справочная информация

Опции сборки и загрузки

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

Конфигурационные опции верхнего уровня

Конфигурирование выполняется путём редактирования файлов: Config.mk и Makefile.

В файле Config.mk указывается архитектура, для которой будет выполняться сборка. Её не нужно изменять, за исключением случаев, когда производится кросс-компиляция или сборка выполняется для системы с поддержкой PAE. Дополнительные конфигурационные опции описаны в Config.mk.

Файл Makefile используется главным образом для настройки набора собираемых ядер. Это делается с помощью строки:
KERNELS ?= linux-2.6-xen0 linux-2.6-xenUДопускается указывать здесь любые ядра, для которых есть соответствующий конфигурационный файл в каталоге buildconfigs/.

Опции сборки Xen

verbose = y Включить отладочные сообщения, когда Xen обнаруживает неожиданное состояние. Также включает консольный вывод из всех доменов.
debug = y Включить отладочные сообщения. Подразумевает verbose=y. (Главным образом используется для отлавливания ошибок в Xen).
debugger = y Включить отладчик Xen. Может использоваться для отладки Xen, гостевых ОС и приложений.
perfc = y Включает счётчики производительности внутри Xen для важных событий. Счётчики можно сбросить или просмотреть с консоли Xen с помощью специальных управляющих комбинаций клавиш.

Опции загрузки Xen

Данные опции используются для конфигурирования Xen во время работы. Их нужно добавлять в командную строку Xen или вручную, при запуске, или путём редактирования конфигурационного файла GRUB grub.conf.

noreboot Не перезагружать машину автоматически при возникновении ошибки. Это может помочь прочитать отладочный вывод, в тех случаях, когда не используется serial-консоль.
nosmp Выключить поддержку SMP. Эта опция подразумевается опцией `ignorebiostables’.
watchdog Включить watchdog NMI. Он может сообщать об определённых сбоях.
noirqbalance Отключить software IRQ balancing and affinity. Это может понадобиться в системах таких как Dell 1850/2850 в которых используются хитрые железные решения для обхода проблем с маршрутизацией IRQ.

~badpage=<page number>,<page number>,…~Список страниц, которые нельзя использовать из-за того что они содержат плохие байты. Например, если в результате тестирования памяти установлено что байт с адресом 0x12345678 сбойный, в командной строке Xen нужно указать «badpage=0x12345».
~com1=<baud>,DPS,<io_base>,<irq> com2=<baud>,DPS,<io_base>,<irq>~Xen поддерживает до двух 16550-совместимых последовательных портов. Например: `com1=9600, 8n1, 0x408, 5′ обозначает COM1, на скорости 9600, 8 битов данных, без четности, адрес базы ввода/вывода 0x408, IRQ 5. Если какие-то конфигурационные опции имеют значение по умолчанию (например, адрес базы ввода/вывода или IRQ), тогда нужно указывать только часть конфигурационной строки. Если скорость порта сконфигурирована (например, с помощью загрузчика), тогда вместо численного значения можно указать auto.

~console=<specifier list>~Указать получателя консольного ввода/вывода. Список состоит из значений, разделенных запятыми:
; vga: Использовать консоль VGA (до тех пор пока не загрузится домен 0, за исключением тех случаев, когда указан vga=keep). ; com1: Использовать последовательный порт com1.; com2H: Использовать последовательный порт com2. У передаваемых символов будет установлен MSB. У принимаемых символов должен быть установлен MSB.; com2L: Использовать последовательный порт com2. У передаваемых символов будет сброшен MSB. У принимаемых символов должен быть сброшен MSB.

Последние два позволяют организовать совместное использование порта двумя подсистемами (например, консолью и отладчиком). Совместное использование контролируется MSB каждого передаваемого/принимаемого символа. Значение по умолчанию ‘com1,vga’.
vga=<options>Список опций, разделённых с помощью ;.; text-<mode>: Выбрать разрешение текстового режима, где режим может иметь такие значения: 80×25, 80×28, 80×30, 80×34, 80×43, 80×50, 80×60. ; keep: Сохранять консоль в VGA режиме даже после того как загрузится домен 0.
sync_consoleВыполнять вывод на консоль в синхронном режиме. Это может помочь в том случае, если система падает перед тем как вывести на консоль все имеющиеся для вывода данные. В большинстве случаев Xen автоматически переходит в синхронный режим сам, как только возникает исключительно событие, но эта опция переводит в синхронный режим в любом случае.

conswitch=<switch-char><auto-switch-char>Указывает, как переключать последовательную консоль между Xen и доменом 0. Требуемая последовательность — Ctrl-<switch-char> нажатый три раза подряд. Для того чтобы отключить переключение, нужно в качестве символа переключения указать обратную кавычку. Символ <auto-switch-char> указывает, должен ли Xen автоматически переключать ввод на домен 0, когда загрузка Xen завершится. Символ «x» означает, что автоматическое переключение отключено. Автоматическое переключение включено во всех остальных случаях. Символ переключения по умолчанию это «a».
nmi=xxxУказывает, что делать с чётностью NMI и ошибками ввода/вывода.*»nmi=fatal»: Xen выводит диагностическое сообщение после чего зависает.*»nmi=dom0″: Уведомить домен 0 NMI.*»nmi=ignore»: Игнорировать NMI.

mem=xxxУстановить предел адресации физической памяти. Память, находящаяся за пределами указанного значения, будет игнорироваться. Параметр может быть указан с суффиксом B, K, M или G, обозначающим байты, килобайты, мегабайты и гигабайты соответственно.

dom0_mem=xxxУказывает объём памяти, выделяемый домену 0. В Xen 3.0 параметр может быть указан с суффиксом B, K, M или G, обозначающим байты, килобайты, мегабайты и гигабайты соответственно. Если суффикс не указан, подразумеваются килобайты. В предыдущих версих Xen суффикс не поддерживался, и все значения интерпретировались как значения в килобайтах.

dom0_vcpus_pinЗакрепить виртуальные процессоры домена 0 за соответствующими им физическими процессорами (по умолчанию =false).
tbuf_size=xxxРазмер буферов трассировки для каждого процессора, в страницах. По умолчанию 0.
sched=xxxВыбрать какой планировшик процессора будет использовать Xen. Возможные значения «credit» (по умолчанию) и «sedf».
apic_verbosity=debug,verboseВыводить более развёрнутую информацию о конфигурации локального APIC и IOAPIC.
lapicИспользовать локальный APIC, даже если он отключен однопроцессорным BIOS’ом.

nolapicНе использовать локальный APIC в однопроцессорной системе, даже если он включён в BIOS.
apic=bigsmp,default,es7000,summitУказать платформу NUMA. Обычно она определяется автоматически.
В дополнение к перечисленным опциям, в командной строке Xen можно указывать следующие опции. Поскольку домен 0 тоже отвечает за загрузку системы, Xen автоматически передаёт эти опции в его командную строку. Опции взяты из синтаксиса командной строки ядра Linux без изменения смысла.

acpi=off,force,strict,ht,noirq,…Указать как Xen (и домен 0) обрабатывают таблицы ACPI BIOS.
acpi_skip_timer_overrideУказать Xen’у (и домену 0) игнорировать перекрывающие прерывание теаймера инструкции определённые таблицами ACPI BIOS.
noapicУказать Xen (и домену 0) игнорировать IOAPIC’и присутствующие в системе и вместо них использовать обычный PIC.
Опции загрузки XenLinux

В дополнение к стандартным опциям Linux поддерживается:

xencons=xxx

Устройство, к которому подключается драйвер виртуальной консоли Xen. Поддерживаются следующие варианты:* xencons=off: отключить виртуальную консоль* xencons=tty: подключить консоль к /dev/tty1 (tty0 при загрузке)* xencons=ttyS: подключить консоль к /dev/ttyS0

Взято тут

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

  1. Уведомление: Руководство пользователя Xen v3.0 Часть 4 | Блог Линуксоида

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

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