The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Уязвимость в 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.ru/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 +/
Сообщение от 4eburashkemail (?), 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 +/
Сообщение от Gannetemail (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 и другие систе..."  +/
Сообщение от Gannetemail (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 и другие систе..."  +/
Сообщение от Gannetemail (ok), 14-Фев-19, 22:42 
> это ты на б-жественную десяточку намекаешь? Не советую, instant karma может настичь:
> http://bash.org/?163301

У кого что болит. Сочувствую тебе.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

91. "Уязвимость в runc и LXC, затрагивающая Docker и другие систе..."  +/
Сообщение от Gannetemail (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 +/
Сообщение от Gannetemail (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 | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Слёрм
Inferno Solutions
Hosting by Ihor
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2019 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру