Какой пароль пользователя запрашивает `sudo`?

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 136808 Jul  4  2017 /usr/bin/sudo

так что он sudoможет быть запущен любым пользователем, и любой пользователь, который запускается, sudoбудет иметь root в качестве эффективного идентификатора пользователя процесса, потому что установлен бит set-user-id /usr/bin/sudo.

С https://unix.stackexchange.com/a/11287/674

Наиболее заметное различие между sudo и su в том, что sudo требует пароль пользователя, а su требует пароль root.

1. Какой пароль пользователя sudoзапрашивает? Это пользователь, представленный реальным идентификатором пользователя процесса?

   Если да, не может ли какой-либо пользователь получить привилегию суперпользователя, запустив sudoи затем предоставив свой собственный пароль? Может ли Linux ограничить это для некоторых пользователей?

2. Является ли это исправить , что sudoзапрашивает пароль после execve() того, как начинает выполняться main()из /usr/bin/sudo?

   Поскольку euid процесса был изменен на root (поскольку бит set-user-id в / usr / bin / sudo установлен), какой смысл sudo запрашивать пароль позже?

Спасибо.

Я прочитал https://unix.stackexchange.com/a/80350/674 , но он не отвечает на вопросы выше.

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

   sudoне обязательно дает право стать пользователем root, оно может предоставлять различные привилегии. Любой пользователь, которому разрешено стать пользователем root, sudoersможет сделать это, используя только свою собственную аутентификацию; но пользователь не может, не может (по крайней мере, не используя sudo). Это не обеспечивается самим Linux, но sudo(и его настройки аутентификации).

2. sudoдействительно запрашивает пароль после его запуска; он не может сделать иначе ( то есть он не может ничего сделать до того, как начнет работать). Смысл sudoзапроса пароля, даже если он root, заключается в проверке личности работающего пользователя (в его типичной конфигурации).

sudoобычно запрашивает пароль пользователя, который его запускает, хотя это можно настроить :

В отличие от того su(1), когда sudoersтребуется аутентификация, он проверяет учетные данные вызывающего пользователя, а не учетные данные целевого пользователя (или пользователя root). Это может быть изменено с помощью rootpw, targetpwи runaspwфлагов, описанных ниже.

Установка rootpwимеет sudoвсегда спрашивать пароль суперпользователя, targetpwзапрашивает пароль пользователя sudo, в конечном счете запустить программу , как и runaspwзапрашивает пароль множества пользователей в runas_default.

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

Примерно так же, любой процесс может также выполнить код в режиме ядра, вызвав, скажем, любой системный вызов open(). (это не то же самое, что код пользовательского пространства и root.) Пока ядро ​​не содержит ошибок, оно не сможет запускать произвольный код.

Из первой строки man sudo:

ОПИСАНИЕ
sudo позволяет разрешенному пользователю выполнять команду от имени суперпользователя или другого пользователя, как указано в политике безопасности. Реальный (не эффективный) идентификатор вызывающего пользователя используется для определения имени пользователя, с которым запрашивается политика безопасности.

Так:

1. Реальный (не эффективный) идентификатор пользователя вызывающего используется ...

2. Да, любой ( разрешенный ) пользователь может получить суперпользователю (или другим) дополнительные привилегии, запустив sudo, а затем предоставив ( настроенную ) требуемую аутентификацию. И разрешенные, и настроенные заданы в файле (ах) sudoers.

3. Может ли Linux ограничить это для некоторых пользователей?
   Да, может, но это не так. В Linux установлено, что двоичный файл sudo может принимать решение на основе набора правил (политики безопасности) внутри программы sudo и внутри файла /etc/sudoers. Обычно могут использоваться другие файлы (также / вместо).

От man setresuid:

ОПИСАНИЕ
setresuid () устанавливает реальный идентификатор пользователя, эффективный идентификатор пользователя и сохраненный set-user-ID вызывающего процесса.

4. Единственный способ получить права суперпользователя, предоставляемые ядром, - запустить программу suid. Иначе быть не может. Это способ, которым Linux выбрал предоставление прав суперпользователя.

5. После того, как ядро ​​загрузило исполняемый файл, который не может быть изменен любым другим пользователем (файл и каталог принадлежат пользователю root и доступен для записи только пользователю root), сам исполняемый файл (sudo) аутентифицирует пользователя, запрашивая его пароль (или что-то еще, как настроено) и решает, если и какие разрешения предоставить.

Дополнительно к другим хорошим ответам о sudo:

suпозволяет эффективно стать другим пользователем. На моем собственном компьютере я не работаю администратором для повседневного использования, а это значит, что я не могу (напрямую) пользоваться sudo. Если я действительно хочу использовать sudo, я могу использовать, suчтобы «стать» администратором пользователя, а затем в этой роли использовать sudo. В этой ситуации я в конечном итоге ввожу пароль учетной записи администратора дважды - один раз при запуске suи один раз при запуске sudo.