Анонсирован (https://blog.docker.com/2014/12/advancing-docker-security-do.../) релиз инструментария для управления изолированными Linux-контейнерами Docker 1.4, предоставляющего высокоуровневый API для манипуляции контейнерами на уровне изоляции отдельных приложений. В частности, Docker позволяет не заботясь о формировании начинки контейнера запускать произвольные процессы в режиме изоляции и затем переносить и клонировать сформированные для данных процессов контейнеры на другие серверы, беря на себя всю работу по созданию, обслуживанию и сопровождению контейнеров. Код Docker написан на языке Go и распространяется (https://github.com/dotcloud/docker/) под лицензией Apache 2.0.Инструментарий базируется на применении встроенных в ядро Linux штатных механизмов изоляции на основе пространств имён (namespaces) и групп управления (cgroups). Для создания контейнеров предлагается использовать libcontainer (обёртка над namespaces и cgroups), также возможно применение lxc (http://lxc.sourceforge.net/), libvirt, systemd-nspawn и других систем изоляции. Для формирования контейнера достаточно загрузить базовый образ окружения (docker pull base), после чего можно запускать в изолированных окружениях произвольные приложения (например, для запуска bash можно выполнить "docker run -i -t base /bin/bash").
Из добавленных в Docker 1.4 новшеств (https://github.com/docker/docker/blob/master/CHANGELOG.md) можно отметить:
- Новый драйвер для организации хранилища поверх многослойной файловой системы OverlayFS (http://www.opennet.me/opennews/art.shtml?num=40947), код которой вошёл в состав ядра Linux 3.18 (http://www.opennet.me/opennews/art.shtml?num=41210);
- В управляющий демон добавлена опция "-label" для установки меток в форме "ключ=значение", выводимых при выполнении команды "docker info";
- Поддержка установки переменных окружения через указание в Dockerfile опции "ENV name=value name2=value2...";
- В вывод команды "docker info" добавлено отображение полей с идентификатором и именем;
- Возможность фильтрации событий по имени события, контейнеру и образу окружения;
- Команда "docker cp" расширена поддержкой копирования данных из разделов контейнера.Одновременно доступен корректирующие выпуск Docker 1.3.3, в котором устранены три уязвимости (https://groups.google.com/forum/#!msg/docker-user/nFAz-B-n4B...) (проблемы также исправлены в Docker 1.4.0), которые были обнаружены в процессе аудита после выявления (http://www.opennet.me/opennews/art.shtml?num=41124) в ноябре двух критических проблем с безопасностью. Уязвимости проявляются при использовании готовых образов или образов, собранных Dockerfile, загруженных из сторонних непроверенных источников. Как и прошлые уязвимости, новые проблемы позволяют выполнить код или получить доступ к внешней ФС в процессе запуска или обработки специально модифицированного образа контейнера.
- CVE-2014-9356 - возможность записи во внешние части ФС и выхода за пределы контейнера через манипуляции с абсолютными символическими ссылками;
- CVE-2014-9357 - повышение привилегий (выполнение кода с правами root) в процессе декодирования специально оформленных архивов LZMA (.xz);
- CVE-2014-9358 - проблемы с проверкой идентификатора образа контейнера, которые могут быть использованы для подмены загружаемого из репозитория образа или выхода за пределы допустимого файлового пути.
Дополнительно можно отметить публикацию (http://blog.docker.com/2014/12/announcing-docker-machine-swa.../) компанией Docker трёх новых инструментов:- Docker Machine (http://github.com/docker/machine) - система для быстрого развёртывание хостов в гостевых окружениях систем виртуализации, предназначенных для организации контейнерной виртуализации приложений на основе Docker. Осуществляет создание начинки сервера, установку на него Docker и настройку клиента для работы с данным сервером. Поддерживается создание серверов в виртуальных окружениях VirtualBox, Digital Ocean и Microsoft Azure;
- Docker Swarm (https://github.com/docker/swarm/) - средства кластеризации для упакованных в контейнеры приложений. Предоставляет управлять кластером из нескольких хостов Docker (например, созданных с использованием Docker Machine) в форме работы с одним виртуальным хостом. Так как Swarm использует штатный Docker API, он может применяться для управления и другими поддерживающими данный API инструментами, такими как dokku, fig, krane, flynn, deis, docker-ui, shipyard, drone.io, Jenkins;- Docker Compose (https://github.com/docker/docker/issues/9459) - система поставки приложения с разделением на несколько контейнеров.
URL: https://blog.docker.com/2014/12/advancing-docker-security-do.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41251
Подумываю над реализацией запуска X-приложений таких, как Xfce4 DE, Firefox и т.д. внутри FreeBSD Jail. В чём может быть принципиальная трудность этого? Способы решения? (Все необходимые приложения, библиотеки и xorg-server 1.12.4 уже есть внутри клетки. Клетка работает — консольные приложения запускаются.
В LXC Х-приложения уже давно запускают, а ты жди своего docker.exe. Всё равно, кроме вантуза у тебя ничего больше не вращается.
1. Мы хотим «ня» и прочие прозрачности/OpenGL.
Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.
Тогда export DISPLAY=host.machine.domain:0, и понеслась.
На основной системе только надо выгрести из флагов X-сервера «-nolisten tcp», и зашарить домашнюю директорию с контейнером (ну, или, хотя бы, .Xauthority из неё).
> 1. Мы хотим «ня» и прочие прозрачности/OpenGL.
> 2. Мы обойдёмся AIGLX (если он есть), или вообще на OpenGL нам наплевать.Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано могу лишь догадываться, и по моим догадкам, на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче как няшно отрисованные окошки. Крузис конечно будет тормозить, но на то он и крузис. Или мои догадки неверны? Чессово лень впиливать в систему что-нибудь композитное, только для того, чтобы посмотреть.
> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть /dev/shm в контейнер? Ну не будет direct render'а, но всё ж клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через сокет серверу. Или это никак? Или это опять же кранты изоляции?
> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
> просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализованоНе страдают. Более того, раньше оно через него обычно и работало.
>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
> Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
> /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
> клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
> сокет серверу. Или это никак? Или это опять же кранты изоляции?Да смотря какая у вас цель. Если вам 3D нужно, почему дать доступ к видеокарте это "кранты изоляции"? А если вам важна изоляция, из которой (кто-то другой, а не ваша конкретная прога) не выберется, зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые вещи, через тот же браузер куча других векторов атаки (изолируете доступ к файликам на хост-системе, а у вас тем временем уведут куки от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).
>> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX? Я
>> просто не пользуюсь всей этой хренью; внутрь не заглядывал, как реализовано
> Не страдают. Более того, раньше оно через него обычно и работало.«Вот ващще-ващще раньше» оно работало и до появления AIGLX в природе. :)
Через специальный X-сервер.
>>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
>> Смерть. Бесспорно. Но... а возможно ли отказаться от dri и как-то прокинуть
>> /dev/shm в контейнер? Ну не будет direct render'а, но всё ж
>> клиенту не придётся сериализовывать всякие там текстурки и прокидывать их через
>> сокет серверу. Или это никак? Или это опять же кранты изоляции?
> Да смотря какая у вас цель. Если вам 3D нужно, почему дать
> доступ к видеокарте это "кранты изоляции"?Потому что «до первого бага».
Примерно, как PCI Pass-through в Xen'е, и без VT-d.
Можно?
Можно.
Секурно?
Нет.> А если вам важна изоляция,
> из которой (кто-то другой, а не ваша конкретная прога) не выберется,
> зачем ей 3D? Десктопные приложения и полная изоляция вообще слабо совместимые
> вещи, через тот же браузер куча других векторов атаки (изолируете доступ
> к файликам на хост-системе, а у вас тем временем уведут куки
> от сайта, где хранятся данные кредитки типа paypal/google checkout/qiwi).Вот это совершенно верно.
Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)
> Но тут ведь, как обычно, надо понимать, что сама по себе изоляция не делает машину секурной, надо ещё и свои привычки поменять. :)Это надо понимать. Но не стоит также забывать, что привычки тоже не панацея.
> Эмм... А "ня" и "прочие прозрачности" как-то заметно страдают от AIGLX?Это зависит от.
Скажем, для «ня» и «прочих прозрачностей» в KDE/KWM OpenGL вообще не нужен — KWM умеет их делать через XRender.
Однако, «классика жанра» — Compiz — уже требует OpenGL, причём каких-то «высоких версий», чуть ли не минимум 2.1.> на глаз заметить разницу между AIGLX и DRI не удастся на столь простой задаче
> как няшно отрисованные окошки.Да, но вот вряд ли удастся сделать так, чтобы в процессе поворота Desktop Cube прям на двух гранях было видно, как играет что-нибудь в YouTube. :)
> Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна: отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции. По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).Отставить панику - /dev/mem никому давать не нужно.
А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение, а не грузить ОСhttp://maci0.wordpress.com/2014/05/02/run-any-applications-o...
>> Тогда контейнерная изоляция (любая на любой операционной системе) бессмысленна:
>> отдача внутрь контейнера /dev/mem и /dev/dri/* — это смерть любой изоляции.
>> По этой же причине бессмысленно внутри контейнера запускать X-сервер (ему это нужно обязательно).
> Отставить панику - /dev/mem никому давать не нужно.Да?
А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.
> А отдача /dev/dri почему смерть, если цель именно в том, чтобы дать
> конкретному приложению 3D? Конечно, в таком контейнере нужно запускать одно приложение,
> а не грузить ОСПотому, что DRM — это ещё и Generic DMA Engine.
Ну, то есть, это получится «изоляция до первого бага в драйвере».
> А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.Я говорил про линукс. Во фре вообще поддержку запуска иксов из под пользователя, без прав рута уже сделали?
> Ну, то есть, это получится «изоляция до первого бага в драйвере».
Контейнеры вообще не очень спасают, если баги такого уровня в ядре. Тут уж только виртуализация. И то, даже там находятся способы выбраться, если баги в ядре..
>> А вы проверьте: загрузите FreeBSD, скажите «sysctl kern.securelevel=2», чтобы закрыть /dev/mem, и стартаните Иксы.
> Я говорил про линукс. Во фре вообще поддержку запуска иксов из под
> пользователя, без прав рута уже сделали?Теоретически запуск xorg-server на FreeBSD из-под пользователя возможен: http://www.freshports.org/x11-servers/xorg-server/
— опцию сборки "SUID=on: Install the Xorg server with setuid bit set" можно перевести в "SUID=off" и собрать xorg-server без привелегированного запуска из-под пользователя. Но в таком режиме в X-ах может работать только root.
И как эта теория с практикой соотносится?
Упрощённо говоря, у нас есть некая машина, у которой извне доступен только SSH. Она не имеет ни графической карты, ни звуковой. Тем не менее, на ней установлено графическое окружение, включающее в себя десктопные X-приложения: Firefox, LibreOffice, Pluma, RSSOwl и т.д.. Возможно ли, имея этот набор ПО, воспользоваться удалённым запуском этих приложений с отрисовкой их окон на клиенте, у которого нормальная графическая карта, достаточно много ОЗУ, звуковая карта? Клиент должен по сути видеть окна, воспроизведение видео/звука и мог бы воздействовать на элементы управления удалённо запущенных программ. В каком направлении копать?
Лет 15 назад на той машине нужно было бы настроить ремотный дисплей , а проуинуть х-сессию (возможно ч\з ssh) ... Как оно сейчас яхз., наверно надо ставить vnc ?
Можно просто ssh -X. У тебя на цигвине должно тоже работать.
Или Ubuntu LTSP
> Можно просто ssh -X. У тебя на цигвине должно тоже работать.Цигвина не имею в наличии. Мне, вообще, нужно сделать сначала на Unix без всяких Windows.
> Или Ubuntu LTSP
Ты, похоже, ничего кроме Ubuntu не знаешь и не хочешь знать, понимать. Печально это.
http://www.bsdstore.ru/ru/xorg_in_jail.html
http://www.youtube.com/watch?v=YcfmRnxHRKYНо как уже писал - это только для себя, поскольку несекьюрно.
Я тоже хочу в клетках запилить, но только приложения, кажтому приложению по клетке, Думаю нужен доступ к экрану и звуковым устройствам, Т.е к сокету Unix для X11, в /tmp/.X11-unix, + правильно настроить DISPLAY, xhost, итд, по поводу звуеа думаю, что достаточно будет прописать монтирование в клетку звуковых устройств. Пока ничего не пробовал, работы много. Кто может что-то посоветовать по делу - напишите комментарий.
Для звука достаточно пробросить туда /run/user/${UID}/pulse
Вообще я выше ссылку давал про запуск скайпа в контейнере - systemd-nspawn'ом либо docker'ном. Никаких проблем нет так запускать любое.
переписан на го 1,4 ? =)
хоть бы один коммент по docker :) ну, раз все прошли мимо - и я пройду :)