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

cc wandrien

тебе понравится.

что за бред, конечно пользователь сможет приаттачится, вообще к любому tty, он же в группе tty состоит! мамкин-хаккер блин. Как systemd должен спасать он тупых-кривых рук?

Вот что у меня выдаёт:

[-] Process 375994 (pkttyagent) shares 375993's process group. Unable to attach.
(This most commonly means that 375993 has sub-processes).
Unable to attach to pid 375993: Invalid argument

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

К tty рутового процесса. Угу.

да вообще любого, смотри ls -al /dev/pts/, хоть через sudo создай, group будет tty.

tty: TTY devices are owned by this group. This is used by write and wall to enable them to write to other people’s TTYs, but it is not intended to be used directly.

Так что к systemd этот «хак» не имеет отношения. Просто человек не понимает как Linux/Unix работает, что не удивительно для systemd-хейтеров.

Жду когда они ещё группу kmem откроют для себя, то ещё начнётся…

включая свои пароли, летающие из keyring в запрашивающее их приложение.

Notabug

включая свои пароли, летающие из keyring в запрашивающее их приложение.

Notabug

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

Там не нужна группа tty, если что. Читай внимательнее:

«systemd-run –pipe» will reuse your user owned pty with the root process and «systemd-run –pty» will create a new root-owned one but root terminal still accessible through the local user pty. Ptrace used for PoC only to hijack the tty fully. tty/sys gid are not required.

Вообще, баг.

Это мем, этими словами Лёнька баги закрывает :)
Пруфы лень искать. Известная история.

так у тебя получилось повторить? Например Дефолтная убунта, без членства в tty, и дефолтные параметры ядра?

PS, аккаунта в твиттере у меня нет, так что мне только изначальные скриншоты показывает

# busctl --monitor
busctl: unrecognized option '--monitor'

А какого года нужна busctl?

UPD: там busctl monitor, а не busctl --monitor.

Вот тебе скрин треда целиком: https://ibb.co/khbvcdk

P.S. у меня не воспроизвелось, потому что ptrace ограничен и reptyr не работает. Если в /proc/sys/kernel/yama/ptrace_scope будет 0, то reptyr будет работать.

Но это не так важно, потому что systemd всё равно не создаёт рутовый pty, в отличие от sudo. Так что косяк всё равно есть, для его эксплуатации не обязательно ptrace использовать.

Просто запусти systemd-run --shell, набери там tty и посмотри, кому этот pty принадлежит. Это будет твой юзер, а не root.

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

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

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

Ну почему же. Это отлично помогает мне не терять вес, потому что драма с дырявым лялексом заставляет меня потреблять попкорн тоннами. За 20 лет лялекс превратился из наименее дырявой пользовательской ОС в наиболее дырявую.

Чувак обосрался себе в штаны, т. к. 1) точно таким же образом можно перехватить любой pty, например, твоего терминального эмулятора, 2) он перехватил не тот pty, лол и 3) это работает, только если предварительнов выключить защиту вокруг ptrace (которая специально от таких умников).

TL;DR: если подключить дебаггер к процессу, в данный момент работающему с какими-то секретами, можно сделать много интересных вещей. Кто бы мог подумать!

Слишком жирно.

Ну то есть ты сейчас подтвердил бессмысленность затеи лёньки. Браво!

Кого? Потттеринга, или sudo?

можно много интересного увидеть, включая свои пароли, летающие из keyring в запрашивающее их приложение.

точно? а накой там тогда пляски с fd passing?

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

P.S. у меня не воспроизвелось, потому что ptrace ограничен и reptyr не работает. Если в /proc/sys/kernel/yama/ptrace_scope будет 0, то reptyr будет работать.

Ну, то есть оно не работает….

Просто запусти systemd-run –shell, набери там tty и посмотри, кому этот pty принадлежит. Это будет твой юзер, а не root.

да, я посмотрел, то есть пользователь, который может поднять привилегии до рута сможет перехватить свой же tty и выполнять команды от рута, при определённых конфигурациях. Круто! Зачем tty перехватывать когда можешь просто в самим терминале писать? И не надо рассказывать про веродоносное ПО от пользователя, вот тебе код вредоносного ПО для sudo

echo 'alias sudo="sudo IHackedYou"' >> ~/.bashrc

Когда оно из твиттера мамкиного хакера придёт в нормальный CVE или bugtracker, тогда и приходи.

Как и любой программный продукт systemd может содержать ошибки. Твиттер не предназначается для их репортинга, мамкин хакер просто неявно пиарит в нём свою контору среди systemd ненавистников. Дай угадаю: 90% реплаев под постом «Systemd - дыра, Лёня - засланник microsoft» и «systemd нарушает unix-way и разрушает Linux»

да, я посмотрел, то есть пользователь, который может поднять привилегии до рута сможет перехватить свой же tty и выполнять команды от рута, при определённых конфигурациях. Круто! Зачем tty перехватывать когда можешь просто в самим терминале писать? И не надо рассказывать про веродоносное ПО от пользователя, вот тебе код вредоносного ПО для sudo

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

