From: Evgeny Sinelnikov <sin@altlinux.org> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: [devel] Политика безопасности в дистрибутивных решениях Date: Thu, 14 Dec 2023 10:21:24 +0400 Message-ID: <CAK42-GrbjYP=cG02jsPPHNwutnDsjUUcanTt37txvWZ9wPhVzg@mail.gmail.com> (raw) Доброй ночи, хочу обратить внимание на последнее обновление polkit, причины этого обновления и последствия, которые в результате мы получим, если в ближайшее время не исправим то, что получилось. = Текущие вопросы = В последних обновлениях polkit было решено удалить правило наделяющее административными привилегиями для системных сервисов на шине dbus группу wheel: - https://packages.altlinux.org/ru/tasks/335977/ (sisyphus) - https://packages.altlinux.org/ru/tasks/335797/ (p10) _____________ @@ -103,7 +103,7 @@ touch ChangeLog %files -f %name-1.lang %dir %_sysconfdir/%name-1 %attr(0700,polkitd,root) %dir %_sysconfdir/%name-1/rules.d -%_sysconfdir/%name-1/rules.d/50-default.rules +%exclude %_sysconfdir/%name-1/rules.d/50-default.rules %_datadir/dbus-1/system.d/org.freedesktop.PolicyKit1.conf %_sysconfdir/pam.d/polkit-1 %_bindir/pk[act]* # 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 успешно срабатывает для пользователя из группы wheel" - https://bugzilla.altlinux.org/35763 "Позволяет установить любой пакет пользователю из группы wheel без пароля" - https://bugzilla.altlinux.org/48431 Там довольно большая переписка, суть которой можно свести к следующему: 1) в нашей сборке packagekit было написано вот такое (см. ниже) правило, по которому любой пользователь из группы wheel (в том числе и любой скрипт) может установить любой пакет из репозитория без ввода пароля: $ rpm -qf /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules packagekit-1.2.5-alt7.x86_64 $ sudo cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.packagekit.package-install" && subject.active == true && subject.local == true && subject.isInGroup("wheel")) { return polkit.Result.YES; } }); По мне, так оригинального auth_admin_keep было бы достаточно. А такое поведение packagekit по умолчанию, ну, совершенно недопустимо с точки зрения безопасности. 2) в нашей сборке systemd команда 'systemd-run -t /bin/sh', аналогичная 'sudo /bin/sh', проверяется общим action_id 'org.freedesktop.systemd1.manage-units' $ 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: В результате логика безопасности по умолчанию, при которой sudo с правилом "пользователю в группе 'wheel' доступна любая команда из под рута" по умолчанию отключена, оказалась нарушена. По мне так ничего супер-крамольного в этом нет, но некоторая несогласованность, всё-таки, неприятна. И для сизифа текущее решение вполне подходит. Но для p10, всё-таки, поздновато так сильно менять поведение. _____________ В одной стороны, первая проблема при этом так и не решена. И это, как бы, не такой уж и плюс. С другой стороны, никто не стал просчитывать последствия текущего решения для второй проблемы. И это, точно, минус. Теперь, по умолчанию, поведение polkit'f вместо такого: $ systemctl restart sshd ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Чтобы перезапустить «sshd.service», необходимо пройти аутентификацию. Multiple identities can be used for authentication: 1. Local Administrator (localadmin) 2. Evgeny Sinelnikov (sin) Choose identity to authenticate as (1-2): ^C будет таким (polkit-agent может быть и графическим, это не важно): $ systemctl restart sshd ==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ==== Чтобы перезапустить «sshd.service», необходимо пройти аутентификацию. Authenticating as: System Administrator (root) Password: То есть теперь мы получаем выровненную, по умолчанию, логику проверки привилегий для systemd-run. То есть, после обновления почти все pokit-проверки административных действий будут запрашивать пароль исключительно рута. Как при запуске acc, который больше ничего не умеет. В каком-то смысле, это плюс, но какой-то сомнительный. "Почти" все (а не все), потому поведение поменяется только для тех polkit-проверок административных действий, для которых отсутствуют, явные правила в /usr/share/polkit-1/rules.d и /etc/polkit-1/rules.d/. При этом те, кто пользуются sudo с паролем и пароль рута уже давно забыли (или никогда не знали - см. ниже "доменные пользователи") столкнуться с проблемами. И это, безусловно, минус. _____________ Вот список установленных у меня пакетов, которых частично НЕ заденет текущее исправление, поскольку для них имеются явные правила в /usr/share/polkit-1/rules.d: $ sudo ls /usr/share/polkit-1/rules.d | while read n; do echo -ne "$n:\t"; rpm -qf /usr/share/polkit-1/rules.d/$n; done blueman.rules: blueman-2.3.5-alt1.x86_64 lightdm.rules: lightdm-1.32.0-alt4.x86_64 org.a11y.brlapi.rules: brltty-6.5-alt1.1.x86_64 org.freedesktop.Flatpak.rules: flatpak-1.14.4-alt1.x86_64 org.freedesktop.GeoClue2.rules: geoclue2-2.7.1-alt1.x86_64 org.freedesktop.packagekit.rules: packagekit-1.2.5.0.0.30-alt1.x86_64 org.gtk.vfs.file-operations.rules: gvfs-backend-admin-1.52.1-alt1.x86_64 sssd-pcsc.rules: sssd-2.9.3-alt1.x86_64 То есть, мы имеем, вообще говоря две проблемы - у нас не только packagekit позволяет без пароля устанавливать приложения из условно доверенных источников, но и flatpak из, вероятно, недоверенных (поправьте, если я не прав). "Частично" (а не совсем не заденет) потому что polkit-проверок административных действий (action_id) много разных, а правила только для некоторых сделаны. _____________ А вот кого затронет больше всего текущее решение второй проблемы. И я на это, прежде всего, обращаю внимание. 1. Первая группа. Локальные пользователи, которые используют sudo (а это большинство локальных пользователей) и которые не помнят пароль рута. 2. Вторая, менее защищённая группа - это пользователи, работающие из-под сетевых учётных записей. Назовём их "доменными пользователями". Такие пользователи, по определению, не должны знать и помнить пароль рута на каждой из, возможно, тысяч машин в единой инфраструктуре. С какими проблемами столкнуться такие пользователи? На самом деле проблем как бы не так уж и много - отвалится всё, что вчера работало через dbus: - настройки NetworkManager; - установка ПО через Gnome Software; - установка даты и времени в графике (через тот же интерфейс, который используется для timedatectl); - возможность выполнять административные команды через systemctl, journalct, hostnamectl и т.п. - возможность работы с gparted; - возможность монтирования дисков графике через UDisks2; - возможность запуска Альтератора на dbus; - ... Самое критичное - это настройка сети, конечно. Хотя новый Альтератор на dbus меня тоже беспокоит. Некоторые подробности по поводу альтератора доступны в тезисах нашей последней конференции: - https://www.basealt.ru/conference/ezhegodnaja-konferencija-razrabotchikov-svobodnykh-programm - https://www.basealt.ru/fileadmin/user_upload/dev-conf/Pereslavl-summer-2023-Ossdevconf-XIX.pdf Не хотелось бы городить правил в обход общего концепта безопасности. К сожалению, он пока недостаточно формализован в рамках наших политик сообщества (ALT Policies): - https://www.altlinux.org/Policy_Policy Со своей стороны скажу, что решение не может и должно выполняться только в рамках отдельных дистрибутивных сборок, поскольку инструменты администрирования, важны на каждом клиенте. И какой-то общий подход следует сформулировать. _____________ = Общее представление о политике безопасности = Какое-то время назад (почти два года как) я попытался на очередной вопрос в телеграм-канале о политике безопасности дать развёрнутый ответ: - https://telegram.me/alt_linux Ниже привожу текст в оригинале: Dmitry, [21.11.21 16:27] Подскажите, а в чем великий смысл раскоментирования wheel в sudoers?) Evgeny Sinelnikov, [21.11.21 20:38] [In reply to Dmitry] Это базовый "дефолт", связанный со встроенной политикой безопасности - не давать доступа обычным пользователям к suid'ным программам. И прежде всего, к бесконтрольному повышению привилегий. Я вижу тут следующие режимы: - стандартный. sudo не используется (можно вообще удалить). Для перехода в рута нужно: а) знать пароль рута, б) быть в группе wheel (иначе даже su - не запустить). Все инструменты, даже графические требуют пароль рута. Параллельно, существует dbus и политика по умолчанию, что все административные действия через PolicyKit допускаются только для пользователя в группе wheel. При этом уже запрашивается пароль пользователя. - традиционный, про который вы спрашиваете. sudo используется в самом расширенном виде - любые команды из-под рута. Плюс остаются все возможности стандартного режима. Хотя в этом режиме пароль рута уже не требуется. sudo запрашивает пароль пользователя и отрабатывает только для тех пользователей, которые входят в группу wheel. - дальше есть два направления в настройке режимов: + ужесточение ограничений; + расширение инструментальных средств, предоставляющих рутовые привилегии. Ужесточение ограничений приводит к тому, что не для всех задач оказывается достаточно одной лишь группы wheel. Это и правила selinux и других средств мандатного доступа, и закручивание гаек, в рамках доступа к различным традиционно суидным утилитам (ping, mtr, growisofs, и т.п.) по группам (например, xgrp для xorg-server или netadmin для ping и mtr, кроме того уже с ходу включены vmusers и vboxusers для kvm и virtualbox). Назначение групп, при этом, можно гибко задавать через модуль ролей (группы в группах - из пакета libnss-role), когда пользователю назначается не заданный список групп при установке или добавлении, а через группы users, powerusers, localadmins (соответствующий модуль alterator-roles сейчас находится в стадии отладки, модуль alterator-users при этом с ним интегрирован). Расширение инструментальных средств предоставляющих рутовые привилегии уже давно реализуется различными приложениями и гибко управляется через Dbus и PolicyKit. Например, для открытия файлового дескриптора устройства нет необходимости предоставлять пользователю непосредственный доступ через права на файл. Файл может быть открыт соответствующей службой и его файловый дескриптор может быть на основании группы или другого правила в PolicyKit передан непосредственно приложению. Именно так работает сейчас ALT Media Writer. Кроме того, под эти цели написана и запланирована с дальнейшему развитию служба alterator-dbus, позволяющая организовать dbus интроспекцию модулей альтератора и обеспечить доступ к существующим модулям через этот встроенный, высокоуровневый IPC. Аналогично тому, как устроены systemctl, nmcli, hostnamectl и т.п. При достаточно развитом наборе расширенных инструментальных средств, предоставляющих доступ к рутовым привилегиям для отдельных задач, "sudo для всех команд из-под рута" выглядит всё больше дырой для разработчика, чем инструментом для обычного пользователя. Таким образом "великий смысл" специально включать традиционный режим для sudo состоит в том, чтобы сохранять направление развития, связанное с тем, чтобы исключить использование sudo, как механизма, для непривилегированного пользователя и включать его каждый раз только тогда, когда это требуется. К сожалению, темпы развития всего этого комплекса доработок происходят очень медленно. И, фактически, парольный sudo оказывается нужен для обычного пользователя для слишком широкого числа задач, чем это следует. = Расширенное представление о политике безопасности = Пожалуй, остановлюсь и дальнейшее буду вносить сюда: https://www.altlinux.org/Security_Policy Конкретные предложения сформулирую чуть позже. -- Sin (Sinelnikov Evgeny)
next reply other threads:[~2023-12-14 6:21 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-12-14 6:21 Evgeny Sinelnikov [this message] 2023-12-14 11:54 ` Paul Wolneykien 2023-12-14 12:55 ` Павел Исопенко
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAK42-GrbjYP=cG02jsPPHNwutnDsjUUcanTt37txvWZ9wPhVzg@mail.gmail.com' \ --to=sin@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git