[devel] sudo/wheel

Чт Ноя 15 11:27:45 MSK 2018

Здравствуйте,

очень сложно комментировать множество разнородных доводов из другого
контекста. Проблема sudo/wheel - это проблема политики. А политика
всегда противоречива.

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

Если мы хотим иметь гибкую, строгую, единую пакетную базу, нам
приходится иметь по умолчанию более строгие предпочтения. Это понятно.

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

пн, 12 нояб. 2018 г. в 21:16, Alexey V. Vissarionov <gremlin at altlinux.org>:
>
> On 2018-11-09 14:21:32 +0400, Evgeny Sinelnikov wrote:
>
>  >>>> В группу wheel добавляют конкретных пользователей. Так что
>  >>>> все пользователи конкретны. Какие ещё конкретные возражения
>  >>>> по этой конкретной настройке?
>  >>> Сейчас в группу wheel добавляют в принципе тех, кому можно
>  >>> позвать sudo (с control sudo wheelonly). А тут раз - и они
>  >>> получают все права.
>  >> Права на запуск sudo (как и любого другого suid-бинарника) надо
>  >> давать отдельной группе (в данном случае sudoers). А %wheel уже
>  >> использовать в /etc/sudoers
>  >> То, что у нас control-файл для sudo такой же, как для su - это
>  >> само по себе ошибка.
>  > Группа wheel не принадлежит программе su. Это более широкая
>  > группа. Поэтому, если "сейчас в группу wheel добавляют в
>  > принципе тех, кого можно позвать sudo", тем кто не хочет
>  > сразу "звать sudo", можно этот пакет просто не устанавливать.
>
> Ура! Дядя Женя разрешил не ставить sudo! :-)

Не за что. Всегда пожалуйста.

>  > Да и нет особого смысла давать wheel без пароля рута.
>
> Жень, ты когда в прошлый раз администрировал что-то критичное? Ну,
> хотя бы такое, что в случае косяка придется несколько лет ущерб
> компенсировать?
>
> Пользователь root в таких системах, как правило, заблокирован чуть
> более, чем полностью, и лишь в редчайших случаях под ним бывает
> можно зайти по SSH.

У меня есть встречный вопрос. Ты когда последний раз просил своего
сына или подругу (не ITшника), по быстрому, уcтановить и настроить
программу на своём десктопе или ноутбуке самостоятельно?

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