Ну перехватить tty рутовой программы может не только сам юзер, но и любая программа, запущенная от его uid.

Я не понимаю, почему фанаты systemd тут уходят в отрицалово, ведь дыра реально существует. Да и чинится тривиально: systemd должен просто сделать chown на tty.

можно много интересного увидеть, включая свои пароли, летающие из keyring в запрашивающее их приложение.

точно? а накой там тогда пляски с fd passing?

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

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

ну а ptrace включён у каждого первого.

Ну перехватить tty рутовой программы может не только сам юзер, но и любая программа, запущенная от его uid.

И здесь мы возвращаемся к untrusted software as normal user, но вы же также flatpak и wayland ненавидите, как и systemd.

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

Я не понимаю, почему фанаты systemd тут уходят в отрицалово, ведь дыра реально существует.

CVE тогда заведи, уверяю если это дыра, то Поттеринг подавится, но поправит.

dbus-broker, который стал дефолтом, гораздо быстрее. Так что уже не особо актуально.

Всё ещё актуально, потому что задержка из-за переключения контекста вылезет. Для звука особенно критично. А с графикой просто жопа, даже dbus-broker повесится от несжатого видео 4k@60fps.

Для тех, у кого нет тваттера

В ксвиттер теперь без аккаунта не пускает? Ну и как тебе такое Илон...а, да, точно...

но вы же также flatpak и wayland ненавидите, как и systemd.

Кто тебе сказал, что мы ненавидим что-то из этого? Твои голоса в голове?

Всё ещё актуально, потому что задержка из-за переключения контекста вылезет. Для звука особенно критично. А с графикой просто жопа, даже dbus-broker повесится от несжатого видео 4k@60fps.

Во-первых нужны пруфы, во-вторых зачем гонять несжатое видео через шину тоже не очень понятно.

Во-первых нужны пруфы

Пруфы того, что от 2 гигабайт в секунду dbus-broker повесится? Ну просунь через него 2 гигабайта в секунду и оцени его производительность. Будет не очень.

во-вторых зачем гонять несжатое видео через шину тоже не очень понятно.

А ты предлагаешь его сжимать в одном процессе просто чтобы потом разжимать в соседнем?

Типичный сценарий: захват экрана.

Пруфы того, что от 2 гигабайт в секунду dbus-broker повесится? Ну просунь через него 2 гигабайта в секунду и оцени его производительность. Будет не очень.

Ну ты говоришь, что будет не очень. Ты можешь это пруфануть?

Типичный сценарий: захват экрана.

Угу, dbus передает тебе audio и video sink’и и pipewire.

...уже готовы заранее.

А то! ))

Пруфы того, что от 2 гигабайт в секунду dbus-broker повесится? Ну просунь через него 2 гигабайта в секунду и оцени его производительность. Будет не очень.

Ну ты говоришь, что будет не очень. Ты можешь это пруфануть?

Забавно, но при заявленном «fastest dbus implementation», у dbus-broker напрочь отсутствуют бенчмарки.

Стандартный dbus точно вешался. Если помнишь драму с kdbus, его из-за этого и пилили.

Типичный сценарий: захват экрана.

Угу, dbus передает тебе audio и video sink’и и pipewire.

Нет, там передаётся fd, из которого можно данные читать. Сами звук и картинку по dbus никто не передаёт. Запусти OBS Studio под вялендом, подключись к шине через busctl monitor и сам оцени.

Стандартный dbus точно вешался. Если помнишь драму с kdbus, его из-за этого и пилили.

Там в топ-5 utf8 парсинг был, потому что кажется там был glib. Авторы dbus-broker сделали нормально.

Нет, там передаётся fd, из которого можно данные читать. Сами звук и картинку по dbus никто не передаёт. Запусти OBS Studio под вялендом, подключись к шине через busctl monitor и сам оцени.

Да, я это и сказал.

Там в топ-5 utf8 парсинг был, потому что кажется там был glib. Авторы dbus-broker сделали нормально.

Сделали нормально для того сценария, где dbus обычно применяется, то есть текстовые и около текстовые сообщения между сервисами. Для передачи 2 гигабайт в секунду dbus обычно не применяется.

Тредом доволен: кукаретики кукарекают, а нормальные пацаны над ними потешаются. ЛОР – торт.

Сделали нормально для того сценария, где dbus обычно применяется, то есть текстовые и около текстовые сообщения между сервисами. Для передачи 2 гигабайт в секунду dbus обычно не применяется.

Потому что для передачи 2 гигабайт сырых данных шина обычно не применяется. Просто хотя бы из-за двойного хопа.

Просто хотя бы из-за двойного хопа.

skill issue lmao

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

Но да, вот поэтому звук по dbus и не гоняют, хотя звук гораздо легче по трафику чем графика. Задержка – довольно неприятная штука.

skill issue lmao

У тебя есть три процесса: a, b и c. Чтобы передать из процесса a в процесс c помощью процесса b, нужно сперва передать данные в b. На этом можно попрощаться с zero copy. Зачем все это делать, если можно просто передать fd в c – загадка.

