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

Я там прочитал, что ты работаешь в интернете. Это не должность.

Я там прочитал, что ты работаешь в интернете. Это не должность.

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

Да, удивляюсь, потому как wheel - это ещё не root, это только возможность запустить sudo с каким-то правами, которые надо ещё дополнительно настроить.

Если не добавлять в группу wheel то policykit-agent спрашивает пароль root. Если добавить, то спрашивает пароль пользователя. При этом если пароль закеширован sudo то и не будет спрашивать, что видимо и случилось. Зачем добавляли в группу wheel? Хотели проверить функциональность systemd-run? Так успешно проверили, так и должно быть.

Нашёл, кстати, Ubuntu. Аналогично. Но там ещё прикольнее, там %sudo ALL=(ALL:ALL) ALL. Это убрал, всё равно дало root через systemd-run.

Да тут видимо, что в лоб, что по лбу. Тетерев на току.

А где-то написано, что Базальт является Интернет-провайдером?

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

Зачем добавляли в группу wheel? Хотели проверить функциональность systemd-run?

Отличная функциональность. Поздравляю.

Да тут видимо, что в лоб, что по лбу. Тетерев на току.

Скажем так, я теперь ещё в большем восторге от логики разработчиков systemd.

Мало того я слабо интересуюсь вашими перестановками и сменами названий. Но, не хотите ответить — ваше право.

Какое слово тут непонятно: «Отсюда проистекает очевидный ответ: я не имею отношения к Базальту» ? Вроде конкретно ответил.

Это убрал, всё равно дало root через systemd-run.

В любом случае polkit настраивается не там

При этом если пароль закеширован sudo то и не будет спрашивать, что видимо и случилось.

polkit не имеет отношения к sudo

В любом случае polkit настраивается не там

Согласен, но тем не менее. Ладно ALT, группа wheel не имеет явной целевой направленности, и, возможно, имеется какой-то резон что-то там делать особое в polkit. Но в Ubuntu-то группа с явным названием sudo! В sudoers никаких разрешений не прописано, но тут на тебе все права пожалуйста.

Вот смотри, это дистрибутив здорового человека:
mike@pet ~ $ id
uid=1000(mike) gid=1000(mike) группы=1000(mike),5(tty),7(lp),10(wheel),14(uucp),35(games),235(plugdev),251(pulse-access),252(pulse),977(asterisk),985(docker),1001(sopas) контекст=staff_u:staff_r:staff_t
Как видишь я в составе wheel
mike@pet ~ $ systemd-run /bin/bash
Failed to start transient service unit: Access denied
Как видишь рута я не получил
mike@pet ~ $ sudo -i
pet ~ #
Хотя sudo у меня беспарольное.
Пользуюсь постоянно systemd с версии 12.

Отличная функциональность. Поздравляю.

Ну давай ещё поругай rm за -rf
У тебя всё совсем так плохо с матчастью?

Скажем так, я теперь ещё в большем восторге от логики разработчиков systemd.

От какой? Дёргать policykit? Так policykit дёргает очень много программ.

polkit не имеет отношения к sudo

Во первых ты не тому пишешь, во вторых пароль спрашивает policykit-agent.

Компания Red Hat рекомендует системным администраторам не создавать аккаунты с отрицательными значениями UID

теперь точно такого создам. лол

От какой? Дёргать policykit? Так policykit дёргает очень много программ.

Я, пока, возьму таймаут и посмотрю на то, как это в ALT обсуждать/решать будут и кого назначат виновником.

Какое слово тут непонятно: «Отсюда проистекает очевидный ответ: я не имею отношения к Базальту» ? Вроде конкретно ответил.

Почему ты отвечаешь на то, что я не спрашивал и не отвечаешь на то, что спросил. У тебя должность-то какая? Хотя, лучше не отвечай.

Это вопрос к дистростроителям. В политиках polkit есть понятие «администратора». Кто такие «администраторы» задается локальными политиками. В том дебиане, что у меня под рукой это:

# find /etc/polkit-1  -type f -exec grep -i admin '{}' ';'
AdminIdentities=unix-group:sudo
AdminIdentities=unix-user:0

И нет никаких wheel, вообще.

как это в ALT обсуждать/решать будут и кого назначат виновником

А у вас там виновных назначают? Очень интересный дистрибутив.

AdminIdentities=unix-group:sudo
И нет никаких wheel, вообще.

Покажи id пользователя. Во многих дистрах вместо wheel делают группу sudo для sudo, а wheel оставляют только для su.

Почему ты отвечаешь на то, что я не спрашивал и не отвечаешь на то, что спросил.

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

Ответ, повторяю: «я не имею отношения к Базальту».

Давай так напишу: я не работал и не работаю ни в ООО «ALTLinux», ни в ООО «Базальт СПО». Соответственно, никаких должностей в «Альтобазальте» не имею. Так понятно?

Вопрос звучал так:

Я прекрасно знаю что я спрашивал.

Так понятно?

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

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

А смысл то какой? У меня вся эта бодяга из треда все равно не работает, что толку в моем id? )

Чем на жизнь зарабатываете?

«Мы делаем Интернет». Что непонятно в сообщении по ссылке из профиля?

Ещё точнее хочешь? Я сам иногда ковыряюсь в консольках Juniper/Cisco/D-Link/ZyXEL/Eltex/SNR/e.t.c. Посылаю людей что-то где-то сделать и т.п. Знаю, что такое RADUIS, что такое почтовый сервер с кучей абонентов, знаю, что такое netflow и т.п. Перечислять могу долго, что я знаю, либо делаю. Иногда ковыряю пакеты, либо связанные с этой деятельностью, либо чисто для себя. И да, использую ALT для всех этих целей, если вообще нужен Linux.

