Джеймс Боттомли (James Bottomley), известный разработчик ядра Linux, входивший в координационный технический комитет Linux Foundation, опубликовал (https://blog.hansenpartnership.com/measuring-the-horizontal-.../) результаты анализа безопасности различных систем контейнерной изоляции, включая традиционные контейнеры Docker, недавно представленную систему Nabla (https://nabla-containers.github.io/), нацеленную на минимизацию выполняемых в основном ядре системных вызовов, и гибридные системы gVisor (https://www.opennet.me/opennews/art.shtml?num=48538) и Kata Containers (https://www.opennet.me/opennews/art.shtml?num=48642) с изоляцией на базе гипервизоров.Для каждого типа систем оценивался уровень защищённости от совершения горизонтальных атак (HAP, Horizontal Attack Profile (https://blog.hansenpartnership.com/containers-and-cloud-secu.../)), при которых брешь в одном из базовых слоёв (например, в ядре Linux или гирервизоре) может привести к полной компрометации всей инфраструктуры и получению контроля за корневым окружением и всеми запущенными контейнерами. Уровень безопасности HAP зависит от объёма привилегированного кода, который вызывается в процессе работы той или оной системы контейнерной изоляции или виртуализации. Чем меньше привилегированного кода вовлечено в выполнение контейнера тем выше безопасность всей системы, так как сокращается число потенциальных векторов для атак и уменьшается вероятность присутствия уязвимостей.
Основным путём совершения горизонтальных атак для контейнеров являются системные вызовы, обработка которых выполняется на стороне общего ядра и, в случае наличия уязвимости в одном из обработчиков системного вызова, злоумышленник, имеющий доступ к одному из контейнеров, может получить контроль над всей инфраструктурой. В случае применения виртуализации на базе гипервизоров главными объектами для атак становятся гипервизор и прослойки для обеспечения доступа к оборудованию или эмуляции оборудования. В системах контейнерной изоляции предоставляется доступ к около 300 системным вызовам, что примерно в 10 раз превышает число гипервызовов (hypercall).
Из-за использования общего ядра Linux обычные контейнеры предоставляют больше векторов для совершения горизонтальных атак. Выходом могли бы стать комбинированные решения на базе виртуализации, использующие легковесное системное окружение, но из-за больших накладных расходов они проигрывают по производительности и требуют для своей работы больше памяти. В качестве варианта, который обеспечивал бы должную производительность и защищённость, недавно была представлена (https://nabla-containers.github.io/blog/) система контейнерной изоляции Nabla (https://nabla-containers.github.io/).
В Nabla используется только 9 системных вызовов, а вся основная функциональность, включая TCP/IP стек и код файловых систем, реализована в виде работающего в пространстве пользователя unikernel, не привязанного к ядру ОС и системным библиотекам. Данную систему можно рассматривать как аналог систем для запуска приложений поверх гипервизора, но вместо гипервизора использует обычные механизмы контейнерной изоляции с жесткой блокировкой доступа к системным вызовам при помощи фильтров seccomp.
В качестве основы в окружениях Nabla задействованы наработки открытого компанией IBM проекта Solo5 (https://github.com/Solo5/solo5/), предоставляющего изолированное окружение для запуска произвольных unikernel, в том числе развиваемых проектами Rump (https://www.opennet.me/opennews/art.shtml?num=40371), MirageOS (https://www.opennet.me/opennews/art.shtml?num=42515) и IncludeOS (https://www.opennet.me/opennews/art.shtml?num=43444). Вся необходимая системная функциональность прикрепляется к приложению во время сборки. Среди протестированных приложений Nginx, Python, Redis и Node.js, для которых подготовлены (https://github.com/nabla-containers/nabla-base-build) типовые образы контейнеров. Для запуска контейнеров применяется runtime runnc (https://github.com/nabla-containers/runnc) (переработанный runc), интегрируемый с инструментарием Docker и совместимый со спецификацией
OCI (https://www.opennet.me/opennews/art.shtml?num=46889) (Open Container Initiative).Для анализа безопасности была проведена оценка охвата привилегированного кода, который вовлекается при выполнении изолированных окружений. В частности, было посчитано число функций ядра, которые были вызваны в процессе работы окружений с Redis, Python и Node.js. В результате в Nabla было зафиксировано в 2-3 раза меньше вызовов по сравнению с другими механизмами изоляции, в том числе с gVisor (https://www.opennet.me/opennews/art.shtml?num=48538) (используется собственное мини-ядро на языке Go, предоставляющее необходимые системные вызовы) и Kata Containers (https://www.opennet.me/opennews/art.shtml?num=48642) (применяется урезанный вариант обычного ядра Linux).
Измерение производительности тестовых заданий на базе Redis, Python и Node.js показало лишь незначительное отставание Nabla от Docker.URL: https://blog.hansenpartnership.com/measuring-the-horizontal-.../
Новость: https://www.opennet.me/opennews/art.shtml?num=48969
Можно изобретать сколько угодно уровней, слоёв и абстракций, но если ты купил проц у успешных откатчиков, смысла в этом не будет никакого.
Проблема этого сравнения в том, что для контейнеров учитывались прямые обращения к системным вызовам, а для виртуализации косвенные - в основном вызовы посчитаны для бэкендов xen и kvm. С точки зрения возможности проведения атак - это небо и земля, как минимум двухкратное усложнение атаки. Например, если найдена 0-day в системном вызове ядра, из контейнера её можно эксплуатировать сразу, а при виртуализации ещё нужно найти вторую дыру в бэкенде. Вообщем, несмотря на всю дырявость Xen контейнеры пока и близко не подошли по уровню изоляции к виртуализации.
+1
похоже, основной целью псевдоисследования являлось навешать маркетоидной лапши на уши - покупайте НАШИХ слонов.
Контейнер в контейнере в контейнере в контейнере в виртуализированной абстракции... Да, предохраняться они умеют, но ощущений никаких уже
нужно запретить все языки программирования кроме Ada и Eiffel, и будет нам безопасность :)
Угу, нет кода -- нет уязвимостей.
Верните машину времени на место, пожалуйста.
> Верните машину времени на место, пожалуйста.стоп, а вы из какого года? Мне б таймер для криокамеры правильно поставить...
> Узким местом Nabla стала реализация сетевого стека в пространстве пользователя. При использовании конфигурации с оркестровкой контейнера напрямую (nabla-raw) без сетевого взаимодействия, производительность Nabla достигла уровня Docker.Зашибись! То есть на диаграмме производительности nabla-raw и nabla-container идут отдельно. А на диаграмме количества системных вызовов есть только одна nabla. Но если юзать ядерный сетевой стек, то вызовов будет явно больше. Какой-то по-детски наивный обман.
> Джеймс Боттомли (James Bottomley), известный разработчик ядра Linux, входивший в координационный
> технический комитет Linux Foundation, опубликовал (https://blog.hansenpartnership.com/measuring-the-horizontal-.../)Полностью:
> A New Method of Containment: IBM Nabla ContainersА еще, совершенно случайно:
https://researcher.watson.ibm.com/researcher/view.php?person...
> James Bottomley is a Distinguished Engineer at IBM Research where he works on Cloud and Container technologyвот ведь какие совпадения бывают!
Не и название. Не знаю о чём речь, но ставить отказываюсь.
> Не и название. Не знаю о чём речь, но ставить отказываюсь.Узнайте больше[I]!
https://blog.hansenpartnership.com/?p=492
http://techrights.org/2018/06/03/blockchain-patent-hype-and-ibm/