rulinux.net - Форум - Security - Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Tue, 29 Nov 2016 13:15:11 +0300

flatpak через что работает?

пёс его. с xdg-app не сталкивался. пока особой нужды его колупать вроде нет. может и стоит пофтыкать.. подозреваю, что у него своя специфика..

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Mon, 28 Nov 2016 21:47:21 +0300

flatpak через что работает? Сам он не требует рута для старта контейнера.

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Mon, 28 Nov 2016 18:17:07 +0300

p.p.s.:
не написал выше очевидное.. оч неплохим вариантом была/стала бы возможность не стартовать "контейнер" рутом. пусть будет привилегированный запуск с .. но не явный "рут".

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Mon, 28 Nov 2016 16:41:32 +0300

Не раздавать права оказывается недостаточно. Это было ещё номально когда по размещалось в ФС в виде одного бинарника, и отслеживалось на этом уровне. Вот сейчас и стремяться все засунуть в контейнер, чтобы было можно управлять доступом как единым контейнером, а не отслеживать на уровне файлов, которых овердофига. Но проблема поднятия привелегий через уязвимости остается, только теперь в другом виде.

камрад, попытаюсь ещё раз сказать мысль, что была не понята..

chroot, jail, sysjail и всё прочее в том же ключе - это "классика". оверхед - минимален. работает в пределах возможностей хоста (kernel + fs + memory). требует прямых рук одмина. и именно тут, на пункте "прямые руки", всё и заверте..

lxc, openvz и контейнеры "солярки", оч грубо говоря, - тот же chroot. все они стартуют "рутом". соответственно root в "контейнере" == container_started_pid (по уровню допуска). т.е. та же ситуёвина, что и при получении "рута" в chroot. для контроля прав на уровне приложений у нас собсно есть тот самый "одмин"(ц)(тм) со своим банхаммером, пилой, ножовкой, пивом и какой-то матерью: selinux, apparmor, polkit, udev, acl, attr и т.п. и т.д..

т.е. "out of scope activity", пмсм, можно пресечь не только рихтовкой кода lxc, что оч хор и радует несказанно, но и "сторонними" стандартными средствами, предназначенными именно для подобного рода работы. субъективно ессно.

p.s.:
ещё думаю, что "сложность" отслеживания и контроля любого исполняемого бинаря - фикция. если его не стартовать под тем самым "рутом", ога.. муторно, неинтересно, скучно, но никак не сложно. плюс всегда актуален вопрос доверия к "источнику". худший случай - static stripped binary - гемор, да. мы можем "верить" (пример: драйвер nVidia и весь non open source), стартануть в виртуалке под юзером или упороццо на декомпиляции. но. прежде всего мы сами решаем "а оно нам надо, стартовать вот Это?" и таки если "да, надо..", то "заходи, не бойся.. выходя - не плачь!"(ц)

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Mon, 28 Nov 2016 12:21:43 +0300

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Mon, 28 Nov 2016 01:47:07 +0300

Я ничего не понял. LXC как раз стремится снизить эти самые 'гораздо бОльшие "накладные расходы"', а раздавать рутовые права направо и налево - просто небезопасно. Раздашь налево - а там бэкдор, троян или баг какой-нибудь окажется. Или пользователь непреднамеренно совершит какую-нибудь ошибку.

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Sun, 27 Nov 2016 20:03:35 +0300

как-то это всё не нра.. есть какое-то субъективное ощущение, что постоянно из *nix хотят сделать M$. chroot, jail, sysjail - Ъ *nix механизмы "изоляции", но.. by system design "рут" в *nix таки обязан иметь права на железо. из-за этого собсно попёрла ставка на полную виртуализацию окружения, несмотря на гораздо бОльшие "накладные расходы".

извините за сумбур, когда читаю подобные "уязвимости" всегда думаю о некоем желании/стремлении урезать по умолчанию рутовые права, вместо того, чтобы тупо не раздавать эти самые права направо и налево.

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Sun, 27 Nov 2016 13:42:26 +0300

Это вам не джейлы, да

Re: Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Sun, 27 Nov 2016 13:01:10 +0300

В LXC вроде всегда рекомендовалось быть очень осторожными с рутовыми правами внутри контейнера

Уязвимость в LXC, позволяющая получить доступ к файлам вне контейнера

Sun, 27 Nov 2016 11:19:40 +0300

В инструментарии управления изолированными контейнерами LXC выявлена уязвимость (CVE-2016-8649), позволяющая при наличии прав root внутри непривилегированного контейнера (работающего в отдельном user namespace) получить доступ к файлам хост-системы и выполнить свой код вне изолированного окружения.

Атака может быть совершена при запуске в контейнере процессов при помощи утилиты lxc-attach. Пользователь root в контейнере имеет возможность влиять на работу утилиты lxc-attach, что, в сочетании с достаточно просто достигаемым состоянием гонки при выполнении lxc-attach, может привести к отключению ограничений и получению доступа к хост-системе. Уязвимость охватывает две проблемы: использование в lxc-attach данных из источников, подконтрольных пользователю контейнера, и возможность применения вызова ptrace для экземпляров lxc-attach, созданных в другом пространстве пользователей (root из контейнера может получить доступ к процессу, созданному во внешнем user namespace).

В частности, lxc-attach оставляет открытым файловый дескриптор к одному из файлов /proc на стороне хост-системы, что позволяет атакующему получить чего него доступ к остальным частям файловой системы, используя системные вызовы семейства openat(). В том числе через файловый дескриптор могут быть записаны данные в файлы /proc/PID/attr/current или /proc/PID/attr/exec на стороне хост-системы для установки меток AppArmor и SELinux к прикреплённому процессу, что даёт возможность отключить сброс привилегий для процесса, запускаемого при помощи lxc-attach.
Уязвимость уже устранена в Ubuntu Linux и ожидает исправления в Debian, RHEL/CentOS, Fedora, Fedora EPEL и SUSE/openSUSE. Патч для блокирования уязвимости принят в дерево исходных текстов LXC, но для полного устранения возможных альтернативных векторов атаки также требуется внесение исправлений в ядро Linux для реализации проверки прав доступа к ptrace с учётом user namespace.
http://openwall.com/lists/oss-security/2016/11/23/6
http://www.opennet.ru/opennews/art.shtml?num=45573