Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
Сообщение от opennews (??), 11-Фев-19, 23:33
В runc (https://github.com/opencontainers/runc), инструментарии для запуска изолированных контейнеров, выявлена (https://seclists.org/oss-sec/2019/q1/119) критическая уязвимость (CVE-2019-5736 (https://security-tracker.debian.org/tracker/CVE-2019-5736)), позволяющая из подготовленного злоумышленником изолированного контейнера подменить исполняемый файл runc и получить root-привилегии на стороне хост-системы. Уязвимость затрагивает все системы контейнерной изоляции, использующие runtime runc, включая Docker, cri-o, containerd, Kubernetes, Podman и flatpak (https://github.com/flatpak/flatpak/releases/tag/1.2.3). Также отмечается, что аналогичная уязвимость присутствует в инструментариях LXC и Apache Mesos. Суть (https://www.redhat.com/en/blog/it-starts-linux-how-red-hat-h...) уязвимости в возможности запуска исполняемого файла runc внутри контейнера, но его исполнения в контексте хост-системы. Например, атакующий может заменить /bin/bash в контейнере на скрипт, вызывающий /proc/self/exe, который ссылается на исполняемый файл runc. При выполнении "docker exec" и запуске runtime-ом подменённого /bin/bash будет выполнен файл, на который ссылается /proc/self/exe, а именно runc на стороне хоста. После этого атакующий может через модификацию /proc/self/exe внести изменение в исполняемый файл runc на стороне хост-системы. Для проведения атаки требуется выполнение пользователем с правами root операции создания нового контейнера на основе подготовленного атакующим образа или подключения к существующему контейнеру (достаточно выполнения "docker exec"), к которому ранее атакующий имел доступ на запись. Проблема не блокируется профилем по умолчанию AppArmor и правилами SELinux в Fedora (процессы контейнера запускаются в контексте container_runtime_t). При этом проблема не проявляется при корректном использованием пространств имён идентификаторов пользователя (user namespaces) или при использовании режима  "enforcing" SELinux в RHEL. Уязвимость уже устранена в RHEL, Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1674489), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...) и SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2019-5736), но остаётся неисправленной в Debian (https://security-tracker.debian.org/tracker/CVE-2019-5736). Решающие проблему патчи подготовлены для runc (https://github.com/opencontainers/runc/commit/0a8e4117e7f715...) и LXC (https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb8...). Рабочий прототип эксплоита планируют опубликовать 18 февраля. URL: https://seclists.org/oss-sec/2019/q1/119 Новость: https://www.opennet.dev/opennews/art.shtml?num=50130
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

3. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
Сообщение от Аноним (3), 12-Фев-19, 00:16
Давно пора понять, что выполнение чего-либо с правами root в контейнере аналогично полной компрометации всей системы. User namespace не лучше, уже на столько грабель наступили и ещё предстоит наступить.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+4 +/–
	Сообщение от Аноним (5), 12-Фев-19, 00:34
	This attack is only possible with privileged containers since it requires root privilege on the host to overwrite the runC binary. Unprivileged containers with a non-identity ID mapping do not have the permission to write to the host binary and therefore are unaffected by this attack.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от хотел спросить (?), 12-Фев-19, 01:40
	а по умолчанию контейнер какой?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	10. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от виндотролль (ok), 12-Фев-19, 03:03
	Смотря кто запускает. Если запускает рут (или пользователь, который может писать в /usr/bin/runc), то привелегированный, otherwise — в пролете.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	21. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+4 +/–
	Сообщение от нах (?), 12-Фев-19, 09:52
	> Смотря кто запускает. совершенно неважно, кто его запускает, лапочка. Потому что на самом деле его запускает, сюрприз, docker-daemon, и таки да - от рута. Потому что только рут и может создавать все эти прекрасные неймспейсы, монтировать слои трэша и п-ца один поверх другого и выполнять еще кучу стремных действий. Как только ты дал юзеру права на docker socket - ты ему дал рута, сюрприз, сюрприз. другое дело, что внутри контейнера процесс с pid1 вовсе не обязан быть рутовым, но это множится на ноль принятыми способами запуска демонов, что в контейнере, что нет. Нерутовый докер встречается все больше в абстрактно-сферическом вакууме, да и там не работает без кучи костылей и подпорок. Ну а поскольку тут речь идет о заведомо подброшенном врагами образе (который типовой лох конечно же тащит неглядя с хаба) - разумеется, даже если  и не запустят его не заморачиваясь, "всегда так делаем!", предусмотрительный автор предусмотрит вывод сообщения "запуск от юзера планируется в следующей major версии, а пока не выпендривайтесь, запускайте как все" - и ты ему совершенно не удивишься, ибо у всех так.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	34. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–3 +/–
	Сообщение от хотел спросить (?), 12-Фев-19, 11:58
	>[оверквотинг удален] > другое дело, что внутри контейнера процесс с pid1 вовсе не обязан быть > рутовым, но это множится на ноль принятыми способами запуска демонов, что > в контейнере, что нет. Нерутовый докер встречается все больше в абстрактно-сферическом > вакууме, да и там не работает без кучи костылей и подпорок. > Ну а поскольку тут речь идет о заведомо подброшенном врагами образе (который > типовой лох конечно же тащит неглядя с хаба) - разумеется, даже > если  и не запустят его не заморачиваясь, "всегда так делаем!", > предусмотрительный автор предусмотрит вывод сообщения "запуск от юзера планируется в следующей > major версии, а пока не выпендривайтесь, запускайте как все" - и > ты ему совершенно не удивишься, ибо у всех так. Т.е. VPS это полноценная изоляция насколько позволяет Spectre (ну или Epyc Rome c шифрованием клиентской памяти). А Docker и другие контейнеры - это адская отложенная дыра и никакой изоляции? Накой черт тогда все вокруг онанируют на эти контейнеры? Они же должны сдохнуть как и Електрон. Когда вышел дотнет коре с поддержкой контейнеров, все прям рассыпались в диферамбах. Типа наконец-то сделали, красавцы... А по-хорошему надо было застрелить того индуса, который это придумал.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	35. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+3 +/–
	Сообщение от нах (?), 12-Фев-19, 12:11
	> Т.е. VPS это полноценная изоляция насколько позволяет Spectre ну как бы побеги из этой изоляции через дырки в виртуальных или паравиртуальных драйверах тоже в общем случаются регулярно. Просто их никто не воспринимает как "notabug" ;-) > Накой черт тогда все вокруг онанируют на эти контейнеры? Они же должны сдохнуть как и Електрон. "а других разработчиков у меня для вас нет". Основное _сегодня_ использование контейнеров - это чтобы разбросанное хрюшками по полу хрючево пополам с навозом донести от их машины до прода, не заляпав все вокруг. И, как и электрон, оно будет жить вечно, потому что стало модно нанимать зато-дешовеньких, и девальвацию специальности уже никто и никогда назад не вернет.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	74. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от lurkr (ok), 13-Фев-19, 13:17
	распечатаю и повешу на стену
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	39. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от псевдонимус (?), 12-Фев-19, 13:02
	>А Docker и другие контейнеры - это адская отложенная дыра да может кроме опенвз >Накой черт тогда все вокруг онанируют на эти контейнеры? Переносимост По этой же причине не сдохнет и эектрон
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	48. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от Аноним (48), 12-Фев-19, 15:31
	> да может кроме опенвз Вы где видели официально стабильный Openvz на ядра выше 2.6.32 ?.. вот вот.. труп оно.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	55. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от нах (?), 12-Фев-19, 17:56
	>>А Docker и другие контейнеры - это адская отложенная дыра > да может кроме опенвз смешно, но его пилили как раз для управления ресурсами в большей степени, чем для надежной изоляции (точнее, тогда меньше боялис-боялис страшного и ужастного хакера, и гораздо больше - долбоящера ,который сожрет все ресурсы дохлого хоста с сотнями таких же рядом) ну правда его нормальные программисты пилили, не "программисты на go"
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	57. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от псевдонимус (?), 12-Фев-19, 19:35
	>>>А Docker и другие контейнеры - это адская отложенная дыра >> да может кроме опенвз > смешно, но его пилили как раз для управления ресурсами в большей степени, > чем для надежной изоляции я про это собствено и написа
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	70. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–3 +/–
	Сообщение от RNZ (ok), 13-Фев-19, 09:40
	> Накой черт тогда все вокруг онанируют на эти контейнеры? Потому-что быстрее, памяти жрёт меньше, управление контекстом и нагрузкой предсказуемее, т.к. работает одно ядро на всё - хост и контейнеры. В VPS, работает по отдельному ядру на хост и каждую VM.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	76. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от псевдонимус (?), 13-Фев-19, 13:51
	>работает одно ядро на всё - хост и контейнеры. Еси ты про процессорное ядро то ты не прав
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	87. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+2 +/–
	Сообщение от RNZ (ok), 13-Фев-19, 22:51
	>>работает одно ядро на всё - хост и контейнеры. > Еси ты про процессорное ядро то ты не прав Ещё про пушечное ядро скажи. Про kernel речь - https://en.wikipedia.org/wiki/Kernel_(operating_system)
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	88. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от псевдонимус (?), 13-Фев-19, 22:59
	Тогда верно И это похо
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	38. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Owlet (?), 12-Фев-19, 12:49
	> Потому что на самом деле его запускает, сюрприз, docker-daemon, и таки да - от рута. Потому что только рут и может создавать все эти прекрасные неймспейсы, монтировать слои трэша и п-ца один поверх другого и выполнять еще кучу стремных действий. И как тогда podman без рута работает по-твоему?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	61. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от виндотролль (ok), 12-Фев-19, 21:16
	> Потому что на самом деле его запускает, сюрприз, docker-daemon, и таки да - от рута. Потому что только рут и может создавать все эти прекрасные неймспейсы, монтировать слои трэша и п-ца один поверх другого и выполнять еще кучу стремных действий. > Как только ты дал юзеру права на docker socket - ты ему дал рута, сюрприз, сюрприз. 100%? Т.е. докер не запускает pid1 контейнера в неймспейсе с маппингом <uid> 0 ? Я не знаком с докером досконально, но изоляция без user namespace имеет мало смысла, я б предположил, что они это делают. Кто-то из нас не понял суть уязвимости.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	71. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от нах (?), 13-Фев-19, 11:02
	>> Как только ты дал юзеру права на docker socket - ты ему дал рута, сюрприз, сюрприз. > 100%? докер - программа, работающая от рута, причем с максимально широкими правами - всякие аппарморы и группы в панике разбегаются, давая уроду дорогу. А управление ей ты дал левому васяну, как только добавил его в группу имеющих право доступа к сокету, ему больше вообще ничего уже в этой жизни не надо, точнее, он сам себе все возьмет, что только захочет. то что в ней нашлась и еще одна мелкая дырочка - что васян может быть нелевым, но запустить по дурости левый контейнер, который нештатным образом получит доступ к все той же докер-инфраструктуре на хосте (и станет опять же рутом) - на этом фоне смешное недоразумение.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	81. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от виндотролль (ok), 13-Фев-19, 18:52
	> докер - программа, работающая от рута, причем с максимально широкими правами - > всякие аппарморы и группы в панике разбегаются, давая уроду дорогу. А > управление ей ты дал левому васяну, как только добавил его в > группу имеющих право доступа к сокету, ему больше вообще ничего уже > в этой жизни не надо, точнее, он сам себе все возьмет, > что только захочет. да ладно? Даже если в ответ демон делает fork() и setuid()? Даже традиционной системы привилегий достаточно, чтоб сделать все безопасно. Конечно, легко ошибиться и наделать дыр. Но сделать безопасно можно. И еще раз, проблема проявляется в привелегированных контейнерах. Т.е. таких, где рут внутри == руту в хосте.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	92. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (92), 14-Фев-19, 23:59
	Наверное именно потому везде пихают аппармор и селинукс.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	93. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от виндотролль (ok), 15-Фев-19, 00:51
	> Наверное именно потому везде пихают аппармор и селинукс. > Конечно, легко ошибиться и наделать дыр Вот поэтому и ставят. Никогда не знаешь, где найдут очередную уязвимость. Удаленное исполнения кода и повышение привелегий случалось и доконтейнерную эпоху.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	62. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от виндотролль (ok), 12-Фев-19, 21:29
	https://docs.docker.com/engine/security/userns-remap/ вот жеж. Немного не так, как я ожидал, но суть в том, что сообщить демону, под кем запускать контейны — можно. А демон хоть под кем крутись — не важно.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	66. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от псевдонимус (?), 12-Фев-19, 23:03
	> https://docs.docker.com/engine/security/userns-remap/ > вот жеж. Немного не так, как я ожидал, но суть в том, > что сообщить демону, под кем запускать контейны — можно. > А демон хоть под кем крутись — не важно. Это и ест дыра Незя дават крутится "под кем хоче" Рут в контейнере не дожен превращатся в рут на хосте
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	72. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от нах (?), 13-Фев-19, 11:05
	> Это и ест дыра Незя дават крутится "под кем хоче" Рут в > контейнере не дожен превращатся в рут на хосте контейнер для этого неособенно и нужен - достаточно дать права левому юзеру на доступ к тому, что делается от рута - и необязательно напрямую. банальный chroot пользователям недоступен - но авторам докера невдомек, почему же это. "какой-то ваш замшелый unixway".
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	75. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от псевдонимус (?), 13-Фев-19, 13:31
	>банальный chroot пользователям недоступен Вот и именно! "Настоящий" (хостовый) рут дожен быт доступен токо админу хоста В бсдовых жайах это можно обеспечит через джай в джайе не стесняя при этом разработчика в современных lинуксовых "контейнерах" (какое говорящее название сразу возникает ассоциация с мусором) как видиsh
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	82. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от виндотролль (ok), 13-Фев-19, 18:54
	>>банальный chroot пользователям недоступен > Вот и именно! "Настоящий" (хостовый) рут дожен быт доступен токо админу хоста > В бсдовых жайах это можно обеспечит через джай в джайе не > стесняя при этом разработчика в современных lинуксовых "контейнерах" (какое говорящее > название сразу возникает ассоциация с мусором) как видиsh вот это вы упрямые. Рут в контейнере не обязательно равне руту в хосте! И если это так (а обычно на продакшнах это так), но уязвимость не проявляется.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	15. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от Аноним (3), 12-Фев-19, 07:50
	> Unprivileged containers with a non-identity ID mapping Читайте про user namespace я упомянул. Безопасность при user namespace не лучше чем просто root внутри из-за специфичных для него проблем, которые  регулярно продолжают находить.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	22. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от нах (?), 12-Фев-19, 09:56
	> Безопасность при user namespace не лучше чем просто root все таки лучше - в частности, вот от этой конкретной беды уберегло бы. то что реализация хромает на все восемь конечностей - и еще будет лет десять, а потом ее выкинут как немодную устаревшую технологию, это отдельная тема.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	23. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (23), 12-Фев-19, 09:58
	"При этом проблема не проявляется при корректном использованием пространств имён идентификаторов пользователя (user namespaces)"
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	37. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+2 +/–
	Сообщение от Аноним (37), 12-Фев-19, 12:48
	Которые в докере, например, не заюзать нормально из-за кучи ограничений (например, невозможность использования volume-ов)
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	54. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–3 +/–
	Сообщение от нах (?), 12-Фев-19, 17:52
	> Которые в докере, например, не заюзать нормально из-за кучи ограничений (например, невозможность > использования volume-ов) а как же "volumes - прошлый век, тру девляпс использует ансибль, всегда модифицируя содержимое контейнера изнутри"?! мне что, не ту методичку подложили?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	63. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от виндотролль (ok), 12-Фев-19, 21:31
	Можно пример, когда это надо?
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

4. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
Сообщение от erthink (ok), 12-Фев-19, 00:25
Красиво!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
Сообщение от 4eburashk (?), 12-Фев-19, 00:42
Ай молодца! Сколько всего сразу повалилось. Вот это понимаю unix-way. Еще бы хромы и системд туда же.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+11 +/–
	Сообщение от Аноним (7), 12-Фев-19, 01:12
	After some discussion with the systemd-nspawn folks, it appears that they aren't vulnerable (because their method of attaching to a container uses a different method to LXC and runc). Наконец-то особый путь Лёни оказался полезен.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+2 +/–
	Сообщение от Gannet (ok), 12-Фев-19, 03:20
	Wow, первый положительный коммент относительно systemd. Сам пользую systemd-контейнеры. Пока не жалею. Щас набежит толпа хейтеров...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–2 +/–
	Сообщение от Аноним (13), 12-Фев-19, 07:21
	> Щас набежит толпа хейтеров... Но ведь nspawn - это гораздо удобнее того же LXC.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–3 +/–
	Сообщение от GentooBoy (ok), 12-Фев-19, 07:40
	А микроскоп лучше молотка, ну кто бы спорил. Выключите свет они на свет лезут.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	9. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (9), 12-Фев-19, 02:20
	> Еще бы хромы и системд туда же из системд к сожалению никто не хочет код копипастить к себе в инит.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–4 +/–
	Сообщение от Аноним (12), 12-Фев-19, 03:39
	Что у вас повалилось? Какой вменяемый сидит под рутом
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	16. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от Онаним (?), 12-Фев-19, 09:29
	Каждый второй хипста с докерком, угу.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	19. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+3 +/–
	Сообщение от нах (?), 12-Фев-19, 09:43
	каждый первый, поскольку далеко не все можно запустить с -u, и даже то что в принципе можно - не оправдывает траходрома
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

17. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+4 +/–
Сообщение от Онаним (?), 12-Фев-19, 09:31
Вообще контейнеры - это адовый костыль. Был таковым, есть, и будет есть.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	28. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+2 +/–
	Сообщение от Аноним (28), 12-Фев-19, 11:35
	Это не костыль. Это попытка забивать гвозди микроскопом, а точнее использовать молоток для микробиологии. Контейнеры - отличный способ разделения ресурсов для доверенных приложений, но почему-то на каком то этапе применения контейнеров какой-то умственно-отсталый решил что они безопасные и должны изолировать и что факт получения рута в контейнере не эквивалентен компроментации всей системы. Оттуда всё и пошло.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	33. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+5 +/–
	Сообщение от нах (?), 12-Фев-19, 11:54
	разделение ресурсов для доверенных приложений неплохо обеспечивает операционная система. ну, во всяком случае, юниксподобная. Контейнеры изначально задумывались именно как слои дополнительной изоляции. (точнее, линуксные их реализации накрутили вокруг эклектичной свалки таких средств в ядре, не имеющей нормальных интерфейсов для пользователя) В настоящее время массово используются вовсе не для этого, а для деплоя в обход dependency hell и компенсации кривизны средств разработки с их привычками "вали все в home", поэтому смешно ожидать что что-то другое у них будет получаться хорошо.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	43. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Клыкастый (ok), 12-Фев-19, 14:06
	> В настоящее время массово используются вовсе не для этого, а для деплоя в обход dependency hell и компенсации кривизны средств разработки с их привычками "вали все в home", поэтому смешно ожидать что что-то другое у них будет получаться хорошо. Хорошо изложил.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	40. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–2 +/–
	Сообщение от псевдонимус (?), 12-Фев-19, 13:15
	Вооот Их создаваи дя руёжки ресурсами а не дя безопасности в отичие от тех же бсдовых кеток
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

20. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
Сообщение от via (??), 12-Фев-19, 09:45
На Убунте lxc запрягают через lxd, и, типа, пофик на эту дыру. Не? У меня runc в 18.04 вообще не установлен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	25. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от нах (?), 12-Фев-19, 10:04
	> На Убунте lxc запрягают через lxd, и, типа, пофик на эту дыру. Не? тебе - пофиг, никому твоя васян-локалхостовая поделка не нужна А дыра в lxc точно такая же как и в докере - причем авторы гордо заявляют что "поскольку мы давно написали на туалетной бумажке, что рутовые контейнеры небезопасТные, объявлять это уязвимостью мы не будем!" Правда, хотя бы соломки подложили, не "notabug".
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	26. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от via (??), 12-Фев-19, 11:18
	дыра то в runc?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	29. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от нах (?), 12-Фев-19, 11:43
	нет, в liblxc точно такая же.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	41. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от via (??), 12-Фев-19, 13:16
	https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... Задевает пакеты docker.io и runc.   lxd апдейтов не требует.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	53. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от нах (?), 12-Фев-19, 17:50
	> https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... ну конечно, кто ж у нас эксперты чье мнение по всем вопросам самое главное - пипл с каноникал орг. > Задевает пакеты docker.io и runc. > lxd апдейтов не требует. notabug...простите, does not requires cve. Я так понимаю, пройти по ссылке из самой новости и прочитать непосредственно мнение разработчиков lxc (с прилагаемым патчем) ты и по сей момент ниасилил?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	27. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (28), 12-Фев-19, 11:28
	>"поскольку мы давно написали на туалетной бумажке, что рутовые контейнеры небезопасТные, объявлять это уязвимостью мы не будем!" Но ведь они абсолютно правы. Контейнеры - это способ разделения ресурсов а не способ изоляции недоверенных приложений, следовательно это баг но не уязвимость.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	30. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от нах (?), 12-Фев-19, 11:48
	s for security, да. Правда, как раз lxc-то принципиально позиционировалась как lightweight-замена vm, от которой в общем принято ждать нормальной изоляции, а не плохого разделения ресурсов. Впрочем, беда всех оберток одна и та же - они все не считают своей проблемой проблему пользователя. "мы вам наслесарили поддержку user namespaces, остальные претензии к ядру, мопед не наш". А вот бсшдшники попали, у них jail традиционно часть системы, а не утилита где-то в sbin, не получается валить все на "эти там в ядре что-то недоделали, но наша утилита тут непричем". ;-)
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	42. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (-), 12-Фев-19, 13:58
	> А вот бсшдшники попали, у них jail традиционно часть системы, а не утилита где-то в sbin, не получается валить все на "эти там в ядре что-то недоделали, но наша утилита тут непричем". ;-) И почему тогда бсдами уже никто не пользуется, если они настолько лучше и продуманее?
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	44. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–2 +/–
	Сообщение от Клыкастый (ok), 12-Фев-19, 14:07
	Ровно по той же причине, по которой линукса нет на десктопах.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	45. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Аноним (-), 12-Фев-19, 14:26
	> Ровно по той же причине, по которой линукса нет на десктопах. Это учитывая, что классический десктоп стремительно вымирает, а на планшетах, хромбухах, телефонах, в телезвизорах совсем не бзды? Просто бсдшники любят рассказывать об академической правильности и крутости своих подходов, скромно умалчивая, что даже сами ими в реальности нигде кроме виртуалки не пользуются.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	46. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от Клыкастый (ok), 12-Фев-19, 15:02
	>> Ровно по той же причине, по которой линукса нет на десктопах. > Это учитывая, что классический десктоп стремительно вымирает Был вопрос и я ответил. К чему эти пространные оправдания с переводом темы и стрелок, совершенно неясно. Такое впечатление что вы, дорогой аноним, отвечаете на вопрос, который я не задавал.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	69. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от псевдонимус (?), 13-Фев-19, 07:13
	Панеты и хромыебуки не взетеи(продавеное в американские коы не в счёт)
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	80. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от анонн (?), 13-Фев-19, 18:39
	> Панеты и хромыебуки не взетеи(продавеное в американские коы не в счёт) Авторитетное мнение не имеюего даже заваявсейся вненей кавы ии магазина по бизости и пиуего уже третий ден каки-то ребусы?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	47. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+1 +/–
	Сообщение от нах (?), 12-Фев-19, 15:29
	> И почему тогда бсдами уже никто не пользуется дык вон там выше изложение, для чего на самом деле нужны нынче контейнеры. Этого в бсде нет и не будет никогда - патамушта-у-разработчика-линукс. В смысле, он вообще ничего другого кроме своей бубунточки не умеет, и до прода ее донести не рассыпав можно только завернув в контейнер (leak and radiation proof). А так - пользуются, те кому на самом деле юникс нужен, а не платформа для докера. И jail там именно как средство изоляции - тоже вполне пользуем, вот, к примеру, так: syslogd_program="/usr/sbin/jail" syslogd_flags="-l -n syslog -s 2 / $hostname $EXT_IP /usr/sbin/syslogd" то есть вообще ничего не трогая в штатной системной обвязке - стремную (в режиме без -ss ) зверушку отправили в отдельную помойку подальше от остальных. Ей там совершенно не плохеет (она не получает pid1, со всеми его обязанностями, она не отрезана от общей fs, ей нормально передает сигналы ротейтилка и т д) но если ее поломают - предстоит еще интересный квест по вылезанию из пространства, где нет ни одного постороннего процесса, сеть ограничена и доступ к сокетам остального сервера - на общих основаниях, а не как у локального процесса и т д. Нет, хочешь отдельную иерархию в fs или вовсе эмуляцию виртуалки с полноценным исполнением /etc/rc, собственным ssh внутри и т д - пожалуйста, но, как видим, можно и без. Проблема в другом - а кому он нужен сегодня, этот юникс? Нужно ж как-в-винде, только бесплатно. Исключения, конечно, есть, но их слишком мало, чтобы привлечь нормальных разработчиков, да еще способных одолеть барьер на входе. P.S. осторожно, в примере использован запрещенный синтаксис времен 4.x и еще он, скорее всего, подерется с protect. Новые-модные тенденции, они и тут норовят все испортить.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	67. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Gannet (ok), 13-Фев-19, 04:14
	Вот ты срёшь на убунточку, а сам кагбе мимоходом умолчал что сам пользуешь. Давай и мы посрём на твой дистр, чё, слабо, умник?
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	73. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от нах (?), 13-Фев-19, 11:16
	> Вот ты срёшь на убунточку, а сам кагбе мимоходом умолчал что сам "как прибили, так и держится". В смысле - чего клиент требует, из того куличик и слепим. Клиентов требующих не из дерьма и палок и способных за это заплатить - у меня, к сожалению, на горизонте  нет. А и появятся - не возьмусь. Клиент не вечен (даже если это какой-нибудь netflix), а строчка в резюме "построил Тадж-Махал в натуральную величину на freebsd" не принесет нынче успеха у следующих работодателей. В отличие от известной субстанции, и можно даже в масштабе 1:10000, но непременно на 1000 инстансов. > пользуешь. Давай и мы посрём на твой дистр, чё, слабо, умник? это ты на б-жественную десяточку намекаешь? Не советую, instant karma может настичь: http://bash.org/?163301
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	90. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Gannet (ok), 14-Фев-19, 22:42
	> это ты на б-жественную десяточку намекаешь? Не советую, instant karma может настичь: > http://bash.org/?163301 У кого что болит. Сочувствую тебе.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	91. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от Gannet (ok), 14-Фев-19, 22:44
	> "как прибили, так и держится". В смысле - чего клиент требует, из > того куличик и слепим. Клиентов требующих не из дерьма и палок > и способных за это заплатить - у меня, к сожалению, на > горизонте  нет. А и появятся - не возьмусь. Клиент не > вечен (даже если это какой-нибудь netflix), а строчка в резюме "построил > Тадж-Махал в натуральную величину на freebsd" не принесет нынче успеха у > следующих работодателей. В отличие от известной субстанции, и можно даже в > масштабе 1:10000, но непременно на 1000 инстансов. Потом сознания?
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	78. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от псевдонимус (?), 13-Фев-19, 14:20
	Я фряху испозую на роутере-файопомойке Нагад на неё Токо без "аргументов" вроде утф8 в консои В ней ест что пнут
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	51. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–3 +/–
	Сообщение от SysA (?), 12-Фев-19, 17:17
	Вообще-то контейнеры никогда не позиционировались как ВМы! Только админам локалхоста не видна разница.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	52. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+3 +/–
	Сообщение от анонн (?), 12-Фев-19, 17:41
	> Вообще-то контейнеры никогда не позиционировались как ВМы! Угу, а системда никогда не позиционировалась как "быстрый инит", помним-помним! https://web.archive.org/web/20110924020630/http://lxc.source.../ > The LXC package combines these Linux kernel mechanisms to provide a userspace container object, a  lightweight virtual system with full resource isolation and resource control for an application or a system. > LXC started out with an efficient mechanism (existing Linux process management) and added isolation, resulting in a system virtualization mechanism as scalable and portable as chroot, capable of simultaneously supporting thousands of emulated systems on a single server while also providing lightweight virtualization options to routers and smart phones. https://linuxcontainers.org/ > That is, containers which offer an environment as close as possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	77. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от SysA (?), 13-Фев-19, 13:52
	Для тех, кто в танке: > That is, containers which offer an environment as close as possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware. Здесь имеется ввиду ФУНКЦИОНАЛЬНОСТЬ, а не защита!
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	79. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от анонн (?), 13-Фев-19, 18:28
	> Для тех, кто в танке: >> That is, containers which offer an environment as close as possible as the one you'd get from a VM but without the overhead that comes with running a separate kernel and simulating all the hardware. > Здесь имеется ввиду ФУНКЦИОНАЛЬНОСТЬ, а не защита! Для тех, кто мерзнет вне танка: это современная формулировка. А что там с (так изящно проигнорированным: >> a  lightweight virtual system with full resource isolation and resource control for an application or a system.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	68. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
	Сообщение от Gannet (ok), 13-Фев-19, 04:16
	>> Вообще-то контейнеры никогда не позиционировались как ВМы! > Именно так и позиционироваис И старые п-уны да админы окахостов пытаис донести > мыс что это не совсем так Но кто учитыва мнение этих > дурачков? У тебя пальцы перебиты что-ли?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	64. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+2 +/–
	Сообщение от Аноним84701 (ok), 12-Фев-19, 22:35
	#60 > Именно так и позиционироваис И старые п-уны да админы окахостов пытаис донести мыс что это не совсем так Но кто учитыва мнение этих дурачков? > Не Сама реаизация инукс-контейнеров и всего производного от них уязвима Даже системдаун-контейнеры(которые тот же lхц) Похоже, оно еще и портит буквы 'л' и 'ъ', как и знаки препинания o_O …
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	65. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–2 +/–
	Сообщение от псевдонимус (?), 12-Фев-19, 22:47
	Просто я заи каву томатным соком Про постоянные дырки в lинукс-контейнерах будет что-нибуд? Норманые опенвз у вас быи тут говорят что они похие и вообще рип Но где же норманые?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

36. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	–1 +/–
Сообщение от Аноним (36), 12-Фев-19, 12:38
Я вообще с контейнерами познакомился, когда надо было чью-то кривую поделку на nodejs, с кучей варнингов при компиляции, собиравшуюся только gcc 4.9 на Ubuntu с определенной версией boost перетащить на другую машину. Очень жаль, что уязвимость нашли, на машине, куда перенес, один хрен никто докер обновлять не будет, ибо работает и хрен с ним ©
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	89. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."	+/–
	Сообщение от leonid (??), 14-Фев-19, 01:23
	> чью-то кривую поделку на nodejs, с кучей варнингов при компиляции, собиравшуюся только gcc 4.9 на Ubuntu с определенной версией boost перетащить на другую машину аминь, брат
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема