Bug 41508 - В дистрибутиве по умолчанию не настроен sudo
Summary: В дистрибутиве по умолчанию не настроен sudo
Status: CLOSED WONTFIX
Alias: None
Product: ALT Linux KDesktop
Classification: Distributions
Component: Состав (show other bugs)
Version: не указана
Hardware: x86_64 Linux
: P5 normal
Assignee: Nobody's working on this, feel free to take it
QA Contact: qa-p7@altlinux.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-05 18:04 MSK by Арбичев Игорь
Modified: 2021-12-07 18:34 MSK (History)
14 users (show)

See Also:


Attachments
конфигурационный файл (3.47 KB, text/plain)
2021-12-05 18:04 MSK, Арбичев Игорь
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Арбичев Игорь 2021-12-05 18:04:43 MSK
Created attachment 10027 [details]
конфигурационный файл

В дистрибутиве в файле sudoers закомментированы строки:
# Defaults targetpw  # Ask for the password of the target user
# ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults targetpw'
Вследствие этого команда sudo не работоспособна, она не срабатывает ни на пароль пользователя root, ни на пароль пользователя, под которым выполнен вход в систему.
Примечание: Файл переименован, так надо было.
Comment 1 Alexander Yereschenko 2021-12-05 21:35:35 MSK
Повторю ту же позицию, которую высказывал на форуме по этому поводу.
Безопасность и удобство - увы, но одновременно невозможно.
Ради одномоментного личного удобства (лени настроить так, так лично себе удобно) жертвовать общей безопасностью по умолчанию нельзя.
Если раскомментировать указанные строчки, то безопасность системы по умолчанию существенно понижается. И большинство пользователей после установки просто так и оставят, просто потому что об этом даже и не догадываются.
А вот наоборот, тому, кому очень нужно именно такой небезопасный, но типа удобный вариант настройки sudo - тот должен это сделать сам и сознательно - прочитать комментарий и раскомментировать соответствующие строки, либо настроить как-то иначе под свои надобности.
Comment 2 Sergey V Turchin 2021-12-06 10:12:31 MSK
А в чём состоит предложение? Изменить то, что закоментировано? Если да, на что?
Comment 3 Evgeny Sinelnikov 2021-12-06 12:01:19 MSK
Для этой задачи существует control sudowheel:

ryze ~ # control sudowheel help
disabled: Disable sudo for wheel users
enabled: Enable sudo for wheel users

ryze ~ # control sudowheel summary
sudo rule "ALL=(ALL) ALL" for wheel users

Включение настройки.
ryze ~ # control sudowheel enabled

Думаю, что в нашей системе необходимы два механизма:
1) Модуль альтератора, который позволяет явно переключаться между документированными режимами безопасности;
2) Инструментарий позволяющий тиражировать выбор предпочитаемой модели безопасности на последующие экземпляры собственных установок.
Comment 4 Evgeny Sinelnikov 2021-12-06 12:04:09 MSK
Мой более развёрнутый ответ из телеграма:

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 оказывается нужен для обычного пользователя для слишком
широкого числа задач, чем это следует.
Comment 5 Evgeny Sinelnikov 2021-12-06 12:11:00 MSK
Для реализации инструментария позволяющего тиражировать выбор предпочитаемой модели безопасности на последующие экземпляры собственных установок, я думаю, что должен быть выбор на этапе установки. Но для этого нужен модуль альтератора.
Comment 6 AEN 2021-12-06 12:21:21 MSK
(Ответ для Арбичев Игорь на комментарий #0)
> Создано вложение 10027 [details] [подробности]
> конфигурационный файл
> 
> В дистрибутиве в файле sudoers закомментированы строки:
> # Defaults targetpw  # Ask for the password of the target user
> # ALL ALL=(ALL) ALL  # WARNING: only use this together with 'Defaults
> targetpw'
> Вследствие этого команда sudo не работоспособна, она не срабатывает ни на
> пароль пользователя root, ни на пароль пользователя, под которым выполнен
> вход в систему.
> Примечание: Файл переименован, так надо было.

http://www.opennet.ru/openforum/vsluhforumID3/73378.html#18
Comment 7 Sergey V Turchin 2021-12-06 12:28:55 MSK
(Ответ для Evgeny Sinelnikov на комментарий #3)
> Для этой задачи существует control sudowheel:
Может, стоит написать про это в коментариях /etc/sudoers ?
Где-то рядом с "WARNING"?
Comment 8 Sergey V Turchin 2021-12-07 18:05:09 MSK
В Workstation K менять умолчательные настройки sudo планов нет.
Comment 9 Sergey Y. Afonin 2021-12-07 18:34:38 MSK
(In reply to Арбичев Игорь from comment #0)

> Вследствие этого команда sudo не работоспособна, она не срабатывает ни на
> пароль пользователя root, ни на пароль пользователя, под которым выполнен
> вход в систему.

И это правильно:
https://bugzilla.altlinux.org/show_bug.cgi?id=18344#c18