Комментарии 14
$ xhost +local:Вот кейлоггеру-то раздолье будет. А Xephyr/Xnest чем не угодили?
Во многих статьях, которые мне попадались, часто вообще советуют использовать
К сожалению, мало, что про них знаю — не довелось попробовать пока. Вы имеете ввиду какую-то связку Docker+Xephyr?
xhost +, а заботы о «защите» возложить на AppArmor, SELinux и т.п. :) Мне кажется, такое решение изначально не нацелено на полную изоляцию приложений, так как оно основано на встроенных возможностях самого docker, а он создавался, грубо говоря, не для этого. А Xephyr/Xnest чем не угодили?
К сожалению, мало, что про них знаю — не довелось попробовать пока. Вы имеете ввиду какую-то связку Docker+Xephyr?
Причины могут быть разные, но чаще всего, это желание сменить излишне громоздкую виртуальную машину на что-то полегче, не потеряв в удобстве и сохранив при этом достаточный уровень изоляции.
Какой уж тут уровень изоляции — контейнеру отдана в полный доступ целая куча устройств. С этим подходом докер превращается из средства контейнеризации в эдакий файрвол между программой и ресурсами ОС.
докер превращается из средства контейнеризации
В chroot
«If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means.» © Alan Cox
Не уверен, что с LXC такое прокатит…
Не уверен, что с LXC такое прокатит…
Тогда fakeroot
$ man fakeroot
…
Fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership.
…
Ещё варианты? :)
…
Fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership.
…
Ещё варианты? :)
Программа думает, что она запущена от рута. На самом деле это не так.
Позволю себе поянить смысл моего первого комментария с цитатой Алана Кокса:
LXC в chroot не превратится хотя бы потому, что в lxc изоляция происходит на уровне ядра, что даёт меньше шансов выбраться за пределы контейнера, нежели за пределы chroot'а
Так же LXC позволяет влиять на потребление ресурсов контейнерами (cpu, ram, ...), изолировать пространство процессов, сетевой стек…
В общем, chroot'у до LXC ой как далеко, даже если LXC сильно-сильно «сконфигурировать» :)
На закуску из man'а chroot'а:
This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a «chroot jail» by doing:
mkdir foo; chroot foo; cd…
This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.
LXC в chroot не превратится хотя бы потому, что в lxc изоляция происходит на уровне ядра, что даёт меньше шансов выбраться за пределы контейнера, нежели за пределы chroot'а
Так же LXC позволяет влиять на потребление ресурсов контейнерами (cpu, ram, ...), изолировать пространство процессов, сетевой стек…
В общем, chroot'у до LXC ой как далеко, даже если LXC сильно-сильно «сконфигурировать» :)
На закуску из man'а chroot'а:
This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a «chroot jail» by doing:
mkdir foo; chroot foo; cd…
This call does not close open file descriptors, and such file descriptors may allow access to files outside the chroot tree.
Мой вариант: github.com/Kagami/kagome
Пока в статусе proof of concept, но планирую допиливать. Если, конечно, что-то более интересное не появится.
Так-то подобных проектов много (особенно тема стала популярна с развитием легковесных контейнеров): sandstorm.io/, coreos.com/, qubes-os.org/ от Рутковской, наконец.
Пока в статусе proof of concept, но планирую допиливать. Если, конечно, что-то более интересное не появится.
Так-то подобных проектов много (особенно тема стала популярна с развитием легковесных контейнеров): sandstorm.io/, coreos.com/, qubes-os.org/ от Рутковской, наконец.
Интересно, я сам задумывался над чем-то вроде light версии QubesOS — более легкой и менее защищенной. Хотя я так понимаю в случае с PV domN, оверхэд и не такой большой. А как у вас обстоят дела с opengl? В QubesOS его нет by design, что немного обидно терять возможность иметь webgl, vdpau и прочее.
Судя по рассылке QubeOS, я так понял что у них даже memory deduplication выключен: groups.google.com/forum/#!msg/qubes-devel/tfMk_g7Y1tQ/iSLQ2jNyZH8J. А значит оверхэд получается очень даже приличным. Хотя вообще про QubeOS мало что могу сказать, но как концепт она гораздо более стройнее и привлекательнее и разрабатывают её люди с неплохим бэкграундом в области безопасности.
Что мне в QubeOS и подобных дистрибутивах не очень нравится — так это то, что это полностью отдельный дистрибутив со своей экосистемой, а значит многие плюсы популярных систем вроде Debian сводятся на нет. Мне ближе по душе использование в родном дистрибутивы средств изоляции, которые достаточно надёжны для большинства задач: отдельные пользователи, отдельные иксы, MAC, контейнеры и т.д.
Про OpenGL, честно говоря, ещё не думал, но вот судя по тому, что в Xephyr поддерживается акселлерация и пробросить иксы с акселлерацией внутрь контейнера возможно, в принципе проблема решаема.
Хотя я, честно говоря, в последнее время больше смотрю в сторону использования отдельной машины для небезопасных и/или сложно изолируемых приложений. Заодно там и Windows можно второй системой для некоторых приложений. Получается и проще, и безопаснее.
Что мне в QubeOS и подобных дистрибутивах не очень нравится — так это то, что это полностью отдельный дистрибутив со своей экосистемой, а значит многие плюсы популярных систем вроде Debian сводятся на нет. Мне ближе по душе использование в родном дистрибутивы средств изоляции, которые достаточно надёжны для большинства задач: отдельные пользователи, отдельные иксы, MAC, контейнеры и т.д.
Про OpenGL, честно говоря, ещё не думал, но вот судя по тому, что в Xephyr поддерживается акселлерация и пробросить иксы с акселлерацией внутрь контейнера возможно, в принципе проблема решаема.
Хотя я, честно говоря, в последнее время больше смотрю в сторону использования отдельной машины для небезопасных и/или сложно изолируемых приложений. Заодно там и Windows можно второй системой для некоторых приложений. Получается и проще, и безопаснее.
Класс, у меня появилась надежда запилить легковесное средство для работы с jack на двух аудиокартах!
А ускорение графики? Я бы в варианте «Монтирование» смонтировал ещё /dev/dri/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker: запуск графических приложений в контейнерах