[devel] Политика безопасности в дистрибутивных решениях

Чт Дек 14 09:21:24 MSK 2023

Доброй ночи,

хочу обратить внимание на последнее обновление 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)