Смысл моего вопроса в том, чтобы посмотреть, что вместо группы wheel у тебя в системе группа sudo, поскольку админами у policykit назначены члены этой группы.

AdminIdentities=unix-group:sudo
И нет никаких wheel, вообще.

ты о чем?

О том, что социальной инженерией можно заставить пользователей сделать что-то не безопасное.

лана, прости, но не хочу на тебя время тратить :)

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

«Мы делаем Интернет». Что непонятно в сообщении по ссылке из профиля?

Под этой фразой сейчас можно понимать что угодно вплоть до «мою полы в датацентре».

Ещё точнее хочешь?

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

Мой текущий пользователь в этой группе, да. В моем случае polkit спрашивает пароль всегда, т.к. у меня в политиках везде admin_auth.

Получается твоя комбинация из версии policylit + настройки политик + возможно что-то ещё оказывается неуязвима.
А обновы policykit не прилетали?

с чего бы?

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

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

Тема большая, а я пока не нашёл другого варианта эксплуатации этой проблемы (с группой и без немеряного значения ID), кроме как через systemd-run.

Тема большая

Всю читать не обязательно.

я пока не нашёл другого варианта эксплуатации этой проблемы (с группой и без немеряного значения ID), кроме как через systemd-run

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

И тебе сразу же пришла в голову гениальная мысль, что во всём виноват systemd.

А почему нет? А если завтра разработчикам systemd придёт в голову, что достаточно наличие пользователя просто в /etc/passwd? Но ладно, соглашусь, что надо поближе познакомиться с рекомендуемой политикой использования PolicyKit. Вдруг там где-то так и написано, а все остальные напрасно перестраховываются.

Предлагаю начать с man systemd-run.
Там есть интересные ключики :)

А если завтра разработчикам systemd придёт в голову, что достаточно наличие пользователя просто в /etc/passwd?

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

И что самое интересное, ты даже понять не можешь почему тебе дали рута, но виноват тебе systemd.

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

Хорошо, я понял. Прошу простить за подобный выпад.

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

Это определяется политиками policykit. Кто именно решает, что и кому можно — видимо дистростроители.
Но, из-за уязвимости получается что администраторами стали и пользователи с отрицательными и очень большими uid. В норме если у тебя пользователь не в wheel, то для такой операции policykit-agent должен запросить пароль root. У тебя спрашивают пароль пользователя, потому что он в wheel. А могли бы и не спрашивать. И ты бы не догадался, из-за уязвимости это, или из-за политики.

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

Это определение термина wheel с доюниксовых времен.

Это определение термина wheel с доюниксовых времен.

В ALT всегда это было не так. По крайней мере, для sudo. Или, точнее, что может запустить член группы wheel регулировалось через control. А в Ubuntu в сегодняшнем тесте моём и группа не wheel, а sudo.

В убунте группа sudo до Ubuntu 12 была admin и также используется как и wheel, для полного доступа.

Если в Альте это не так по какой-то причине (это было бы весьма странно, но особый путь он особый, да), то наверное альтовцам не стоило копипастить дефолты policy-kit с других систем не глядя.

то наверное альтовцам не стоило копипастить дефолты policy-kit с других систем не глядя.

Вероятно да.

а я к policykit изначально относился как к какой-то ненужной сущности

uid можно было сделать беззнаковым. Отрицательные uid не нужны.

А он в Linux и есть беззнаковый. uid_t = uint32. Это разработчики PolicyKit с нелюбовью к системным типам его решили в int сохранять.

то наверное альтовцам не стоило копипастить дефолты policy-kit с других систем не глядя.

А какие ещё приложения, кроме systemd-run, допускают исполнение всего подряд с правами суперпользователя, ориентируясь на какие-то групповые политики по-умолчанию? Такие известны? Допустим с sudo в Ubuntu понятно, там хоть, по счастью, конфиг удобочитаемый и вообще читаемый.

Допустим с sudo в Ubuntu понятно

В ALT, кстати, это самое пытались сделать не далее, как месяц назад: https://lists.altlinux.org/pipermail/devel/2018-November/205847.html
Но попытка пока была пресечена.

А какие ещё приложения, кроме systemd-run, допускают исполнение всего подряд с правами суперпользователя

bash например, sh, zsh :D

ловите наркомана

bash например, sh, zsh :D

Они знают про что-то вне классических прав? Или имеют собственные странные конфиги? :-)

ловите наркомана

Ты остановись хотябы. :-)

Они знают про что-то вне классических прав? Или имеют собственные странные конфиги? :-)

systemd-run звонит в systemd и просит создать+запустить временный сервис. Сам systemd-run ничего не запускает.

systemd использует polkit (опционально, но дистростроители склонны включать это в 100% случаев) что бы обрабатывать запросы от обычных пользователей.

«Стандартных» технологий повышения привилегий на данный момент всего 3 - su, sudo, polkit. Все что их использует, так или иначе, потенциально может «исполнять всё подряд с правами суперпользователя».

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

pkaction | xargs -I{} pkaction --action-id {} --verbose | less

Приятных открытий!

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

Это понятно. Вопрос в другом. Ещё раз: известны ли приложения, кроме systemd-run (хорошо, systemd), кто запускает таким образом всё подряд, не сверяясь с так или иначе заданным списком допустимого к запуску.

Интересна глубина распространения такой ДНК у современных разработчиков.

Приятных открытий!

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