В инструментарии управления изолированными контейнерами LXC выявлена (http://openwall.com/lists/oss-security/2016/11/23/6) уязвимость (CVE-2016-8649 (https://security-tracker.debian.org/tracker/CVE-2016-8649)), позволяющая (https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1639345) при наличии прав root внутри непривилегированного контейнера (работающего в отдельном user namespace) получить доступ к файлам хост-системы и выполнить свой код вне изолированного окружения.

Атака может быть совершена при запуске в контейнере процессов при помощи утилиты lxc-attach. Пользователь root в контейнере имеет возможность влиять на работу утилиты lxc-attach, что, в сочетании с достаточно просто достигаемым состоянием гонки (https://ru.wikipedia.org/wiki/%D0%A1%D0%... при выполнении 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 (https://www.ubuntu.com/usn/usn-3136-1/) и ожидает исправления в Debian (https://security-tracker.debian.org/tracker/CVE-2016-8649), RHEL/CentOS (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-8649), Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1398243), Fedora EPEL (https://bugzilla.redhat.com/show_bug.cgi?id=1398245) и  SUSE/openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-8649). Патч (https://github.com/lxc/lxc/commit/81f466d05f2a89cb4f122ef7f5... для блокирования уязвимости принят в дерево исходных текстов LXC, но для полного устранения возможных альтернативных векторов атаки также требуется внесение исправлений (https://lists.linuxfoundation.org/pipermail/containers/2016-... в ядро Linux для реализации проверки прав доступа к ptrace с учётом user namespace.

URL: http://openwall.com/lists/oss-security/2016/11/23/6
Новость: https://www.opennet.ru/opennews/art.shtml?num=45573

• Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 12:35 , 27-Ноя-16
  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 12:57 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 13:14 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 13:18 , 27-Ноя-16
      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 16:11 , 27-Ноя-16
  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Anonymous_1, 14:46 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,username, 15:23 , 27-Ноя-16
      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,хомяк, 15:33 , 27-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,username, 16:53 , 27-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 08:20 , 28-Ноя-16
            • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 00:45 , 29-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,PnDx, 15:06 , 28-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 18:42 , 27-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,PnDx, 15:08 , 28-Ноя-16
            • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 17:31 , 28-Ноя-16
              • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Michael Shigorin, 18:19 , 28-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,pavlinux, 00:00 , 29-Ноя-16
      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 15:33 , 27-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 22:42 , 27-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 22:52 , 27-Ноя-16
  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 15:34 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 19:11 , 27-Ноя-16
      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 20:28 , 27-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 21:55 , 27-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 22:40 , 27-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 22:45 , 27-Ноя-16
            • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 22:55 , 27-Ноя-16
              • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 00:02 , 28-Ноя-16
          • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Валик228, 04:57 , 28-Ноя-16
            • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 07:32 , 28-Ноя-16
              • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 16:10 , 28-Ноя-16
                • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 22:12 , 28-Ноя-16
                  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 22:53 , 28-Ноя-16
                    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,angra, 23:10 , 28-Ноя-16
                      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 13:01 , 29-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 14:48 , 28-Ноя-16
  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 20:09 , 27-Ноя-16
  • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Michael Shigorin, 21:21 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 21:48 , 27-Ноя-16
    • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,KonstantinB, 22:00 , 27-Ноя-16
      • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Ванга, 16:54 , 28-Ноя-16
        • Уязвимость в LXC, позволяющая получить доступ к файлам вне к...,Аноним, 22:53 , 28-Ноя-16
• Свой OS template в openvz контейнере,seyko, 03:53 , 30-Ноя-16

Давать кому попало рута в контейнере - это уже заведомо хождение по минному полю. Такие уязвимости, боюсь, будут всегда.

> Давать кому попало рута в контейнере - это уже заведомо хождение по
> минному полю. Такие уязвимости, боюсь, будут всегда.

LXC просто изначально не хотели делать рута внутри контейнеров, ну а потом по-быстрому накрутили, вот и результат

Да фиг с ним, с lxc, тут основная проблема в ptrace().

Ну, то есть как. Не хотели, потому что ядро не обеспечивало достаточной изоляции само по себе. Проверки в юзерспейсе - это заведомо ненадежный способ.

> Ну, то есть как. Не хотели, потому что ядро не обеспечивало достаточной
> изоляции само по себе. Проверки в юзерспейсе - это заведомо ненадежный
> способ.

Вообще подобные уязвимости нормальны, пока технологию не начинают активно применять нет возможности протестировать ее целиком. Синтетические тесты не покрывают все возможные варианты проблем.

Мне LXC больше напоминает Linux-Vserver, но второй из этого списка уже слабо активен

Смысл тогда в контейнере, если рута не давать?)

Хм, ну поясни зачем тебе там рут, просто интересно.

Как запустить nginx без root?

Так же как и с рутом.
Единственная привилегия, которая может понадобиться вебсерверу, это возможность слушать на портах < 1024. Что вполне решается навешиванием атрибутов (привилегий) на бинарник nginx

> Что вполне решается навешиванием атрибутов (привилегий) на бинарник nginx

И опять наступаешь на те же грабли, только в профиль. Либо режешь права группе и навешиваешь на бинарник, запрещаешь некоторые системные вызовы, тогда да, возможно. И то из контейнера можно будет выйти через какую-нибудь уязвимость нулевого-дня.

Непривилегированные контейнеры с разрешенным CAP_NET_BIND_SERVICE

Порт за-DNAT-ить. Обычно приемлемо, если в conntrack не упирается. (Но где это проблема, там lxc с iptables'ами по фигу наверное, т.к. netmap и прочее интересное.)

> Как запустить nginx без root?

Уже дюжину лет как

sysctl security.mac.portacl.rules=uid:80:tcp:80

> Уже дюжину лет как
>

 
> sysctl security.mac.portacl.rules=uid:80:tcp:80 
> 

# sysctl -a | grep  security | wc -l
0
У Вас таки фрюха?

> # sysctl -a | grep  security | wc -l
> 0
> У Вас таки фрюха?

Ну да. Я думал, раньше кто догадается.
А что, в пингвины такие вещи еще не завезли? oO
Тогда пожалуйста:
https://github.com/freebsd/freebsd/blob/master/sys/security/...
Хотя у вас вроде как setcap + CAP_NET_BIND_SERVICE есть ;)

Да и в целом просто прикольный эксперимент - вон, пока не знали, накрутили 6 плюсов, теперь можно посмотреть, насколько классовая неприязнь преобладает над здравым смыслом )

Кстати, man grep
> -c    Выдает только количество строк, содержащих образец.
>

> Да и в целом просто прикольный эксперимент - вон, пока не знали

Кто как :)

> накрутили 6 плюсов

Держите седьмой для ровного счёта.

$ sysctl security.mac.portacl.rules=uid:80:tcp:80
sysctl: Permission denied

Оттака ..ня, ребяты

Начни с рассказа, зачем тебе вообще рут где-либо. Может в процессе и сам поймешь. Контейнер ничем особо не отличается от железной машины для большинства задач.

> Начни с рассказа, зачем тебе вообще рут где-либо. Может в процессе и
> сам поймешь. Контейнер ничем особо не отличается от железной машины для
> большинства задач.

что бы запускать свои сервисы - а не те которые хостер за меня решил запустить.
к пример потунелировать openvpn через 443 порт.

Тебе надо помочь сделать следующий шаг? Если рут тебе обычно нужен для запуска своих сервисов, то рут в контейнере тебе нужен ... для запуска в нем своих сервисов. Неожиданно, правда?

Расскажи это хостерам с openvz, они посмеются. А тем, кто заикнется про XEN и прочая, можно напомнить, сколько уязвимостей было там.

В openvz похожие уязвимости были.

Уязвимости находили практически везде. Объявишь весь софт минным полем и откажешься от него?

Это был ответ на "расскажи хостерам".

В целом же, openvz изначально сделан грамотно. Openvz - это прежде всего патчи на ядро, достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило.

lxc же это просто юзерспейсный набор инструментов, упрощающих использование linux containers/namespaces/cgroups. Говорить о его безопасности вообще не имеет смысла, его безопасность равна безопасности ядра. И патчи, подобные вот этой ерунде, на которую ссылка - это лечение симптомов, костыль, затыкающий один из бесконечного числа возможных векторов атаки.

