LINUX.ORG.RU
ФорумTalks

Поттеринг не успел выкинуть sudo, а его уже поимели

 , ,


0

2

Привет, ЛОР!

Нашёл интересное чтиво про инициативу Лёнечки по замене sudo на что-то там новое и улучшенное. Вкратце: dbus дыра, systemd дыра, всё дыра, сплоиты уже готовы заранее.

Немного цитат:

Here’s a quick PoC to demonstrate root permission hijacking by exploiting the fact «systemd-run» (the basis of uid0/run0, the sudo replacer) creates a user owned pty for communication with the new «root» process.

This isn’t the only bug of course, it’s not possible on Linux to read the environment of a root owned process but as systemd creates a service in the system slice, you can query D-BUS and learn sensitive information passed to the process env, such as API keys or other secrets.

Это, кстати, правда. Если открыть консольку и забрать там busctl --user monitor, можно много интересного увидеть, включая свои пароли, летающие из keyring в запрашивающее их приложение.

Ссылка: https://twitter.com/hackerfantastic/status/1785495587514638559

UPD:

Для тех, у кого нет тваттера, вот другая ссылка: https://github.com/hackerhouse-opensource/exploits/blob/master/systemd-run-tty.txt

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 3)

Ответ на: комментарий от cumvillain

Он у тебя есть.

В лялексе разве есть быстрое целевое переключение контекста мимо ядра? Типа, я хочу отдать процессор воооон тому процессу вот с таким-то пидом.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от cumvillain

К этим сисколам ещё надо добавить накладные расходы на переключение в ядро на модификации данных в клиенте. Их будет много, и вовсе не факт, что это будет быстрее, нежели одно большое копирование.

Задача «передать данные из одного процесса в другой» и так решается достаточно эффективно.

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

wandrien ★★
()
Ответ на: комментарий от wandrien

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

В смысле? Это обычный паттерн pub-sub. Его каждая первая шина типа ZMQ или Kafka реализует.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от wandrien

А системная шина сообщений тут при чем?

Чтобы её можно было использовать для такого же? Ты тут сам про отсутствие фич ноешь регулярно.

Банальный пример: десктопные нотификации и их обработка и отображение больше чем в одном месте.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от i-rinat

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

Все-таки HDD (Hate Driven Development) реальная парадигма)

goingUp ★★★★★
()
Ответ на: комментарий от hateyoufeel

Чтобы её можно было использовать для такого же? Ты тут сам про отсутствие фич ноешь регулярно.

Да, но нет.

Делать через dbus что-то типа вывода графики OGL или хотя бы основного канала обмена сообщениями оконной системы – безумие. dbus – это место встречи и не более. Далее агенты могут обменяться fd и использовать оптимизированный протокол с учётом особенностей задачи.

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

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

Посыл мой прост: «Хватит плодить фичи. Займитесь уже архитектурой.»

Банальный пример: десктопные нотификации и их обработка и отображение больше чем в одном месте.

Для отображения нотификаций не требуется пропускная способность в единицы гигабайт в секунду.

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

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)

можно много интересного увидеть

от юзера Failed to connect to bus: No such file or directory, из под root нет никакого выхлопа

amd_amd ★★★★★
()
Ответ на: комментарий от wandrien

Делать через dbus что-то типа вывода графики OGL или хотя бы основного канала обмена сообщениями оконной системы – безумие.

Почему? Если забыть про тормознутость существующей реализации и говорить про идеальный вариант dbus, я не вижу ни одной причины использовать его как универсальный инструмент для IPC. Потому что он вроде как на него и претендует. По крайней мере, перцы из Freedesktop его так позиционируют.

В любом случае, я не понимаю минусов, если dbus будет уметь гигабайты с секунду. Это будет хуже чем сейчас? Явно нет.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Почему?

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

Любой вариант улучшения означает фактически разработку новой несовместимой шины.

То есть практических вариантов два:

  1. Оставить dbus как есть в виде перечислителя объектов и отправки не требовательных к производительности сообщений. Для производительного варианта переключаться на приложение-специфичный протокол.
  2. Делать вообще с нуля, не оглядываясь на dbus. Ломать так ломать.
wandrien ★★
()
Ответ на: комментарий от wandrien

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

Подразумевает? Нет. Плюс, его можно расширить.

Оставить dbus как есть в виде перечислителя объектов и отправки не требовательных к производительности сообщений. Для производительного варианта переключаться на приложение-специфичный протокол.

Или же можно просто сделать новый тип сообщений для высокопроизводительной передачи данных. Это не так сложно.

