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

"Выпуск инструментариев для управления контейнерами LXC 7.0 и LXD 6.8"	+/–
Сообщение от opennews (??), 30-Апр-26, 10:36
Сообщество Linux Containers опубликовало релиз инструментария для организации работы изолированных контейнеров LXC 7.0, предоставляющий   runtime, подходящий как для  запуска контейнеров с полным системным окружением, близких к виртуальным машинам, так и для выполнения непривилегированных контейнеров отдельных приложений (OCI). LXC относится к низкоуровневым инструментариям, работающим на уровне отдельных контейнеров. Для  централизованного управления контейнерами, развёрнутыми в кластере из нескольких серверов, на базе LXC развиваются системы Incus и LXD. Ветка LXC 7.0 отнесена к выпускам с длительной поддержкой, обновления для которых формируются в течение 5 лет (до 2031 года). Код LXC написан на языке Си и распространяется под лицензией GPLv2... Подробнее: https://www.opennet.me/opennews/art.shtml?num=65327
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+2 +/–
Сообщение от Аноним (-), 30-Апр-26, 10:36
Нам нужна новость по Copy Fail! Это же такой C moment!
Ответить | Правка | Наверх | Cообщить модератору

	3. Скрыто модератором	+/–
	Сообщение от Аноним (-), 30-Апр-26, 10:53
	AOSP к нему неуязвим фактически из-за очень строгих SELinux политик.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	–2 +/–
	Сообщение от penetrator (?), 30-Апр-26, 11:34
	и пою я песню про физические сервера, уже не первый год пою
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	21. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+1 +/–
	Сообщение от Аноним (21), 30-Апр-26, 12:45
	Потому что в вопросе не разобрался вообще
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	–1 +/–
	Сообщение от Аноним (-), 30-Апр-26, 12:09
	А,ещё свежая Pack2TheRoot. Уязвимы все дистрибутивы, которые используют PackageKit (Ubuntu, например). ~12 лет оставалась незамеченной. Copy Fail оставался незамеченным почти десятилетие.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	–1 +/–
Сообщение от Аноним (21), 30-Апр-26, 10:49
Как это на бубунту 26.04 или 24.04 поставить правильно? Я так понимаю что в родные пакеты к этим релизам оно ещё долго не попадёт
Ответить | Правка | Наверх | Cообщить модератору

	8. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+1 +/–
	Сообщение от hbfrehregsdgf (?), 30-Апр-26, 11:25
	Через у6людочный snapd
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Аноним (21), 30-Апр-26, 12:45
	не ну снап только в утиль
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	–2 +/–
	Сообщение от Аноним (14), 30-Апр-26, 12:06
	правильно - удалить убунту и поставить кашерную федору))
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	23. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Аноним (21), 30-Апр-26, 12:46
	там каши дофига?
	Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