Реально уязвимость в ядре, в реализации ptrace(). В ядре уязвимости всегда были и еще много найдут, их там исправят, это нормально. Ненормально пихать userspace-затычки на один частный случай и называть это security fix.

> В целом же, openvz изначально сделан грамотно

еще бы. долгое время тестировали на бесплатных юзерах, прежде чем закрыть его.
Все же помним - как SWSoft - (тогда так назывался) взял и закрыл и никому не давал свои патчи на ядро.

> достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило
> его безопасность равна безопасности ядра.

Ты уже отказался от дырявого линуксового ядра или еще ходишь по этому минному полю? Или ты вообще считаешь, что ходить по минному полю это нормально так как "В ядре уязвимости всегда были и еще много найдут, их там исправят, это нормально"? Тогда к чему вообще был пассаж про рута в контейнере?

Я имел ввиду linux containers в их текущем состоянии, а не какие-нибудь там абстрактные контейнеры.

Теперь стало понятней и я даже частично согласен. По-крайней мере давать чистого рута без отображения через namespaces точно не стоит. Но и с непривилегированными как видим могут быть некоторые проблемы.

> В целом же, openvz изначально сделан грамотно. Openvz - это прежде всего патчи на ядро, достичь безопасности на дырявом ядре за счет проверок в userspace там никому в голову не приходило.

в целом же, ты чушь морозишь несусветную ибо некомпетентен совершенно.
openvz 10 лет тому возможно таким и было. сейчас опенвз целиком работает на неймспейсе, цпусетах и прочих ядерных технологиях (как и lxc), авторами большей части которых и являются openvz-шники.

Целиком? Сам то пробовал, компетентный ты наш? Кое-какую функциональность с vzctl 4.x и ванильным ядром получить конечно можно, но это будет лишь жалкая тень openvz, уступающая lxc. Полноценная работа openvz возможна лишь с их ядром.

не тупи ;-)

openvz потихоньку сливается - все наработки переливая в ванилу.
скоро совсем сольется.

а ты можешь дальше использовать тестовый полигон OpenVZ.

Ничего себе степень альтернативной одаренности. Да если весь патч openvz перейдет в ванилу, то это будет просто праздник. Все бы так сливались.

нет сил свое тянуть, cgroups + linux-vserver наступают на пятки, клиенты уже нос воротят - когда в ответ на запрос исходников им дулю суют, вот и приходится сливать..

> linux-vserver наступают на пятки

Ты еще и из альтернативной вселенной пишешь?

а тебе Parallels сколько отстегнул ?

> Уязвимости находили практически везде. Объявишь весь софт минным полем и откажешься от
> него?

Компьютеры - минное поле. Срочно отказываемся от них и возвращаемся в пещеры! Мамонт стынет! /s

> Давать кому попало рута в контейнере - это уже заведомо хождение по
> минному полю. Такие уязвимости, боюсь, будут всегда.

Выделяя пользователю контейнер по сути на откуп отдают отдельную виртуальную систему, чтобы пользователь сам в ней всё настраивал. Root в контейнере при user namespace никаким образом не должен пересекаться с root-ом в основной системe.

> Давать кому попало рута в контейнере - это уже заведомо хождение по минному полю.

Смотря в каком.  Но особо воодушевлённые давно уж не верили, что LXC не для безопасности, а для удобства.

Жаль, с ovz containers что-то непонятное творится.

там просто уже некому делать вменяемый код.

> Смотря в каком

В linux containers, разумеется - в контексте новости. Solaris zones я не имел ввиду точно.

> Жаль, с ovz containers что-то непонятное творится.

Да вроде понятное - "дом свободный, живите кто хотите".

Так опенвз вроде слился с виртуоззо?

> Так опенвз вроде слился с виртуоззо?

openvz это подачка в виде Open Core от виртуозы.

Какой host-провайдере предоставляет возможность использовать свой OS-template для контейнеров openxz ? Почему-то большинство предлагают только ими приготовленные заготовкии. Своя ОС -- только при использовании KVM (в виде ISO)