У тебя есть три процесса: a, b и c. Чтобы передать из процесса a в процесс c помощью процесса b, нужно сперва передать данные в b.

Нет. Нужно создать шареный буфер в a и передать его в c. На самом деле, конечно, лялекс изобрёл почти нормальный подход, только буфер заворачивается в fd и превращается в очередь. Что, например, ставит крест на возможности передавать данные двум и более процессам сразу.

Плюс, копирование всё равно остаётся. Сначала из буфера процесса-отправителя в буфер fd, а потом из буфера fd в буфер у получателя. Тут можно подзадрочиться с mmap(), вроде как, но это тоже слегка залупа. Хорошо если хотя бы splice() прикрутили.

Нет. Нужно создать шареный буфер в a и передать его в c.

Это и есть передача fd.

Нет. Нужно создать шареный буфер в a и передать его в c.

Это и есть передача fd.

Да-да. Дальше прочитай:

только буфер заворачивается в fd и превращается в очередь.

только буфер заворачивается в fd и превращается в очередь

В какую очередь он у тебя превращается? :)

только буфер заворачивается в fd и превращается в очередь

В какую очередь он у тебя превращается? :)

Большая часть пользователей этих буферов (господи!) делают read(), что удаляет данные оттуда.

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

Надо тоже пойти буфера попользовать уже, хехехе.

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

Ты так и не привел примеров как именно. Если тебе нужен mmap(), ты делаешь mmap(). Если ты хочешь просто вычитать секрет в 64 байта длиной, ты делаешь один read(). Ложки нет, все хорошо. Если тебе нужно сразу в сеть отправить, делаешь sendfile().

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

Ты так и не привел примеров как именно. Если тебе нужен mmap(), ты делаешь mmap(). Если ты хочешь просто вычитать секрет в 64 байта длиной, ты делаешь один read(). Ложки нет, все хорошо.

В сценарии общения один-один всё и правда норм (кроме всратого файлоцентричного API). Нюансы возникают, когда ты хочешь сделать рассылку один-много. В текущем варианте это просто не будет работать без копирования для каждого получателя.

В сценарии общения один-один всё и правда норм (кроме всратого файлоцентричного API). Нюансы возникают, когда ты хочешь сделать рассылку один-много. В текущем варианте это просто не будет работать без копирования для каждого получателя.

huh?

#define _GNU_SOURCE

#include <err.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <unistd.h>

int
main(void)
{
	int fd, dfd1, dfd2;
	const char *data = "test";
	const size_t data_len = strlen(data) + 1;
	size_t written;
	const char *copy1, *copy2;

	fd = memfd_create("data", 0);
	if (fd == -1)
		err(1, "cannot create memfd");

	written = write(fd, data, data_len);
	if (written == -1)
		err(1, "cannot write data to memory area");

	dfd1 = dup(fd);
	dfd2 = dup(fd);
	
	copy1 = mmap(NULL, data_len, PROT_READ | PROT_WRITE, MAP_SHARED, dfd1, 0);
	copy2 = mmap(NULL, data_len, PROT_READ | PROT_WRITE, MAP_SHARED, dfd2, 0);

	printf("%s\n", copy1);
	printf("%s\n", copy2);

	return 0;
}

$ ./test
test
test

Ты не понял. Проблема в том, что один процесс-получатель может поднасрать другим. Если ты запишешь что-то в copy1, читающий из copy2 это увидит.

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

Я понимаю, что руками в лялексе это можно сделать. Но это должна делать шина сама, а не автор каждой проги.

Кстати, для memfd можно вообще CoW сделать?

Ты не понял. Проблема в том, что один процесс-получатель может поднасрать другим. Если ты запишешь что-то в copy1, читающий из copy2 это увидит.

Если ты хочешь read-only передачу, ты делаешь memory sealing и больше никто ничего не может.

Если же получателей много, страница с сообщением мапится каждому с CoW.

ahem:

       MAP_PRIVATE
              Create  a  private copy-on-write mapping.  Updates to the mapping
              are not visible to other processes mapping the same file, and are
              not carried through to the underlying file.   It  is  unspecified
              whether  changes made to the file after the mmap() call are visi‐
              ble in the mapped region.

Я правильно понимаю от DBUS АРХИТЕКТУРНОЕ ГОВНО!111 мы пришли к тому что там не хватает wrapperов с понятными именами вокруг mmap?

Если ты хочешь read-only передачу, ты делаешь memory sealing и больше никто ничего не может.

Нет, я хочу, чтобы процесс получатель не мог поднасрать другим.

It is unspecified whether changes made to the file after the mmap() call are visible in the mapped region.

Да, я о том же. Для широковещательных рассылок по шине это не слишком подходит.

Я правильно понимаю от DBUS АРХИТЕКТУРНОЕ ГОВНО!111 мы пришли к тому что там не хватает wrapperов с понятными именами вокруг mmap?

Лол нет. Dbus всё ещё говно, потому что не делает кучу того, что могла бы и должна делать шина, и заставляет приложения жонглировать fd.