Сообщение от dimuspav (ok), 30-Апр-26, 11:12
CVE-2026-31431 прозвище Сору Fail СРОЧНО: ИИ обнаружил нулевую уязвимость ядра Linux, которая рутует каждую дистрибуцию с 2017 года. Эксплойт помещается в 732 байта Python. Обновите ядро как можно скорее. Уязвимость имеет обозначение CVE-2026-31431, прозвище "Сору Fail", раскрыта сегодня Theori. Она тихо сидела в ядре Linux девять лет. Большинство багов эскалации привилегий в Linux капризны. Им нужен точный временной интервал (гонка), или утечка конкретных адресов ядра откуда-то, или тщательная настройка под каждую дистрибуцию. "Сору Fail" не нуждается ни в чём из этого. Это ошибка линейной логики, которая работает с первого раза, всегда, на любой mainstream-машине с Linux. Нападающему нужен лишь обычный учётный аккаунт пользователя на машине. Оттуда скрипт просит ядро выполнить некоторую криптографическую работу, злоупотребляет тем, как эта работа подключена, и в итоге записывает 4 байта в область памяти под названием "page cache" (высокоскоростная копия файлов Linux в RAM). Эти 4 байта можно направить на любую программу, которой доверяет система, например /usr/bin/su - Ярлык для получения рута. Результат: в следующий раз, когда кто-то запустит эту программу, она пустит нападающего как рута. То, что должно беспокоить больше всего: повреждение никогда не затрагивает файл на диске. Оно существует только в памяти Linux-копии этого файла. Если вы сделаете образ жёсткого диска потом, файл на диске будет точно соответствовать официальному хэшу пакета. Перезагрузите машину или просто создайте давление на память (любая нормальная нагрузка системы, требующая RAM), и кэшированная копия перезагрузится свежей с диска. Контейнеры тоже не спасут. Page cachе общий для всего хоста, так что процесс внутри контейнера может использовать эту уязвимость, чтобы скомпрометировать базовый сервер и добраться до других арендаторов. Первородный грех — это "оптимизация на месте" 2017 года в модуле крипто-ядра под названием algif aead. Она должна была сделать шифрование чуть быстрее. Изменение нарушило критическое предположение о безопасности, и никто не заметил девять лет. Этот баг потом ехал на всех обновлениях ядра с 2017 года и до сегодняшнего дня. Эта уязвимость затрагивает следующее: Общие серверы (dev-машины, jump-хосты, build-серверы): любой пользователь становится рутом Kubernetes и кластеры контейнеров: один скомпрометированный под уходит на хост CI-раннеры (GitHub Actions, GitLab, Jenkins): вредоносный pull request становится рутом на раннере Облачные платформы, запускающие пользовательский код (ноутбуки, песочницы агентов, serverless-функции): арендатор становится рутом хоста Хронология: 23 марта 2026: сообщено команде безопасности ядра Linux 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE 29 апреля: публичное раскрытие 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE Смягчение: обновите ядро до сборки, включающей mainline-коммит а664bf3d603d. Если не можете патчить сразу, отключите уязвимый модуль: echo "install algif_aead /bin/ false" > /etc/modprobe.d/ disable-algif.conf rmmod algif_aead 2>/dev/null || true Для окружений, запускающих недоверенный код (контейнеры, песочницы, CI-раннеры), полностью заблокируйте доступ к крипто-интерфейсу ядра AF ALG, даже после патча. Почти ничто легитимное в нём не нуждается, блокировка закрывает дверь на весь этот класс багов...
Ответить | Правка | Наверх | Cообщить модератору

	7. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+2 +/–
	Сообщение от Аноним (7), 30-Апр-26, 11:19
	А чего ты новость не оформил, а гадишь в коментах рандомной темы? Ты же ровно это же (только юез личной истерики) мог написать в новости и принести этим пользу, а не изображать белку-истеричку
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от dimuspav (ok), 30-Апр-26, 12:27
	я просто мимо шел, я "пешеход" безправный а отправка через форму залипает сорри PS в новость отправил - но это на модерации
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от dimuspav (ok), 30-Апр-26, 12:34
	прежде чем минусить прочитали бы любой школьник сможет подняться до рута просто запуском скрипт.py на любой сборке linux
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	25. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Аноним (25), 30-Апр-26, 14:03
	>гадишь в коментах Какие Вы добрые, когда возьмут за мягкое. Ядро, готовься к аудиту ИИ. Гордость ядерщиков - держись.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

