Обнаружена уязвимость в Polkit, которая позволяет выполнять любую команду systemctl пользователю с низкими привилегиями

И так чуточку, совсем ненавязчиво передергиваем.

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

Вообще это отличная идея конечно, требовать чтобы systemd теперь своими юнит-тестами покрыл весь софт написанный за двадцать лет до него

Речь о том, что RHEL делают рукожопы. Факт наличия systemd тут скорее индикатор. Да и за каким хреном systemd берёт на себя полномочия запуска софта от рута со стороны пользователя, пусть и через policykit?

приведет ли дефолтная/типичная/кривая (но тем не менее типичная) настройка LDAP (или иного костыля авторизации) в среде где не овердохрена пользователей к самопроизвольному появлению таких UID, которые можно проэксплуатировать, или нет?

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

это базовая функциональность системы существовавшая задолго до появления systemd и являющаяся стандартом.

Ссылочку на ISO или RFC по policykit (включая конфиги на жабоскрипте) приведёшь?

И любой современный проект должен её поддерживать.

Вот тут ты и передёргиваешь. См. выше.

И да, можно долго разговаривать о том как линукс стал сложнее, умнее и как страшно жить. Можно пойди сделать hardened-дистр с отлючением всех «новомодных» фишечек (новомодность начинается с 2009 примерно). А можно взять себя в руки, перестать истерить и поработать над налаживанием обновлений на всех подконтрольных серверах, потому что уязвимости есть и будут и никто от них не застрахован. Святое ядро в том числе.

«Нет, это не новомодные хипстеры дебилы, что наплодили полурабочего говнеца! Это вы дебилы, раз не хотите за ними говно выстраивать фигурками так, чтобы оно хоть как-то работало и не так сильно воняло!»

Офигеть логика.

Штука в том, что polkit является стандартом только для FDO софта

Нет, не является. Freedesktop вообще никакие стандарты не имеет - в этом проекте есть только спецификации по работе с их стеком. На стандарты ЭТО не тянет. Это примерно то же, что называть DirectX стандартом.

С позиции разработчика systemd это так.

Даже с позиции разработчика systemd это косяк, потому что они используют дырявой метод авторизации. Это не libc и не ядро, они могут выкинуть polkit к чертовой матери и для пользователя вообще ничего не изменится.

Нет, не является. Freedesktop вообще никакие стандарты не имеет - в этом проекте есть только спецификации по работе с их стеком. На стандарты ЭТО не тянет. Это примерно то же, что называть DirectX стандартом.

Я не знаю, что ты называешь БОЖЕСТВЕННЫМ СТАНДАРТОМ КОТОРЫЙ НАПИСАН ПРАВИЛЬНО И ТЯНЕТ НА ЭТО ВЫСОКОЕ ЗВАНИЕ, но де-факто стандартом у fdoшного софта является использовать polkit для таких вот штук. Смирись.

Там в основном в пакете зависимости прописаны. Встречаются такие, для работы которых policykit не нужен в принципе. Например, winetricks.

Специальное значение, о котором ты говоришь - это fork return status for child

То, о котором я говорил - это 0 в kill(2). Но fork тоже подходит.

А «глобальная переменная» с таким значением тоже существует: это сваппер-шедуллер.

С каким «таким»?

От ссылок на википедию уже изжога, так что вот lkml.

В трейсе, на который ты ссылаешься, pid 0 тоже используется в смысле «в данный момент нет ЦП нет процесса с валидным PID» (трейс начинается в start_kernel, потом do_IRQ - это прерывание).

но де-факто стандартом у fdoшного софта является использовать polkit для таких вот штук. Смирись.

Если объяснять на пальцах, то стандарт - это что-то вроде POSIX, ISO, OASIS и т.д. То, что не привязано к реализации. То, что в FDO - это привязка к реализациям. В FDO не стандарты, а спецификации по работе со стеком технологий.

Даже с позиции разработчика systemd это косяк

Это заявление разработчика systemd?

Если ты вдруг не в курсе, то POSIX это именно описание работы со стеком технологий. Это такая общая сумма реализаций. И пишется он по устояшимся практикам, а не наоборот.