Делать вообще с нуля, не оглядываясь на dbus. Ломать так ломать.

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

Мораль истории в том, что если в условиях существующей экосистемы переписывать всё с нуля вместо доработки существующего, вместо одной конфетки получаются две бочки говна. Просто одна будет более новой чем другая.

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Пароль — не видюшка, пароль через fd передавать только дольше. Как ты его собрался подслушивать (и зачем, когда можно попросить)?

t184256 ★★★★★
()
Ответ на: комментарий от intelfx

Так почему они его в ядро не приняли в конечном счете? Сейчас, конечно, это уже не важно, ведь есть dbus-broker, на который постепенно переходят разработчики дистрибутивов, но всё-таки

hateWin ★☆
()
Ответ на: комментарий от hateyoufeel

Не помню точно, но получилась шляпа

Шляпа у тебя вместо мозга, поскольку ты агрессивный догматик. Я уже несколько раз пытался добиться от тебя конструктивной критики архитектуры вайланда — в ответ только пук-среньк

hateWin ★☆
()
Ответ на: комментарий от hateWin

О.. фанатики вяленого подтянулись. Ни дня без обсасывания своего любимого убогонького недопротокола!

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Как я понимаю, кроме смайликов ты больше никак отреагировать не можешь? Окей, слив так слив

hateWin ★☆
()
Ответ на: комментарий от hateWin

Отсутствие консенсуса относительно базовых абстракций, я бы это так сформулировал. Типа у нас все еще нет протокола для получения списка десктопов. Или получения координат окон (что нужно для тулзов для захвата окон, сейчас все композиторы делают это на свое усмотрение). Нет единого протокола управления экранами. Нет даже способа узнать раскладку чтобы на панельку вывести. Архитектурной проблемы как таковой нет, но административная оказалась еще хуже.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от hateWin

Хороший вопрос, я не знаю на него ответа.

intelfx ★★★★★
()
Ответ на: комментарий от cumvillain

Как раз консенсус есть. Сам вайланд только обрабатывает события ввода и рисует текстуры на экране. Есть небольшой набор стандартизированных расширений. Остальное — на совести разработчиков композитора

hateWin ★☆
()
Ответ на: комментарий от cumvillain

Или получения координат окон (что нужно для тулзов для захвата окон, сейчас все композиторы делают это на свое усмотрение). Нет единого протокола управления экранами

Это всё можно реализовать в расширениях. Это не проблема.

hateWin ★☆
()
Ответ на: комментарий от hateWin

Как раз консенсус есть. Сам вайланд только обрабатывает события ввода и рисует текстуры на экране. Есть небольшой набор стандартизированных расширений. Остальное — на совести разработчиков композитора

Ясно, ты не участвовал в разработке софта в вейланд.

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

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от hateWin

Это всё можно реализовать в расширениях. Это не проблема.

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

Проблема вейланда как экосистемы, а не идеи, в том, что там худший пример разработки комитетом — медленно, МЕДЛЕННО и много компромиссных решений.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 1)
Ответ на: комментарий от cumvillain

Хорошо. Я согласен с тем, что у вайланда есть организационные проблемы. Но @hateyoufeel настаивает, что у вайланда проблемы именно с архитектурой. Какие именно — он объяснить не может

hateWin ★☆
()
Ответ на: комментарий от hateWin

А смотри какая беда получается:

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

  2. Внесение любой мелочи требует месяцев в лучгем случае, обычно это год и больше

  3. Софт надо было портировать еще вчера

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

В итоге экосистема развивается через боль отважными людьми, готовыми годами(!) байкшедить в багтрекере. Не такие упертые разработчики вынуждены просто признавать ограничения и делать костыли. А ограничений дохрена в силу пункта 1.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 3)
Ответ на: комментарий от cumvillain

Разрабы испугавшись иксов делают слишком минимальный протокол

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

hateWin ★☆
()
Ответ на: комментарий от hateWin

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

А это еще надо доказать, потому что в иксы фичи носили гораздо быстрее. По итогу может оказаться, что вейланд тоже протухнет, но уже по причине отсутсвия желающих туда ходить протоколы делать. Парни из гнома просто положили и делают все через приватные дбас апи гнома. В итоге куча софта в нем просто не работает. Авторы композиторов тоже положили и делают через ipc / приватные протоколы / не делают вообще. И все скатилось к тому что контролы на панельке надо реализовывать отдельно для каждого композитора, а для каких-то композиторов показать раскладку клавиатуры — нерешаемая задача.

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

Это было буквально пару раз, даже конверсии wlr в ext все еще обсуждаются.

cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 2)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)