systemd-run -t /bin/sh успешно срабатывает для пользователя из группы wheel С форума: https://forum.altlinux.org/index.php?topic=41933.0 $ systemd-run -t /bin/sh Running as unit: run-u80.service Press ^] three times within 1s to disconnect TTY. sh-3.2# whoami root Это идёт вразрез вот с этим обсуждением (ссылка на середину сразу): https://lists.altlinux.org/pipermail/devel/2018-December/206081.html
Перевешиваю на polkit. Это он разрешает. systemd-run только спрашивает у него.
(In reply to comment #1) > Перевешиваю на polkit. Это он разрешает. systemd-run только спрашивает у него. А файл с описанием этой политики кто поставляет, systemd или polkit?
описание политики находится в /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy $ rpmquery -f /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy systemd-239-alt3.x86_64
(В ответ на комментарий №3) > описание политики находится в > /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy > > $ rpmquery -f /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy > systemd-239-alt3.x86_64 нет, эта policy не имеет никакого отношения к systemd-run. Точнее там не упоминается ничего о systemd-run. systemd-run подпадает под правило по-умолчанию /etc/polkit-1/rules.d/50-default.rules. Если мы не будем ничего менять в правиле по-умолчанию, тогда да, надо перевесить баг обратно на systemd и придумывать политику специально для systemd-run.
Давайте лучше исправим сразу для всех пользователей polkit, а не только для systemd-run.
$ groups user uucp proc cdrom floppy cdwriter audio radio users vmusers video camera vboxusers xgrp scanner $ systemd-run -t /bin/sh ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: System Administrator (root) Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u299.service Press ^] three times within 1s to disconnect TTY. sh-3.2# whoami root $ groups user wheel uucp proc cdrom floppy cdwriter audio radio users vmusers video camera vboxusers xgrp scanner $ systemd-run -t /bin/sh ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: user Password: ==== AUTHENTICATION COMPLETE ==== Running as unit: run-u307.service Press ^] three times within 1s to disconnect TTY. sh-3.2# whoami root
вот здесь все прекрасно видно. если пользователь в группе wheel авторизуем с паролем пользователя. если пользователь не в группе wheel авторизуем с паролем рута
(In reply to comment #7) > вот здесь все прекрасно видно. если пользователь в группе wheel > авторизуем с паролем пользователя. если пользователь не в группе wheel > авторизуем с паролем рута Да, об этом и баг, что это неправильно.
$ grep -A8 \"org.freedesktop.systemd1.manage-units\" /usr/share/polkit-1/actions/org.freedesktop.systemd1.policy <action id="org.freedesktop.systemd1.manage-units"> <description gettext-domain="systemd">Manage system services or other units</description> <message gettext-domain="systemd">Authentication is required to manage system services or other units.</message> <defaults> <allow_any>auth_admin</allow_any> <allow_inactive>auth_admin</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> </action>
(В ответ на комментарий №8) > Да, об этом и баг, что это неправильно. что конкретно? авторизовать с паролем пользователя?
(In reply to comment #10) > (В ответ на комментарий №8) > > Да, об этом и баг, что это неправильно. > > что конкретно? авторизовать с паролем пользователя? Да, аутентифицировать пользователя (по паролю) для авторизации рута.
ну тогда вам сюда /etc/polkit-1/rules.d/50-default.rules и таки да polkit считает пользователя в группе wheel рутом
вот нормальное описание https://wiki.archlinux.org/index.php/Polkit#Administrator_identities
(In reply to comment #13) > вот нормальное описание > https://wiki.archlinux.org/index.php/Polkit#Administrator_identities Не всё, что годится для Arch, годится для ALT. Я могу себе представить какой-нибудь упрощённый дистрибутив вроде Simply, где такая политика авторизации рута документирована и подходит, но в общем случае это уязвимость.
в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или паковать в отдельный пакет
(In reply to comment #7) > вот здесь все прекрасно видно. если пользователь в группе wheel > авторизуем с паролем пользователя. если пользователь не в группе wheel > авторизуем с паролем рута Запрос на аналогичное поведение sudo (bug 18344) было решено не реализовывать. И тут оказывается, то в дистрибутивах с systemd есть второй путь для получения административных привилегий любым членом группы wheel.
To aris@ shrek@ shaba@ Пожалуйста, уделите внимание этому багу. ACL на пакет только на вас. Может быть просто удалить 50-default.rules?
(Ответ для nbr на комментарий #17) > To aris@ shrek@ shaba@ > Пожалуйста, уделите внимание этому багу. ACL на пакет только на вас. > Может быть просто удалить 50-default.rules?
(Ответ для Valery Inozemtsev на комментарий #15) > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или > паковать в отдельный пакет Считаю некорректным предлагать мантейнеру пакета просто откреститься, а пользователям и релиз-менеджерам расхлёбывать.
polkit-123-alt1 -> sisyphus: Mon Dec 04 2023 Valery Inozemtsev <shrek@altlinux.ru> 123-alt1 - 123 - is not packed 50-default.rules (closes: #35763)
> Mon Dec 04 2023 Valery Inozemtsev <shrek@altlinux.ru> 123-alt1 > - is not packed 50-default.rules (closes: #35763) 💩
А в p10 исправлять будут?
(Ответ для Sergey V Turchin на комментарий #22) > А в p10 исправлять будут? #335797
(Ответ для Valery Inozemtsev на комментарий #23) > (Ответ для Sergey V Turchin на комментарий #22) > > А в p10 исправлять будут? > > #335797 Кто-нибудь одобрит?
(Ответ для Sergey V Turchin на комментарий #19) > (Ответ для Valery Inozemtsev на комментарий #15) > > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или > > паковать в отдельный пакет > Считаю некорректным предлагать мантейнеру пакета просто откреститься, а > пользователям и релиз-менеджерам расхлёбывать. Ну конкретно ради Simply, где и так sudo настраивается пользователю, можно вынести в какой polkit-wheel-is-root. Но вообще этих веб-макак пороть в детстве надо было, конечно, а не набирать по объявлению системный софт писать :-/ Вчера собирал polkit-duktape 0.120 на сей счёт.
(Ответ для Антон Мидюков на комментарий #24) > > > А в p10 исправлять будут? > > #335797 > Кто-нибудь одобрит? Да.
(Ответ для Michael Shigorin на комментарий #25) > (Ответ для Sergey V Turchin на комментарий #19) > > (Ответ для Valery Inozemtsev на комментарий #15) > > > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или > > > паковать в отдельный пакет > > Считаю некорректным предлагать мантейнеру пакета просто откреститься, а > > пользователям и релиз-менеджерам расхлёбывать. > Ну конкретно ради Simply, где и так sudo настраивается пользователю, > можно вынести в какой polkit-wheel-is-root. > > Но вообще этих веб-макак пороть в детстве надо было, конечно, > а не набирать по объявлению системный софт писать :-/ > Вчера собирал polkit-duktape 0.120 на сей счёт. В каком смысле "ради Simply"? Давайте мы дружно пересядем с локальных пользователей на доменных и посмотрим на проблему их глазами. Предлагаю подумать откатить всё обратно. Либо предложить что-то разумное тысячам клиентов в домене, у которым после такого чудесного обновления в стабильном бранче отвалится доступ. Везде.
Никто не подумал, что нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять?
(Ответ для Evgeny Sinelnikov на комментарий #27) > (Ответ для Michael Shigorin на комментарий #25) > > (Ответ для Sergey V Turchin на комментарий #19) > > > (Ответ для Valery Inozemtsev на комментарий #15) > > > > в таком случае просто не паковать /etc/polkit-1/rules.d/50-default.rules или > > > > паковать в отдельный пакет > > > Считаю некорректным предлагать мантейнеру пакета просто откреститься, а > > > пользователям и релиз-менеджерам расхлёбывать. > > Ну конкретно ради Simply, где и так sudo настраивается пользователю, > > можно вынести в какой polkit-wheel-is-root. > > > > Но вообще этих веб-макак пороть в детстве надо было, конечно, > > а не набирать по объявлению системный софт писать :-/ > > Вчера собирал polkit-duktape 0.120 на сей счёт. > > В каком смысле "ради Simply"? > > Давайте мы дружно пересядем с локальных пользователей на доменных и > посмотрим на проблему их глазами. > > Предлагаю подумать откатить всё обратно. Либо предложить что-то разумное > тысячам клиентов в домене, у которым после такого чудесного обновления в > стабильном бранче отвалится доступ. Везде. Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить зависимость на него.
(Ответ для Evgeny Sinelnikov на комментарий #28) > Никто не подумал, что нужно не группу выпиливать, а правило polkit'а, по > умолчанию поменять? О выпиливании какой группы речь? Как поменять?
(Ответ для Антон Мидюков на комментарий #29) [...] > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить > зависимость на него. Звучит очень странно. Нет, так не пойдёт. Кто-нибудь может сказать какой action-id использует команда из-за которой весь сыр бор?: $ systemd-run -t /bin/sh
(Ответ для Evgeny Sinelnikov на комментарий #28) > нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять Так и сделали, вроде.
(Ответ для Evgeny Sinelnikov на комментарий #31) > (Ответ для Антон Мидюков на комментарий #29) > [...] > > > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить > > зависимость на него. > > Звучит очень странно. Нет, так не пойдёт. > Почему? В p10 поведение не меняется. В p11 правило может быть включено в состав коробки дистрибутива. Никто ничего не заметит.
(Ответ для Антон Мидюков на комментарий #33) > (Ответ для Evgeny Sinelnikov на комментарий #31) > > (Ответ для Антон Мидюков на комментарий #29) > > [...] > > > > > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить > > > зависимость на него. > > > > Звучит очень странно. Нет, так не пойдёт. > > > > Почему? В p10 поведение не меняется. В p11 правило может быть включено в > состав коробки дистрибутива. Никто ничего не заметит. В каком смысле не поменяется. То есть правило, что wheel - это группа с админскими привилегиями убрали. А через эту группу доменные пользователи только и могут получать сейчас привилегии. А доменные пользователи как будут их теперь получать? По паролю рута? (Ответ для Sergey V Turchin на комментарий #32) > (Ответ для Evgeny Sinelnikov на комментарий #28) > > нужно не группу выпиливать, а правило polkit'а, по умолчанию поменять > Так и сделали, вроде. Так, да не так... Вот дефолтные правила для action-id: $ cat /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy |grep -i -e yes -e "action id" <action id="org.freedesktop.packagekit.cancel-foreign"> <action id="org.freedesktop.packagekit.package-install"> <action id="org.freedesktop.packagekit.package-install-untrusted"> <action id="org.freedesktop.packagekit.package-reinstall"> <action id="org.freedesktop.packagekit.package-downgrade"> <action id="org.freedesktop.packagekit.system-trust-signing-key"> <action id="org.freedesktop.packagekit.package-eula-accept"> <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.package-remove"> <action id="org.freedesktop.packagekit.system-update"> - Changing this to anything other than 'yes' will break unattended <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.system-sources-configure"> <action id="org.freedesktop.packagekit.system-sources-refresh"> <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.system-network-proxy-configure"> <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.device-rebind"> - This should not be set to 'yes' as unprivileged users could then <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.upgrade-system"> <action id="org.freedesktop.packagekit.repair-system"> <action id="org.freedesktop.packagekit.trigger-offline-update"> <allow_active>yes</allow_active> <action id="org.freedesktop.packagekit.trigger-offline-upgrade"> <action id="org.freedesktop.packagekit.clear-offline-update"> <allow_active>yes</allow_active> Кто, вообще, решил, что удалённое правило является источником проблемы, обозначенной в заголовке этой задачи? $ id uid=758801104(sin) gid=758800513(domain users) группы=758800513(domain users),10(wheel),14(uucp),19(proc),22(cdrom),51(ftpadmin),71(floppy),80(cdwriter),81(audio),83(radio),100(users),101(localadmins),430(usershares),442(docker),448(vboxsf),451(hashman),461(vboxadd),463(fuse),467(video),477(vboxusers),480(camera),494(remote),498(xgrp),499(scanner),500(admin),501(sin_a),502(sin_b),758801110(software admins),758801125(server admins),758801126(docs admins),758801132(gpo admins),758801133(integration team),758801134(system team),758801136(public admins),758801178(workstation admins),758801183(security team) $ sudo cat /etc/polkit-1/rules.d/50-default.rules /* -*- mode: js; js-indent-level: 4; indent-tabs-mode: nil -*- */ // DO NOT EDIT THIS FILE, it will be overwritten on update // // Default rules for polkit // // See the polkit(8) man page for more information // about configuring polkit. polkit.addAdminRule(function(action, subject) { return ["unix-group:wheel"]; }); $ systemd-run -t /bin/sh ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Authentication is required to manage system services or other units. Authenticating as: Evgeny Sinelnikov (sin)
(Ответ для Evgeny Sinelnikov на комментарий #34) > (Ответ для Антон Мидюков на комментарий #33) > > (Ответ для Evgeny Sinelnikov на комментарий #31) > > > (Ответ для Антон Мидюков на комментарий #29) > > > [...] > > > > > > > > Можно отдельный пакет сделать c правилом. И именно в p10 у polkit поставить > > > > зависимость на него. > > > > > > Звучит очень странно. Нет, так не пойдёт. > > > > > > > Почему? В p10 поведение не меняется. В p11 правило может быть включено в > > состав коробки дистрибутива. Никто ничего не заметит. > > В каком смысле не поменяется. То есть правило, что wheel - это группа с > админскими привилегиями убрали. А через эту группу доменные пользователи > только и могут получать сейчас привилегии. > Я предложил в p10 собрать пакет с правилом, выставить зависимость у polkit в p10 на пакет с этим правилом. Итого в p10 это правило всегда будет, а в p11 его можно будет устанавливать или не устанавливать.
(Ответ для Антон Мидюков на комментарий #35) [...] > > Я предложил в p10 собрать пакет с правилом, выставить зависимость у polkit в > p10 на пакет с этим правилом. Итого в p10 это правило всегда будет, а в p11 > его можно будет устанавливать или не устанавливать. А что, в сущности, означает подход, при котором такое правило можно не устанавливать? По-моему, очень просто получается. Получается, что без знания пароля рута, запрещаются любые административные действия. Вариант без пароля я вообще не рассматриваю. Но в данном же случае речь совсем о другом. У меня 20 или 200 машин. С каким паролем рута их ставили уже никто не вспомнит. Логин осуществляется сетевым пользователем. Каким образом предлагается получать административные привилегии? Водораздел проходит по вопросу получения рутового shell'а. Чем systemd-run -t /bin/sh доступный по группе wheel, отличается от sudo /bin/sh по группе wheel. Про это никто не договоривался. Про это, по умолчанию, нет. Но дальше больше. Сейчас речь-то зашла о любых, вообще, административных действиях. Почему? Потому что action_id соответствующий org.freedesktop.systemd1.manage-units трактуется слишком широко. Ну, можно было бы его отключить...
По идее админские привилегии доменный пользователь должен получать через пароль доменного пользователя при условии вхождения в какую-то группу. Группа wheel лично меня устраивает, но у ldv были какие-то возражения по этому поводу (а может быть и не по этому). Самое главное - для перехода на более высокие привилегии обязательно должен запрашиваться пользовательский пароль (или использоваться другая схема авторизации, настроенная для доменного пользователя а pam)
Локальные привилегии назначаются на основании назначенных локальных групп. Переписывать все приложения для поиска новых групп-привилегий - штука непонятная. Делается такое назначение через модуль ролей. - без модуля libnss-role: $ grep ^group /etc/nsswitch.conf group: files [SUCCESS=merge] sss systemd $ id sin uid=87001104(sin) gid=87000513(domain users) группы=87000513(domain users),972(nfsuser),953(hashman),1001(sin_a),1002(sin_b),87000512(domain admins),87001115(dist admins),87000572(denied rodc password replication group) - с модулем libnss-role: $ grep ^group /etc/nsswitch.conf group: files [SUCCESS=merge] sss systemd role $ id sin uid=87001104(sin) gid=87000513(domain users) группы=87000513(domain users),972(nfsuser),953(hashman),1001(sin_a),1002(sin_b),87000512(domain admins),87001115(dist admins),87000572(denied rodc password replication group),100(users),36(vmusers),80(cdwriter),22(cdrom),81(audio),981(video),19(proc),83(radio),963(camera),71(floppy),998(xgrp),999(scanner),14(uucp),948(vboxusers),970(fuse),101(localadmins),10(wheel) Правила назначения групп: $ rolelst -V # Settings read from /etc/role: users:vmusers domain users:users domain admins:localadmins # Resulting settings merged with /etc/role.d entries users:vmusers,cdwriter,cdrom,audio,video,proc,radio,camera,floppy,xgrp,scanner,uucp,vboxusers,fuse domain users:users domain admins:localadmins localadmins:wheel,vboxusers powerusers:remote,vboxusers
(Ответ для Anton Farygin на комментарий #37) [...] > Самое главное - для перехода на более высокие привилегии обязательно должен > запрашиваться пользовательский пароль (или использоваться другая схема > авторизации, настроенная для доменного пользователя а pam) Ну, то есть согласен с rider@. И даже более того. Других особых вариантов повышения привилегий для доменных пользователей, кроме как по группе, особо не вижу.
(Ответ для Evgeny Sinelnikov на комментарий #39) > (Ответ для Anton Farygin на комментарий #37) > [...] > > Самое главное - для перехода на более высокие привилегии обязательно должен > > запрашиваться пользовательский пароль (или использоваться другая схема > > авторизации, настроенная для доменного пользователя а pam) > > Ну, то есть согласен с rider@. И даже более того. Других особых вариантов > повышения привилегий для доменных пользователей, кроме как по группе, особо > не вижу. Вторая неделя пошла, как дефолтное правило удалили в p10. Непонятно, почему не возвращаем назад, если это проблема для доменных пользователей. Или не проблема?
(Ответ для Антон Мидюков на комментарий #40) > > Других особых вариантов повышения привилегий для доменных пользователей, > > кроме как по группе, особо не вижу. > Вторая неделя пошла, как дефолтное правило удалили в p10. > Непонятно, почему не возвращаем назад, если это проблема для доменных > пользователей. Или не проблема? Напрашивается отдельный пакет с внятным именем.
(Ответ для Michael Shigorin на комментарий #41) > (Ответ для Антон Мидюков на комментарий #40) > > > Других особых вариантов повышения привилегий для доменных пользователей, > > > кроме как по группе, особо не вижу. > > Вторая неделя пошла, как дефолтное правило удалили в p10. > > Непонятно, почему не возвращаем назад, если это проблема для доменных > > пользователей. Или не проблема? > Напрашивается отдельный пакет с внятным именем. Не знаю, как насчёт внятности, но такой пакет теперь есть. Это polkit-default-rules. Багу закрываю.