>  > На самом деле, есть один разумный вариант - это давать wheel
>  > для su в другого пользователя. Но это редкий случай. И для
>  > умолчания он не подходит.
>
> Группа wheel - админская. Какие права ей давать, в общем случае
> решают сами администраторы, но в большинстве случаев это доступ
> к чтению логов (0640 root:wheel /var/log/*) и конфигов. Просто
> для того, чтобы лишний раз не работать с UID==0.

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

Можно называть это как угодно (Windows-подходом или Убунту-стилем), но
простые в администрировании решения тоже нужно уметь строить.

>  > А речь идёт об умолчаниях. Я ещё раз это подчёркиваю. Я не
>  > понимаю зачем давать wheel, как повод потом "позвать sudo"?
>  > Почему оно сразу не должно работать? Для какого разумного
>  > варианта использования этот промежуточный этап имеет смысл?
>
> Попробую объяснить: sudo - это средство повышения привилегий
> пользователя, что противоестественно (в норме привилегии только
> понижаются). При этом сам по себе любой бинарник с установленным
> SetUID создает риски для системы (обычно со средней вероятностью
> и высоким ущербом), где повлиять на уровень ущерба нельзя (root
> может делать что угодно), зато можно снизить вероятность хотя бы
> до низкой (а еще лучше очень низкой), сузив круг пользователей,
> которым этот бинарник доступен для выполнения.

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

Значит так. Захожу я под рутом (как-то) и боюсь что-нибудь сломать.
Дай, думаю понижу себе приоритет. Так это что-ли работает?

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

> Поэтому su следует держать с правами 0711 root:root, а sudo - с
> правами 4710 root:sudoers. И еще в httpd есть suexec - для него
> полагается выставлять 4710 root:httpd
>
> А общедоступных suid-бинарников в грамотно настроенной системе
> быть не должно вообще ни при каких условиях.
>
>  > Чем включенный парольный sudo удобен - понятно (первое, что делаю
>  > я и многие пользователи Альтов после установки системы - это
>  > лезут настраивать sudo). А чем настроенный вариант объективно
>  > плох (помимо личных предпочтений и традиции, которые тоже
>  > стоит учитывать, конечно) есть внятные аргументы?
>  >
>  > У меня есть. Пароль даже первого пользователя может быть не
>  > так строг, как пароль рута. Но ssh для такого пользователя тоже
>  > будет работать. Я бы тут предложил здесь включить ограничение
>  > на строгость пароля для пользователя через ssh, при сохранении
>  > возможности заходить нестрогим паролем локально.
>
> Ты, наверное, сильно удивишься, но администраторы давно решили
> эту дилемму:
>
> gremlin at nb:~ > grep -i password /etc/ssh/sshd_config
> PasswordAuthentication  no
> PermitEmptyPasswords    no
> PermitRootLogin         without-password
>
> Это мой домашний ноутбук, но SSH у меня везде настроен одинаково,
> то есть в точности так же, как на боевых серверах, доступных из
> внешнего мира. Да, заодно рекомендую обратить внимание на то, что
> для цитирования конфига мне хватило прав обычного пользователя:
>
> gremlin at nb:~ > ll /etc/ssh/sshd_config
> -rw-r----- 1 root wheel 933 июн 16  2016 /etc/ssh/sshd_config

И как эти настройки решают описанную выше проблему? Вот
устанавливается ОС. Вот мы отключили аутентификацию в ssh по паролю.
Супер. Дальше что? Давайте тогда в документации сразу писать о том,
как сгенерировать ssh-ключи.

Даже студенты факультета компьютерных наук не особо в этом разбираются
на первых курсах (а некоторые и на последних), ибо давние пользователи
популярной ОС, в том числе и Убунты.

>  > В целом, я не понимаю содержания спора. Я откатил sudo, до
>  > оригинального состояния с этой политикой. Планирую включить в
>  > Альтератор возможность её включения. Зачем спорить по поводу
>  > её необходимости по умолчанию, если задача не стоит в том,
>  > чтобы это утвердить?
>
> Лично у меня к sudo ровно два пожелания:
> 1. Выставить для /usr/bin/sudo права 4710 root:sudoers
> 2. Вынести все "политики по умолчанию" в /etc/sudoers.d/*

Конструктивные пожелания - это хорошо. А как они вписываются в
настройку для уже установленных решений? Что будет с правами в системе
после обновления до реализации этих пожеланий?

>  > Мне тут очевидно только одно - желающих следовать исходному
>  > варианту в рамках личных предпочтений и сложившейся традиции
>  > достаточно много. А те, кому это неудобно, в [devel] не активны
>  > или, вообще, в нём отсутствуют. Я получил в багзиле пока только
>  > один отзыв поддержку. В рассылке положительных отзывов не
>  > было совсем.
>  > Лично моё мнение тут такое - тех, кому такое умолчание для sudo
>  > было бы удобно, достаточно много, но они почему-то об этом не
>  > высказываются.
>
> Значит, для этого умолчания надо сделать пакет sudo-policy-wheel
> (так даже лучше, чем sudo-defaults-wheel), куда поместить файл
> /etc/sudoers.d/wheel примерно такого содержания:
>
> %wheel ALL = (ALL) ALL

Такой пакет с настройками уже обсуждался. И он имеет право на
существование, но это - не решение. Это тот же неудобный костыль,
только для него ещё и сеть нужна, чтобы настроить первоначально
дескотпную систему. Для сертифицированных SPT решений - это, вообще,
мрак. Доставить пакет с настройками там как-то не очень логично.

Да и, собственно, зачем это? Сейчас, после установки десктопной
системы, нужно войти в первого юзера, у котрого есть wheel, потом
сделать su -, потом поправить файл /etc/sudoers. Что предлагается
вместо этого? Всё тоже самое, только вместо "поправить один файл"
нужно предварительно настроить сеть, проверить и настроить apt и, если
имеется доступ к интернет, обновить базы apt и установить пакет, имя
которого нужно ещё вспомнить.

Если серьёзно, то это не рабочий вариант.

--
Sin (Sinelnikov Evgeny)