root в ядре и обрушение системы через systemd (local)

p.s.

Зря по мелочам человека отвлекаешь. Он сейчас анализом занят

=)

не понял шутка или ты серьезно, но ему же патчиться, а не мне.;)

а так больше токсов не тянет

Иксперта с лора сразу видно.

А серьезные люди пишут: "Гигантские «дыры» в Linux вызывают крах системы и позволяют запускать любой код. Под угрозой Debian, Ubuntu, Red Hat.

В ядре и системном менеджере (systemd) Linux найдены опасные уязвимости. Они позволяют вызвать крах системы и выполнить произвольный код. Одной из них скоро исполнится семь лет, а вторая отметила свое шестилетие."

Иксперта с лора сразу видно.

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

Уныленький вброс с маргинальным юзкейсом, который всё равно подлатают.

сходи обновления проверь, вдруг уже прилетели

Я к тому, что человек не может делать два дела одновременно. Кроме того сама systemd себя бережёт. В материале было упомянуто, что уязвимость не могли использовать в 248 версии, так как мешала ошибка в коде этой версии. Но дальше «всё стало хорошо»

А зачем? У меня нет путей такой длины.

О нет, в коде бывают уязвимости, какой ужас.

Ну и что?

intelfx вот следствие нарушения KISS.

И плевать, что кода стало больше из-за возросших потребностей, которые надо покрывать, плевать, что вследствие развития проекта он усложняется.

то есть ты серьезно писал про анализ?:) епта:) по секрету: это не называется делом. это сидение на форуме с фигней) айтишники так отдыхают.

понял: у тебя и серверов с юзерами нет. ок. проходи мимо, маргинальный юзкейс.

Ну и плюс в этом вся культура сишки - кастовать числа неявно.

А допустим есть, и что? По твоему на каждом сервере есть доступ к возможности монтировать каждому первому длинные пути?

для fuse, думаю, есть

:) епта:)

Ну в голимый оффтоп же сейчас уйдём.

друг, ты его начал, правда? вот и заканчивай)

А я думаю, что не каждый сервер - хост контейнеров.

а я думаю, что это очень спорно вопрос, откуда можно монтировать fuse и создавать юзер-контейнеры.

если хочешь, можешь дать мне юзера на одном из своих серверов. посмотрим по факту=)

BPF

шо, опять?
Как-то понятия не имею, зачем оно (не)нужно, но судя по новостям - какое-то убер-решето

Соглашусь. Как впрочем и толерантность вашего KISS-решета к этой дыре или ещё какой-нибудь.

if an attacker FUSE-mounts a long directory (longer than 8MB), then systemd exhausts its stack

VLA/alloca?

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

Тем временем уже пропатчили похоже https://github.com/systemd/systemd/pull/20256

Соглашусь.

вот видишь:) если подумать

Как впрочем и толерантность вашего KISS-решета к этой дыре или ещё какой-нибудь.

ой-ой, полегче:) в моем init нет столько кода=)

это линукс

witch  # du -sb /sbin/init
150368	/sbin/init

это bsd:

moonfall ~ # du -b /sbin/init 
1230072 /sbin/init

да уж понятно дело. чего там патчить. мне это все нравится как proof of concept. сложный софт предсказуемо больше уязвимостей. но я все еще жду root'a.

В твоём init вообще ничего толкового нет. При этом процесс инициализации дёргает десятки/сотни отдельных приложений и библиотек, которые тоже могут иметь дыры и непредсказуемое поведение в маргинальных случаях. Система не загрузилась, но зато PID1 жив и ядро работает - отличное достижение! Сервер с работающим ядром и PID1 - сверхполезная штука, не то что сервер с systemd! (:

Ну бред же. От того что ты размазал монолит на over9000 отдельных компонентов софт проще не станет, и уязвимостей будет скорее всего только больше. Причина тому проста: монолиту не нужно думать о совместимости с чем бы то ни было и его компоненты разрабатываются синхронно. А куче компонентов - нужно, потому что они не разрабатываются синхронно и то, что работало идеально в одной версии может запросто развалиться в следующей.

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

Так что в плане надёжности я тут вижу теорему Эскобара. А в плане фичастости побеждает systemd.

нет, это ты пишешь бред. ты вообще работаешь по айти специальности?

монолиту не нужно думать

кому прости? думают люди обычно.

что работало идеально в одной версии может запросто развалиться в следующей.

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

Это было бы верно, если бы код systemd был лапшой, но это не так. Всё те же модули, но под одним зонтиком.

вот ты получил падение системы, т.к. один из модулей поломал весь зонтик. просто приведи мне пример того же самого в системе без systemd.

кому прости? думают люди обычно.

Для тебя перефразирую: людям, разрабатывающим монолитный проект.

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

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

Ты же эксперт в области систем без systemd - ты и приведи. Или ты решил не проводить аудит, а просто уверовать в швятой идеал KISS?

это сейчас пустое блабла. нет, posix и unix интерфейсам, на котором основан мой инит, уже пара десятков лет. нет, я не думаю, что ты прав. когда будет падение системы по вине моего инит, я тебе первый напишу. можешь, даже новость создать:)

нет, я слежу за CVE и сообщил тебе, как есть. «проблемы нет». ты не согласен. приводи свой пример. причем обрати внимание, тебе нужно привести не просто пример поломки при загрузке, а когда запуск приложения из юзер-спейса делает систему недоступной по вине _инит_. так происходит в сабжевой новости. ядро должно функционировать. твое ошибочное приложение должно вызвать ошибку в pid 1 и убить ВСЕ процессы. понимаешь?

Ещё разок: не нужно что бы у тебя упал init, достаточно что бы твой сервер перестал работать как тобой задумано. Ведь ты не будешь отрицать, что systemd выглядит таким дырявым благодаря тому что он содержит кучу компонентов, а твой KISS-подход выглядит таким «идеальным» лишь потому что вина ложится на отдельные компоненты?

нет, именно это я и отрицаю! общее число критических ошибок при KISS меньше. ты хочешь просто привести мне пример падения сервера по вине юзерспейс утилиты, но чтобы это не было проблемой ядра? ну попробуй.

Дополнительные условия пошли. С точки зрения полезности система с живым ядром и PID1 ничем не лучше системы, улетевший в kernel panic.

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

С точки зрения полезности система с живым ядром и PID1 ничем не лучше системы, улетевший в kernel panic.

ты не шаришь. я выводил сервера из ступора и могу тебе сказать, что это разные ситуации. более того, я ни разу не видел систему только с ядром и pid 1.

Без физического доступа? Просто с физическим доступом сервер можно вывести из любого ступора, кроме аппаратного отказа.

с сетевым доступом. если в процессах все еще висит ssh. я говорю, приведи мне в пример какой-нибудь mount, который все ломает, но так, чтобы это не было проблемой ядра.

Я вот подумал, этот эксплойт в общем-то ничем не примечателен. Ведь буквально каждый эксплойт с повышением привилегий можно использовать для того что бы шлёпнуть PID1.

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

Отцы не совсем дураки ведь были, когда говорили про яйца в корзинке. Уронил корзинку и все, ходи без яиц.

да, ты же все-таки появился на свет...

так в новости их два. один уже привычное повышение привилегий в ядре, второе - новинка, проблема systemd.

Причем тут я? Всегда учат избегать создания единственной точки отказа. В данном случае корзинка(системди) - это оно.