Попробовал в Devuan через policykit получить права рута. не получилось.

Это только в арче у людей получилось. Вопрос с pkexec разобрали в теме, почему у кого-то срабатывает, а у кого-то нет.
У меня не срабатывает уязвимость ни через pkexec, ни через systemd-run.

Андроид и эмбед в данном случае не рассматривался.

Если ты вдруг не в курсе, то POSIX это именно описание работы со стеком технологий.

Если ты не в курсе, то POSIX - это описание того, как стек технологий должен работать, а не наоборот.

Это такая общая сумма реализаций. И пишется он по устояшимся практикам, а не наоборот.

А спецификации FDO - это как раз наоборот.

Рассматривается всё. Но в первую очередь - серверы.

Ты б сначала хотя бы попытался понять о чём была речь там. Для этого много не надо.

Я как раз всё понял, чего нельзя сказать о тебе. Потому, что когда говорят о доле линукса и эксплуатации уязвимостей, речь идёт исключительно о возможности массово эти уязвимости эксплуатировать. Не имеет значения, какая доля линукса на десктопе - имеет значение только то, какая доля линукса вообще. Она огромна. По сабжу получается, что та область, в которой линукс доминирует, позволяет эксплуатировать уязвимость массово.

polkit позволяет и вовсе обходиться без ввода пароля в допустимых случаях

Ну вот. И как быть без polkit-а?

Это работает и в рхел. См. Мой пример.

Есть примеры использования кроме как через systemd? А то в сабжевой новости фигурирует сочетание systemd и policykit, что уже способствует развитию дискуссии в соответствующем направлении.

Естественно. Уже показали через pkexec.

Лёня «Обосрамс» Поцеринг точно такую же риторику толкал, когда визжал аки свинка, что в неработоспособности его системуды виноват стандарт FHS, а не его кривые руки

Это, случайно, не вывод предупреждения о том, что с отдельным /usr может ломаться самый разнообразный не связанный с systemd софт, но которое никак не влияло на работоспособность самого systemd, превратилось в «неработоспособность системуды из-за FHS»? :D

С каким «таким»?

мы вроде про pid 0

В трейсе, на который ты ссылаешься, pid 0 тоже используется в смысле «в данный момент нет ЦП нет процесса с валидным PID»

почему «тоже» не понял. «тоже» как с форк? да нет.

(трейс начинается в start_kernel, потом do_IRQ - это прерывание).

Process swapper/0 (pid: 0, threadinfo ffffffff8138e000, task ffffffff813a1020) - pid 0 - это глобальный indentifier процесса.

Предлагаете покрывать юнит-тестами чужой продукт? o_O

Что-то прокосоглазил я твой пример с rhel.

А «глобальная переменная» с таким значением тоже существует: это сваппер-шедуллер.

С каким «таким»?

мы вроде про pid 0

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

Process swapper/0 (pid: 0, threadinfo ffffffff8138e000, task ffffffff813a1020) - pid 0 - это глобальный indentifier процесса.

См. выше.

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

Я в том месте говорил не о эксплуатации уязвимостей, а о набежавших в топик истеришных с криками про systemd.

Я как раз всё понял, чего нельзя сказать о тебе.

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

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

может быть, это процесс с фиксированным pid?:) также, как pid 1 в случае с init.

Естественно. Уже показали через pkexec.

И показали, что не всегда это работает.

Это, случайно, не вывод предупреждения о том, что с отдельным /usr может ломаться самый разнообразный не связанный с systemd софт, но которое никак не влияло на работоспособность самого systemd, превратилось в «неработоспособность системуды из-за FHS»? :D

Нет. Я даже не знаю, откуда ты это взял. Там была проблема с запуском системы через systemd.

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

раз не знаешь, то держи:

https://en.wikipedia.org/wiki/Process_identifier

There are two tasks with specially distinguished process IDs: swapper or sched has process ID 0 and is responsible for paging, and is actually part of the kernel rather than a normal user-mode process.

И показали, что не всегда это работает.

Это и через systemd не всегда работает. Обновление polkit много куда пришло уже.

