Установите пароль sudo иначе, чем логин

Как привилегированный пользователь, я пытаюсь установить пароль sudo на другой, который используется при входе в систему.

Я провел некоторое исследование, но не нашел ответа. Поддерживает ли sudo такую ​​конфигурацию?

Если вы когда-нибудь потеряете свой пароль, вы потеряете все. Кто-то может войти в систему и продвинуть себя, чтобы root с тем же паролем.

sudo имеет возможность запрашивать пароль root вместо вызываемого пароля пользователя ( rootpw ), но совместный пароль root определенно не является вариантом, поэтому мы настроили sudo .

В прошлом у меня была config 2FA , она отлично работала, но также поражала цель автоматизации. Например, если вы хотите выполнить привилегированную команду на дюжине серверов с сценарием expect , добавление 2FA не позволит вам это сделать.

Самое близкое решение, которое я нашел, – это разрешить только закрытый ключ SSH и настройку парольной фразы с ключом, который отличается от пароля sudo (login). Тем не менее, это не удобно, потому что в чрезвычайной ситуации вы не можете войти в систему с ПК, где у него нет этого ключа.

Если вы хотите запросить пароль root, в отличие от пароля пользователя, есть опции, которые вы можете поместить в /etc/sudoers . rootpw в частности, попросит пароль root. Существует также runaspw и targetpw ; подробнее см. справочную страницу sudoers (5).

Помимо этого, sudo выполняет свою аутентификацию (как и все остальное) через PAM. PAM поддерживает конфигурацию для каждого приложения. Конфигурация Sudo находится (по крайней мере, в моей системе Debian) /etc/pam.d/sudo и выглядит так:

 $ cat sudo #%PAM-1.0 @include common-auth @include common-account @include common-session-noninteractive 

Другими словами, по умолчанию он аутентифицируется как все остальное в системе. Вы можете изменить эту @include common-auth и иметь PAM (и, следовательно, sudo) использовать альтернативный источник пароля. Строки без комментариев в common-auth выглядят примерно так (по умолчанию это будет отличаться, если вы используете, например, LDAP):

 auth [success=1 default=ignore] pam_unix.so nullok_secure auth requisite pam_deny.so auth required pam_permit.so 

Вы можете использовать, например, pam_userdb.so вместо pam_unix.so , и хранить свои альтернативные пароли в базе данных Berkeley DB.

пример

Я создал каталог /var/local/sudopass , владелец / группа root:shadow , режим 2750 . Внутри я пошел вперед и создал файл базы данных паролей, используя db5.1_load (это версия DB Berkeley, используемая в Debian Wheezy):

  # umask 0027
 # db5.1_load -h / var / local / sudopass -t hash -T passwd.db
 Энтони
 WMaEFvCFEFplI
 ^ D 

Этот хэш был сгенерирован с помощью mkpasswd -m des , используя пароль «password». Очень надежно! (К сожалению, pam_userdb, похоже, не поддерживает ничего лучше, чем хэширование древнего crypt(3) ).

Теперь отредактируйте /etc/pam.d/sudo и удалите @include common-auth и вместо этого разместите это на месте:

 auth [success=1 default=ignore] pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd auth requisite pam_deny.so auth required pam_permit.so 

Обратите внимание, что pam_userdb добавляет расширение .db к переданной базе данных, поэтому вы должны оставить .db выключенным.

Согласно комментарию dannysauer в комментарии , вам может потребоваться сделать то же самое редактирование в /etc/pam.d/sudo-i .

Теперь, для sudo, я должен использовать password вместо моего реального пароля для входа:

  anthony @ sudotest: ~ $ sudo -K
 anthony @ sudotest: ~ $ sudo echo -e '\ nit работал'
 [sudo] пароль для anthony: p s s s o o r r RETURN

 это сработало 

Для Redhat / Centos это требование может быть достигнуто следующими шагами:

Создайте пользовательский пароль и выполните:

 # db_load -t hash -T /usr/local/etc/passwd.db user pass ^d 

