Продолжу рассказ про перспективные разработки в области виртуализации. Давайте рассмотрим отдельно стоящий сервер, к которому в силу тех или иных причин злоумышленник получил доступ с привилегиями администратора. Плохо? Безусловно. Теперь у злоумышленника "ключи" от всех выполняющихся на сервере служб. А теперь представьте, что в роли сервера у нас машина с гипервизором, в котором работает какое-то количество виртуальных машин. Ситуация хуже во много раз: "плохие парни" получают доступ сразу ко всем виртуальным машинам. Тем более, что опасность увеличивается, благодаря использованию в случае гостевых операционных систем локальных механизмов атаки. Оставим в стороне конкретные технологии и конкретных вендоров. Не важно, чья модель безопаснее - Microsoft, VMWare, Citrix, Sun, etc. Никто не будет спорить, что от потенциальных уязвимостей не застрахован никто, вне зависимости от размеров возможной площади атаки.
Теперь снова вернемся к более простому и традиционному случаю - получению привилегий на отдельно стоящем сервере/ОС. Данная проблема более традиционна, и для ее решения уже существуют технологии. Благодаря таким решениям, ряд операционных систем общего назначения, например, уже получило высокий уровень сертификации Common Сriteria EAL4+ (c расширениями LSPP, RBACPP и CAPP).
Такие "заклинания", как мандатный контроль доступа (MAC), многоуровневая система безопасности (MLS), мульти-категорийная безопасность (MCS) уже не раз встречались в моем блоге в контексте операционной системы. Я не буду повторяться, и просто дам ссылку на посты с тегом "SELinux", где я и писал про практическую реализацию ограничений привилегий системного администратора :) Итак, идея состоит в том, чтобы защитить гипервизор при помощи существующих решений мандатного контроля доступа.
Теперь вернемся к конкретике :) Проект sVirt, направленный на решение этой задачи, был анонсирован Джеймсом Моррисом в рассылке libvirt в августе прошлого года. Цель проекта - интеграция SELinux и виртуализации на основе Linux-ориентированных технологий. Недостаточность традиционного дискреционного контроля доступа в системах, требующих особой защищенности, обуславливается тем, что субъект может менять собственную политику безопасности. С другой стороны, если гостевые операционные системы будут изолированы при помощи политик мандатного контроля доступа, то это резко снижает возможный ущерб от успешной атаки, а то и вовсе ее предотвращает. В идеале в каждом процессе виртуальная машина должна работать в собственном контексте безопасности. Снова в качестве иллюстрации посмотрим на отдельную - не виртуализированную - операционную систему. Вы без труда найдете примеры, когда реальные уязвимости, затрагивающие ОС, в том или ином компоненте операционной системы с отключенным SELinux успешно блокировались политикой безопасности при включенном мандатном контроле.
К своей первой версии sVirt должен обеспечивать реализацию MAC на уровне ядра гипервизора, и обеспечивать простую изоляцию виртуальных машин, не требуя никакой настройки, т.е. все должно работать "из коробки". Ресурсы каждой гостевой операционной системы должны иметь свой уникальный контекст virtd_isolated_t:. Взаимодействие между доменами при этом исключается. В будущем планируется выделить разные типы гостевых машин, требующих разную политику, например, virtd_isolated_webserver_t, реализовать политику SELinux на уровне сетевого взаимодействия, многоуровневую систему безопасности (MLS).
В каком состоянии находится проект сейчас? Сделана низкоуровневая интеграция с libvirt, базовая поддержка в virsh, и виртуальные машины могут запускаться в своих контекстах безопасности. Как и в случае с oVirt, в первую очередь работа идет над KVM.
Что означает все выше сказанное? Возможно в будущем те уникальные преимущества в плане защищенности, доступные в операционных системах общего назначения с открытым исходным кодом, станут преимуществами систем виртуализации с открытым кодом.
Теперь снова вернемся к более простому и традиционному случаю - получению привилегий на отдельно стоящем сервере/ОС. Данная проблема более традиционна, и для ее решения уже существуют технологии. Благодаря таким решениям, ряд операционных систем общего назначения, например, уже получило высокий уровень сертификации Common Сriteria EAL4+ (c расширениями LSPP, RBACPP и CAPP).
Такие "заклинания", как мандатный контроль доступа (MAC), многоуровневая система безопасности (MLS), мульти-категорийная безопасность (MCS) уже не раз встречались в моем блоге в контексте операционной системы. Я не буду повторяться, и просто дам ссылку на посты с тегом "SELinux", где я и писал про практическую реализацию ограничений привилегий системного администратора :) Итак, идея состоит в том, чтобы защитить гипервизор при помощи существующих решений мандатного контроля доступа.
Теперь вернемся к конкретике :) Проект sVirt, направленный на решение этой задачи, был анонсирован Джеймсом Моррисом в рассылке libvirt в августе прошлого года. Цель проекта - интеграция SELinux и виртуализации на основе Linux-ориентированных технологий. Недостаточность традиционного дискреционного контроля доступа в системах, требующих особой защищенности, обуславливается тем, что субъект может менять собственную политику безопасности. С другой стороны, если гостевые операционные системы будут изолированы при помощи политик мандатного контроля доступа, то это резко снижает возможный ущерб от успешной атаки, а то и вовсе ее предотвращает. В идеале в каждом процессе виртуальная машина должна работать в собственном контексте безопасности. Снова в качестве иллюстрации посмотрим на отдельную - не виртуализированную - операционную систему. Вы без труда найдете примеры, когда реальные уязвимости, затрагивающие ОС, в том или ином компоненте операционной системы с отключенным SELinux успешно блокировались политикой безопасности при включенном мандатном контроле.
К своей первой версии sVirt должен обеспечивать реализацию MAC на уровне ядра гипервизора, и обеспечивать простую изоляцию виртуальных машин, не требуя никакой настройки, т.е. все должно работать "из коробки". Ресурсы каждой гостевой операционной системы должны иметь свой уникальный контекст virtd_isolated_t:
В каком состоянии находится проект сейчас? Сделана низкоуровневая интеграция с libvirt, базовая поддержка в virsh, и виртуальные машины могут запускаться в своих контекстах безопасности. Как и в случае с oVirt, в первую очередь работа идет над KVM.
Что означает все выше сказанное? Возможно в будущем те уникальные преимущества в плане защищенности, доступные в операционных системах общего назначения с открытым исходным кодом, станут преимуществами систем виртуализации с открытым кодом.
5 комментариев:
было бы справедливо упоминуть apparmor и солярис его безумном количеством зон
Зоны это несколько иное. В солярис соответствующая технология - это Flask. И поскольку проект относительно молодой, в настоящий момент он менее готов к промышленному применению.
Про проекты подобные sVirt, но основанные на AppArmor я не знаю. Кроме того, на мой взгляд по ряду причин данная технология менее перспективна.
Иное? Зоны это чистый аналоиг виртуализации. Selinux вот это да,- несколько иное.
Нет. Зоны - это "кирпичики" из которых строятся контейнеры. А контейнер - это изолированная среда
исполнения в рамках одной системы Solaris. Это не виртуализация. Все зоны в системе используют общее ядро.
Насколько я понимаю (я глубоко в этом не разбирался и на данный момент мои суждения поверхностны) ближайший аналог в Linux - это Lguest
Спасибо очень интересные замечания.
Все это где-то рядом. xen, selinux, lguest, flask. Попробую разобраться.
Отправить комментарий