5. Скрыто модератором	+/–
Сообщение от dimuspav_ (?), 30-Апр-26, 11:16
https://github.com/theori-io/copy-fail-CVE-2026-31431 СРОЧНО: ИИ обнаружил нулевую уязвимость ядра Linux, которая рутует каждую дистрибуцию с 2017 года. Эксплойт помещается в 732 байта Python. Обновите ядро как можно скорее. Уязвимость имеет обозначение CVE-2026-31431, прозвище "Сору Fail", раскрыта сегодня Theori. Она тихо сидела в ядре Linux девять лет. Большинство багов эскалации привилегий в Linux капризны. Им нужен точный временной интервал (гонка), или утечка конкретных адресов ядра откуда-то, или тщательная настройка под каждую дистрибуцию. "Сору Fail" не нуждается ни в чём из этого. Это ошибка линейной логики, которая работает с первого раза, всегда, на любой mainstream-машине с Linux. Нападающему нужен лишь обычный учётный аккаунт пользователя на машине. Оттуда скрипт просит ядро выполнить некоторую криптографическую работу, злоупотребляет тем, как эта работа подключена, и в итоге записывает 4 байта в область памяти под названием "page cache" (высокоскоростная копия файлов Linux в RAM). Эти 4 байта можно направить на любую программу, которой доверяет система, например /usr/bin/su - Ярлык для получения рута. Результат: в следующий раз, когда кто-то запустит эту программу, она пустит нападающего как рута. То, что должно беспокоить больше всего: повреждение никогда не затрагивает файл на диске. Оно существует только в памяти Linux-копии этого файла. Если вы сделаете образ жёсткого диска потом, файл на диске будет точно соответствовать официальному хэшу пакета. Перезагрузите машину или просто создайте давление на память (любая нормальная нагрузка системы, требующая RAM), и кэшированная копия перезагрузится свежей с диска. Контейнеры тоже не спасут. Page cachе общий для всего хоста, так что процесс внутри контейнера может использовать эту уязвимость, чтобы скомпрометировать базовый сервер и добраться до других арендаторов. Первородный грех — это "оптимизация на месте" 2017 года в модуле крипто-ядра под названием algif aead. Она должна была сделать шифрование чуть быстрее. Изменение нарушило критическое предположение о безопасности, и никто не заметил девять лет. Этот баг потом ехал на всех обновлениях ядра с 2017 года и до сегодняшнего дня. Эта уязвимость затрагивает следующее: Общие серверы (dev-машины, jump-хосты, build-серверы): любой пользователь становится рутом Kubernetes и кластеры контейнеров: один скомпрометированный под уходит на хост CI-раннеры (GitHub Actions, GitLab, Jenkins): вредоносный pull request становится рутом на раннере Облачные платформы, запускающие пользовательский код (ноутбуки, песочницы агентов, serverless-функции): арендатор становится рутом хоста Хронология: 23 марта 2026: сообщено команде безопасности ядра Linux 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE 29 апреля: публичное раскрытие 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE Смягчение: обновите ядро до сборки, включающей mainline-коммит а664bf3d603d. Если не можете патчить сразу, отключите уязвимый модуль: echo "install algif_aead /bin/ false" > /etc/modprobe.d/ disable-algif.conf rmmod algif_aead 2>/dev/null || true Для окружений, запускающих недоверенный код (контейнеры, песочницы, CI-раннеры), полностью заблокируйте доступ к крипто-интерфейсу ядра AF ALG, даже после патча. Почти ничто легитимное в нём не нуждается, блокировка закрывает дверь на весь этот класс багов...
Ответить | Правка | Наверх | Cообщить модератору

	11. Скрыто модератором	+/–
	Сообщение от yet another anonymous (?), 30-Апр-26, 11:40
	Это к AF_ALG sockets, приситствуют при соответствующем модуле (CONFIG_CRYPTO_USER=m). Хз, насколько многие его грузят.
	Ответить | Правка | Наверх | Cообщить модератору

	12. Скрыто модератором	+/–
	Сообщение от Аноним (12), 30-Апр-26, 12:04
	Было проверено мной, оно грузится само при выполнении эксплоита, работает на Debian stable (trixie).
	Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	–2 +/–