Отредактируйте файл sudo pam.d так, чтобы он выглядел так:

 $ cat /etc/pam.d/sudo auth required pam_userdb.so db=/usr/local/etc/passwd account required pam_userdb.so db=/usr/local/etc/passwd password include system-auth session optional pam_keyinit.so revoke session required pam_limits.so 

Я все еще ищу путь для конфигурации, так что только этот пользователь / группа должен быть аутентифицирован этим настраиваемым методом, другие могут быть аутентифицированы обычным методом system-auth. Может ли кто-нибудь дать мне несколько советов?

Я не думаю, что sudo поддерживает такую ​​настройку. Цель приглашения пароля sudo заключается в том, чтобы гарантировать, что человек, выдающий команду sudo, является тем же лицом, которое зарегистрировано, и самый простой способ сделать это – попросить зарегистрированного пользователя выполнить повторную аутентификацию.

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

Ваша проблема заключается в том, что пароль вашей учетной записи может быть раскрыт. Решение состоит в том, чтобы не использовать пароль для входа в систему таким образом, чтобы он мог быть раскрыт. С помощью ssh пароль зашифровывается на проводе, так что это нормально. Люди отключают пароль auth с помощью ssh, чтобы предотвратить атаки с угадыванием пароля, а не для защиты конфиденциальности паролей. Если вы используете один и тот же пароль учетной записи для чего-либо еще, убедитесь, что вы используете безопасный, зашифрованный канал для предоставления пароля. Если вас беспокоит кейлоггер или что-то еще, прекратите использование ненадежных машин для входа в систему.

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

У меня нет прямого доступа к системе, где я могу проверить это и детализировать, но у меня есть идея:

  • (Предположим, что ваша обычная учетная запись – shau .)
  • Создайте вторую учетную запись: shau2 . (Я не уверен, хотите ли вы, чтобы он имел тот же UID, что и shau .)
  • Настройте shau2 для получения привилегий sudo с помощью NOPASSWD.
  • Настройте псевдоним или сценарий оболочки, чтобы сделать su shau2 -c sudo "$@" . Это должно потребовать пароль shau2 . Если это введено правильно, он будет запускать sudo как shau2 (который не должен запрашивать пароль).
  • Удалите sudo привилегии shau .

К сожалению, вам придется повторить это для каждого пользователя, у которого есть привилегии sudo.

Спасибо @ Shâu Shắc за ответ ! Это решение также работает для LinuxMint 17.1 Cinnamon 32bit (я только установил пакет db-util для запуска db_load ).

Но я очень смущен результирующему файлу passwd.db . Я сделал то же самое, что и в вашем ответе (но использовал Дэвида и Джонса , они выглядят более привлекательными):

 # db_load -t hash -T /usr/local/etc/passwd.db david jones ^d 

Но введенные учетные данные сохраняются в хэш-файле в виде обычного текста:

 # grep 'jones.*david' /usr/local/etc/passwd.db Binary file /usr/local/etc/passwd.db matches 

Вы также можете увидеть david и jones через mcedit :

введите описание изображения здесь

Да, можно ограничить права доступа /usr/local/etc/passwd.db . Но в любом случае имя пользователя и пароль, хранящиеся в виде обычного текста, являются плохими.


Даже с отдельным паролем sudo есть некоторые потенциальные дыры в безопасности (по умолчанию настройка дистрибутива). Таким образом, отдельный пароль не применим для su (поэтому можно запустить корневой сеанс, используя su и пароль для входа). Отдельный пароль не соблюдается Policy Kit (можно запустить Synaptic, используя synaptic-pkexec и пароль для входа в систему, а затем удалить пакеты …). Эти проблемы могут быть устранены путем дополнительной настройки файлов конфигурации.

В общем, кажется, что безопасный отдельный пароль sudo может быть достигнут только с помощью настраиваемого модуля PAM (возможно, такой модуль будет сравнивать пароль и хэш SHA-512, читаемый из файла) или функциональность SELinux.

PS: извините, это должен быть комментарий. Но это идет как ответ из-за текстового формата. Спасибо за понимание.