В ядре Linux в коде трансляции uid/gid из пространства имён идентификаторов пользователей (user namespace) в основной набор идентификаторов выявлена (https://www.openwall.com/lists/oss-security/2018/11/16/1) уязвимость (https://bugs.chromium.org/p/project-zero/issues/detail?id=1712) (CVE-2018-18955 (https://security-tracker.debian.org/tracker/CVE-2018-18955)), позволяющая непривилегированному пользователю, имеющему полномочия администратора в изолированном контейнере (CAP_SYS_ADMIN), обойти ограничения безопасности и получить доступ к ресурсам вне текущего пространства имён идентификаторов. Например, при использовании общей файловой системы в контейнере и хост-окружении можно через прямое обращение к i-node прочитать содержимое файла /etc/shadow в основном окружении.
Уязвимость вызвана (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) ошибкой в ядре 4.15, внесённой в октябре прошлого года, и исправлена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) в выпусках 4.18.19, 4.19.2 и 4.20-rc2. Проблема присутствует в функции map_write(), определённой в файле kernel/user_namespace.c, и вызвана некорректной обработкой вложенных пространств идентификаторов пользователей, в которых используется более 5 диапазонов UID или GID. В частности, трансляция из пространства идентификаторов в ядре работает корректно, но не выполняется при обратном преобразовании (из ядра в пространство идентификаторов).Уязвимость присутствует в дистрибутивах, использующих ядро 4.15 и более новые выпуски, например, в Ubuntu 18.04/18.10 (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...), Arch Linux (https://security.archlinux.org/) и Fedorа (https://bugzilla.redhat.com/show_bug.cgi?id=1652681) (в (Arch (https://security.archlinux.org/package/linux) и Fedora (https://bodhi.fedoraproject.org/updates/?releases=F28&type=s...) уже доступно ядро 4.19.2 с исправлением). RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-18955) и SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-18955) не подвержены проблеме. В Debian и Red Hat Enterprise Linux поддержка "user namespace" по умолчанию не активирована, но она включена в Ubuntu и Fedora.
URL: https://www.openwall.com/lists/oss-security/2018/11/16/1
Новость: https://www.opennet.ru/opennews/art.shtml?num=49649
>Уязвимость вызвана ошибкой в ядре 4.15Но виноваты всё равно контейнеры!
Но виноваты все равно корпорации и автор npm leftpad лично!
Поттеринга забыл же!
> Поттеринга забыл же!Что, передумали фиксить и вместо этого объявили нот-а-багом?
Хотя то, что фанаты с незамутненной радостью и злорадством вынуждены пояснять "а вот тут Великий не виноват!", говорит уже о многом ))
>Но виноваты все равно корпорацииА не так что ли? Классических, понятных ugo rwx с нашлёпкой в виде chroot хватает всем смертным, современные фортеля с правами, контейнерами, изоляциями - это всё поветрия со стороны копрораций.
> А не так что ли? Классических, понятных ugo rwx с нашлёпкой в
> виде chroot хватает всем смертным, современные фортеля с правами, контейнерами, изоляциями - это всё поветрия со стороны копрораций.Очевидно же, что это все происки Заклятых Врагов:
man jail
HISTORY
The jail utility appeared in FreeBSD 4.0. (март 2000г)
джейлы бсдешные тоже не торт, там тоже маппить нужно юиды/гиды, чтобы в топе(в системе) норм видеть а не неизвестные.
uid/gid возьми из LDAP и будет тебе счастье где только угодно.
> uid/gid возьми из LDAP и будет тебе счастье где только угодно.ради одного узера в джейле мне лдап наворачивать? легче в самой системе такого же юзера создать
одна проблема - jail тоже требует рутовых прав - и не просто так это делает. А иначе будет:
jail: jail_set: Operation not permitted
никакого тебе userns...Потому что jail - он как раз об изоляции и безопасности, а не о том как уйти от dependency hell путем наворачивания слоев поверх слоев поверх слоев.
> одна проблема - jail тоже требует рутовых прав - и не просто
> так это делает. А иначе будет:
> jail: jail_set: Operation not permitted
> никакого тебе userns...
> Потому что jail - он как раз об изоляции и безопасности, а
> не о том как уйти от dependency hell путем наворачивания слоев
> поверх слоев поверх слоев.бесит за столько лет нормальный процесс монтирования и отмонтирования не придумали, крешится джейл процесс, а маунты висят, и хрен запустишь если не отмонтируешь.
Корпораций лишь в том смысле, что это попытка пресловутой экономии на персонале, то есть использовании копченных принесиподаев заместо квалифицированных админов и юзеров. Защита от дурака для дурака, если кратко. Но из этого ничего заведомо не может получиться хорошего, потому что это нарушение принципов юникса (та самая избирательность в выборе друзей, ага). А все такие нарушения ломают его целостность и приводят к предсказуемым последствиям. Не может любая домохозяйка управлять сложной системой, требующей реальных знаний и глубокого понимания. Не получается чуда.Но корпорации корпорациями, а эти поветрия находят большой энтузиазм в рядах кибервасянов, только что слезших с пальмы. Происходит повсеместно внедрение в защиту того элемента, от которого, собственно, она должна защищать.
Единственное, что можно сказать в качестве резюме по таким случаям — что скупой платит дважды. Нельзя экономить на мозгах. Нельзя нанимать дураков на сложные задачи.
>Но корпорации корпорациями, а эти поветрия находят большой энтузиазм в рядах кибервасяновДа, пожалуй, это пострашней будет.
> виде chroot хватает всем смертным,Проблема только в том что безопасность это если и улучшает то очень маргинально. А если сервис, даже работающий под юзером, ломанут - у него как-то многовато доступа получается в типовой системе.
До чего же дырявы линукс-контейнеры.
До чего же дырявы контейнеры.
Fixed.
Так чтоб оно дырявым не было - ядро изнавально должно было писаться с учетом таких хотелок. Но кто ж на момент начала написания реально существующих ОС о таком задумывался? А когда это потом сбоку на проволоку и скотч примотано...
> >Уязвимость вызвана ошибкой в ядре 4.15
> Но виноваты всё равно контейнеры!Да, эти все "спейсыс" - для контейнеров.
Но виновато всеравно сообщество, которое написало GNU/Linux!
Прочитал "мейнтейнеры", в принципе, разницы нет.
Естественно. В линуксе они тот ещё шлак с точки зрения безопасности.
> Естественно. В линуксе они тот ещё шлак с точки зрения безопасности.Контейнеры-то? Ну сломайте мне ovz.
> Ну сломайте мне ovz >= 4.15/fixed
Мишень - OpenVZ это такое дикое глюкало... его ломать не надо - оно просто падает при определенных нагрузках.
Тем более официально 'stable' там как г. мамонта - 2.6.32..
OVZ это единственные лiнупс контейнеры, которые работают, несмотря на ряд недостатков.
но поскольку совместимость с современным софтом у ядра 2.6 примерно никакая - больше пользы от выноса в этом случае линукса на помойку и установки freebsd. Там возможности внутриджейлового рута хоть как-то ограничены.
> но поскольку совместимость с современным софтом у ядра 2.6В контейнере оно покажется 3.2, помнится.
что установишь в текстовой строчке - так и будет. хоть 99.01
> В контейнере оно покажется 3.2, помнится.Я вам на любом ядре покажу любую цифирь. И чего? Как максимум это позволит программам глючить чаще и больше.
> поскольку совместимость с современным софтом у ядра 2.6 примерно никакаяИ с каким "современным софтом" несовместим 2.6.32 из RHEL6 ?
Софт не обращается к ядру напрямую и не видит ядра, софт работает с libc
Так опенвз постоянно критикуют поклонники продукции рэдхэт, говорят что они не работают с уродливым костылём под названием селинукс. И вообще патчить ядро дозволено только корпорации в красном головном уборе типа "шляпа".
просто у той корпорации это получается, а виртуозы застряли в ядре 2.6
у vz когда-то тоже получалось, но привычка к закрытию кода, и тот факт что разбежались разработчики (посмотрев кто работал над 2.6.32 и сейчас).
> и тот факт что разбежались разработчикиА это болотников "благодарить" надо -- Монахову мозги проэксплойтили, в итоге потеряли мотор проекта в виде Кирилла.
Да кто им мозги эксплойтил с их менеджментом? Такая уверенность фирмы в том что все будут до упора сношаться с их кастомными ядрами, поддерживаемыми абы как - здорово, конечно, но кроме самой этой фирмы такое "счастье" мало кому надо.Хостерам как-то проще оказалось на full virt переходить по мере того как гипервизоры становились все быстрее, virtio шел в массы и проч. Так юзеры не трахают мозг саппорту кучей дурных проблем и вообще могут ставить любую ось, за которую сами отвечают. И настраивают сами. Вгружая какие там кому надо модули ядра или что там у них. Без дергания саппортов компании.
А тем кто контейнеры для изоляции своих компонентов применял, кастомное ядро - как нож в спину. Вот для ovz почти и не осталось юзкейсов. Куда его такой красивый в таком виде девать?
> Контейнеры-то? Ну сломайте мне ovz.Погуглите "openvz exploit", чего уж там. Другое дело что бесплатно вам это никто не даст, хакеры тоже видите ли хотят чтобы копание в чужом гуано как-то компенсировалось. Да и если нашару или сильно массово отдать - школьники мигом положат хостинги, админы офигеют, эксплойт очень скоро перестанет работать. И все дружно пролетят.
Ну вот опять
Никогда такого не было.
> Например, при использовании общей файловой системыА посему общими должны быть только файло-помойки.
Да! Вот почему в proxmox обновление ядра прилетело.
вот эти ребята:
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
CC: Serge Hallyn <serge@hallyn.com>
CC: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> вот эти ребята:
> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>Примечательно, что LTS ветка ядра -- 4.14, а в Ubuntu используют 4.15
> RHEL и SUSE не подвержены проблеме. В Debian и Red Hat Enterprise Linux поддержка "user namespace" по умолчанию не активирована, но она включена в Ubuntu и Fedora.Так-то! Выбирай сердцем, голосуй кошельком. :)
Ещё у кого-то есть вопросы про блидинг едж? :)
А ничего что в дистрах с отрубленными user namespaces, те же вещи делаются только с правами рута?
> А ничего что в дистрах с отрубленными user namespaces, те же вещи
> делаются только с правами рута?Какие конкретно вещи?
В нормальных юниксах ничего не должно делаться от рута юзером или юзером с повышенными правами. Рута выдают исключительно квалифицированному админу. Обычным юзерам выдали по домашнему каталогу для жизни, и больше ничего в системе им не принадлежит. Это основа основ безопасности любого юникса.
А если вы хотите, чтоб как в Windows 98 было, где всем можно всё, то добро пожаловать в опасный и заманчивый мир увлекательных приключений с регулярной переустановкой всего с нуля.
> В нормальных юниксах ничего не должно делаться от рута юзером или юзером с повышенными правами. Рута выдают исключительно квалифицированному админу.Это всё влажные мечты. Да было бы круто, если бы к каждому пользователю убунты приставили бы по квалифицированному админу, с поиском работы у васянов проблем бы не было. Но это всё влажные мечты, потому что при таких требованиях к unix'у, этот ваш unix никому не будет нужен. То есть ты всё равно останешься невостребованным на рынке труда.
То есть, то что кибервасяны-сантехники, переодически ходят и починяют пользовательские Windows/MacOS это как бы нормально?
С общепринятой точки зрения, наверное нет особой разницы, хотя если сбылась бы мечта Стива Джобса, то PC не нужен. Все в гаджете под названием ipad/iphone, который вам не принадлежит.
да мы и линуксы ТАК починить могем - reboot/install/next/next/format - yes!/ok!и, в принципе-то, любой васян справится. (какой еще архив любимого котика - ты чего, как лох, его не в облаке хранил?)
> да мы и линуксы ТАК починить могем - reboot/install/next/next/format - yes!/ok!Да нет там никакого next и формата как такового. Придет автоматическая система деплоймента, вкатит данные на диск и уберется восвояси. Так что никто ничего не кликает даже. Когда машин много, клацать next на каждой из них - много чести.
> Ещё у кого-то есть вопросы про блидинг едж? :)(в Arch и Fedora уже доступно ядро 4.19.2 с исправлением)
а что именно в нем нового поломали - владельцы узнают немного позже.
Если ваши контейнеры которые имеют доступ в сеть имеют флаг cap_sys_admin это уже проблема в голове.
Весь смысл контейнеров, чтобы иметь изолированный root
cap_sys_admin это уже деизоляция.
> cap_sys_admin это уже деизоляция.Это по задумке фэйковый рут. Карманный. Имеющий полномочия только в своем загончике.
> usernsСледующий!
а пока ты просто даешь рута основной системы всем, кому нужно банально запустить что-то в контейнере?Ну продолжайте, продолжайте...
sudo с привязкой к паре юзер - прикладуха ?
Это типа лечения подорожником. Применять можно только по причине невежества.
Приложения в своей работе обычно читают и пишут файлы. Путем всяких хитрых манипуляций их можно заставить читать и писать совсем не те файлы, на которые рассчитывал дающий sudo.
> sudo с привязкой к паре юзер - прикладуха ?И в результате этот юзер потом сможет сисколами по всей системе шариться, в основном namespace. Делая многовато лишнего.
Глупый живящий в собственном коде.
Только разработчики ядра добавляют бэкдор и тут же их планы раскрывают..
Ну тут одно из двух, либо ошибка в ядре, либо манифест приличного поведения института благородных девиц.