Сообщение от dimuspav_ (?), 30-Апр-26, 11:18
СРОЧНО: ИИ обнаружил нулевую уязвимость ядра Linux, которая рутует каждую дистрибуцию с 2017 года. Эксплойт помещается в 732 байта Python. Обновите ядро как можно скорее. Уязвимость имеет обозначение CVE-2026-31431, прозвище "Сору Fail", раскрыта сегодня Theori. Она тихо сидела в ядре Linux девять лет. Большинство багов эскалации привилегий в Linux капризны. Им нужен точный временной интервал (гонка), или утечка конкретных адресов ядра откуда-то, или тщательная настройка под каждую дистрибуцию. "Сору Fail" не нуждается ни в чём из этого. Это ошибка линейной логики, которая работает с первого раза, всегда, на любой mainstream-машине с Linux. Нападающему нужен лишь обычный учётный аккаунт пользователя на машине. Оттуда скрипт просит ядро выполнить некоторую криптографическую работу, злоупотребляет тем, как эта работа подключена, и в итоге записывает 4 байта в область памяти под названием "page cache" (высокоскоростная копия файлов Linux в RAM). Эти 4 байта можно направить на любую программу, которой доверяет система, например /usr/bin/su - Ярлык для получения рута. Результат: в следующий раз, когда кто-то запустит эту программу, она пустит нападающего как рута. То, что должно беспокоить больше всего: повреждение никогда не затрагивает файл на диске. Оно существует только в памяти Linux-копии этого файла. Если вы сделаете образ жёсткого диска потом, файл на диске будет точно соответствовать официальному хэшу пакета. Перезагрузите машину или просто создайте давление на память (любая нормальная нагрузка системы, требующая RAM), и кэшированная копия перезагрузится свежей с диска. Контейнеры тоже не спасут. Page cachе общий для всего хоста, так что процесс внутри контейнера может использовать эту уязвимость, чтобы скомпрометировать базовый сервер и добраться до других арендаторов. Первородный грех — это "оптимизация на месте" 2017 года в модуле крипто-ядра под названием algif aead. Она должна была сделать шифрование чуть быстрее. Изменение нарушило критическое предположение о безопасности, и никто не заметил девять лет. Этот баг потом ехал на всех обновлениях ядра с 2017 года и до сегодняшнего дня. Эта уязвимость затрагивает следующее: Общие серверы (dev-машины, jump-хосты, build-серверы): любой пользователь становится рутом Kubernetes и кластеры контейнеров: один скомпрометированный под уходит на хост CI-раннеры (GitHub Actions, GitLab, Jenkins): вредоносный pull request становится рутом на раннере Облачные платформы, запускающие пользовательский код (ноутбуки, песочницы агентов, serverless-функции): арендатор становится рутом хоста Хронология: 23 марта 2026: сообщено команде безопасности ядра Linux 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE 29 апреля: публичное раскрытие 1 апреля: патч закоммичен в mainline (коммит а664bf3d603d) 22 апреля: назначен CVE Смягчение: обновите ядро до сборки, включающей mainline-коммит а664bf3d603d. Если не можете патчить сразу, отключите уязвимый модуль: echo "install algif_aead /bin/ false" > /etc/modprobe.d/ disable-algif.conf rmmod algif_aead 2>/dev/null || true Для окружений, запускающих недоверенный код (контейнеры, песочницы, CI-раннеры), полностью заблокируйте доступ к крипто-интерфейсу ядра AF ALG, даже после патча. Почти ничто легитимное в нём не нуждается, блокировка закрывает дверь на весь этот класс багов...
Ответить | Правка | Наверх | Cообщить модератору

	13. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Аноним (12), 30-Апр-26, 12:05
	Мало того, что это спам, так ещё и ИИ слоп.
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Sm0ke85 (ok), 30-Апр-26, 12:14
	>СРОЧНО: ИИ обнаружил нулевую уязвимость СРОЧНО: ЧЕЛОВЕК обнаружил Лупня среди людей...!!! Этот Лупень постит нейрослоп с кривым оформлением!!!!
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	20. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от dimuspav (ok), 30-Апр-26, 12:36
	это cve и предыдущая новость о поднятии прав тоже указывает на ии пора привыкать и обзываться нехорошо))
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от Sm0ke85 (ok), 30-Апр-26, 15:06
	>и обзываться нехорошо)) Ну так вот выглядит для меня эти все нейро-новости и особенно "уязвимости", т.к. частенько те "уязвимости" - не более чем сферический конь в вакууме (конкретно за озвученную уязвимость не знаю, но думаю фиксы скоро прилетят, если серьезное что)
	Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
Сообщение от A.Stahl (ok), 30-Апр-26, 11:39
А что, с rm какие-то проблемы? Всегда отлично работал.
Ответить | Правка | Наверх | Cообщить модератору

	18. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
	Сообщение от dimuspav (ok), 30-Апр-26, 12:29
	не смог удалить задублировалось изза залипания формы модератор, удали пожалуйста
	Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск инструментариев для управления контейнерами LXC 7.0 и..."	+/–
Сообщение от Аноним (24), 30-Апр-26, 13:47
Расскажите про смысл контейнеров, если почти в каждом выпуске браузеров всплывают уязвимости, побивающие контейнер и уходящие в рут на хосте?
Ответить | Правка | Наверх | Cообщить модератору

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

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