Нет. Я даже не знаю, откуда ты это взял. Там была проблема с запуском системы через systemd.

Можно ссылочку, пожалуйста?

Я не знаю, что такое «сваппер-шедуллер», но это явно какая-то задача, а не значение PID.

раз не знаешь, то держи:
https://en.wikipedia.org/wiki/Process_identifier

Ты даже не понял, в чем была нелепость твоих слов.

Предлагаете покрывать юнит-тестами чужой продукт? o_O

Свой.

оу? мы опять включили режим умника? чья бы корова мычала: Обнаружена уязвимость в Polkit, которая позволяет выполнять любую команду systemctl пользователю с низкими привилегиями (комментарий)

оу? мы опять включили режим умника?

Мы? Я его никогда и не выключаю, ты его еще и не включал.

чья бы корова мычала: Обнаружена уязвимость в Polkit, которая позволяет выполнять любую команду systemctl пользователю с низкими привилегиями

И что? Там всё правильно. Даже твоя ссылка на Wikipedia не говорит, что у ядра есть PID.

Я тоже хочу такие вещества :D

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

что у ядра есть PID.

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

что у ядра есть PID.

а ты меня так понял, да?

Я понял, что у тебя были какие-то претензии к моим утверждениям, которые ты не опроверг.

ну да и хрен с тобой золотая рыбка.

И тебе того же.

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

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

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

Угу. На запись любого файла написать юнит-тест, проверяющий, что файл действительно создался, действительно с теми правами, его действительно могут читать те кто должны и не могут те, кто не должны (проверить все возможные UID, а то вдруг файл с правами 700 принадлежащий UID 4000000000 тоже все могут читать).

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

Так что ли?

домыслы неумею, да. только то что написано.

да это по сути умный chroot

Умный chroot - это systemd-nspawn.

Проверить, правильно ли работает твой программный продукт

Их программный продукт работает правильно:

1. спрашивает у polkit, можно ли пользователю запустить данную операцию;
2. получает ответ, что можно;
3. запускает операцию.

В чём здесь, по-вашему, ошибка?

странно что pkexec себя по разному в разных дистрибутивах ведёт.. кто-то не возвращает патчи в апстрим или шо?

самая вишенка истории конечно же в том что если pkexec в некоторых дистрибутивах дополнительно проверяет uid за полкитом, значит они нашли что полкит неправильно себя ведёт, но вместо того что-бы зарепортить багу в полкит они у себя костылик добавили..

Может они сделали и то и другое одновременно. Надо сверять даты

а точно.. run это тот который всё что угодно как сервис запускает?

такто да надо теперь смотреть когда в pkexec эта проверка появилась..

Их программный продукт работает правильно:

спрашивает у polkit, можно ли пользователю запустить данную операцию;
получает ответ, что можно;
запускает операцию.

В чём здесь, по-вашему, ошибка?

В классической ошибке программиста. Фича заключается не в том, чтобы у polkit'а спросить, а в том, чтобы сделать возможным выполнение привилегированных операций без привлечения рута, но только тем юзерам, которым явно разрешили. В данном случае, решили сделать через polkit и дать возможность выполнять команды только юзерам с правами auth_admin. И вот этот момент они и не проверили.

Тестировать нужно видную пользователю функциональность. В данном случае — выполнение привилегированных команд через systemctl, и совсем не важно, через что там это реализовано. А то вдруг у них там

if (uid > 0 && uid <= INT_MAX)
    res = ask_polkit();

И все, привет.

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

У тебя есть uid, у него есть три типа значений — ноль (рут), 1 - UID_MAX (юзеры) и все, что выше. И да, их по хорошему стоит проверить. Хотя бы по одному из группы.

(проверить все возможные UID, а то вдруг файл с правами 700 принадлежащий UID 4000000000 тоже все могут читать).

Слово «fuzzing» ты, видимо, в первый раз слышишь.

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

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

На выполнение любого арифметического действия добавить юнит тест, проверяющий, что арифметика действительно работает верно...

Проверки на integer overflow обычно пытаются зашить в фукнции. realloc, calloc и reallocarray не просто так придумали.