Когда Ubuntu запрашивает пароль администратора, как он решает, какой административный пользователь должен попросить?

Ясно, что sudo был бы первым выбором для меня в таком случае. Судя по всему, большинство (фактических) админов фактически не используют /etc/sudoers в максимально возможной степени (User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

Большинство админов используют только некоторые из существующих правил и добавляют пользователей или, что еще хуже, просто добавляют пользователей в группу sudo, для которой правило обычно существует в настройках Ubuntu (%sudo ...).

Учитывая ваш комментарий:

Я считаю, что вы также не используете его, насколько это возможно.

В таком сценарии, как ваш, я бы буквально списал несколько действий, к которым Боб должен быть ограничен. На самом деле это то, что я сделал на сервере, который я поддерживаю, чтобы разрешить двум конкретным пользователям перезагружать отдельного гостя KVM на хосте. Сценарии будут содержать хешбанг с абсолютным путем к интерпретатору (например, #!/bin/dash вместо #!/usr/bin/env bash) и, вероятно, запускаться с оболочкой, которая используется в других местах для привилегированных задач (/bin/dash или /bin/sh). Это всего лишь меры предосторожности. Помимо этого, я бы убедился, чтобы жестко закодировать все абсолютные пути к двоичным файлам и использовать как можно больше из них. Например. при использовании bash / dash я предпочел бы builtin s по command s (см. man bash). Вы можете сделать это поддерживаемым, назначив переменную абсолютный путь и ссылаясь на программу, основанную на этой переменной ($VIRSH вместо /usr/bin/virsh). Если вы можете, проверьте все внешние скрипты перед их вызовом. Особенно, если вам нужно вызвать их в привилегированном контексте. В моем случае я также ограничиваю пользователей конкретным корневым каталогом и конкретной подсистемой SSH, поскольку они только подключаются к машине через sshd и аутентификацию с открытым ключом. Очевидно, вам это не нужно.

Удостоверьтесь, что chown root: <the-script>; chmod u=rw,a=,a+rx <the-script> не позволяет кому-либо, кроме root, поработать с ним. Также будьте осторожны с битами setuid и setgid, включенными в целевые двоичные файлы (find можно использовать для их обнаружения). Предположим, что ваш скрипт находится в /usr/sbin/priv-action.

Теперь отредактируйте свой /etc/sudoers. noexec может использоваться для предотвращения других двоичных файлов, кроме тех, которые явно разрешены. На самом деле существует множество дополнительных настроек, а не только те, которые я описываю здесь. Поэтому не забудьте проконсультироваться с man sudoers.

Теперь я предпочитаю называть пользователей (User_Alias) в моем файле sudoers, но вы также можете использовать Group_Alias (man sudoers ) или фактической системной группы (например, %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

, а затем добавить псевдоним команды, чтобы разрешить выполнение этого конкретного скрипта:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Последнее, но не менее важное приходит волшебная линия, позволяющая bob (или, скорее, пользователям, перечисленным в LIMITED_ADMINS) выполнять привилегированные команды через скрипт:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

В отличие от предыдущих описаний псевдонима, для строки требуется объяснение. Итак, давайте сначала разобраться в деталях по строке «Пользовательская спецификация». Здесь man sudoers помогает:

. Основная структура пользовательской спецификации - who where = (as_whom) what. [!d15 ]

root    ALL=(ALL) ALL

Пример строки (найден на большинстве установок Ubuntu):

Это говорит о том, что пользователь существует root (используйте #0, чтобы связать его с UID 0) может на всех хостах запускаться под любым контекстом пользователя, но будет запрашиваться его пароль (при условии поведения по умолчанию). Добавление тега NOPASSWD до последнего ALL затем также позволит root делать то же самое без запроса пароля (например: root ALL=(ALL) NOPASSWD:ALL). ALL является внутренним подстановочным псевдонимом для различных типов псевдонимов.

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

Но вернемся к Бобу:

позволит bob и другим перечисленным членам User_Alias LIMITED_ADMINS (на всех хостах это то, что ALL для) как пользователь root (группа подразумевала, но могла быть дана, см. man sudoers) команды, заданные в Cmnd_Alias PRIV_ACTION. Все становится лучше. По-прежнему предполагая, что вы пишете этот скрипт, вы можете разрешить различные параметры, тем самым избегая писать несколько сценариев. /etc/sudoers с радостью принимает shell-подобные подстановочные знаки, чтобы ограничить возможности разрешенных аргументов.

Я постоянно обнаружил, что администраторы не используют sudoers способ его использования, поэтому Я оценил соответствующий «Hack» из двух книг «Linux Server Hacks» и «Linux Server Hacks Volume Two», благодаря чему я начал с более сложного использования этого прекрасного средства.

Вы можете подойти со всеми видами свернутых - что не может точно помочь аспекту безопасности - решения для вашего конкретного случая, но как только вы говорите на основной лексике /etc/sudoers, вы можете совершать довольно магические подвиги:)

#includedir /etc/sudoers.d

В Unix / Linux есть только один суперпользователь, его имя - root, но sudoers - это пользователи, которые могут стать root. Вы должны использовать группы:

newgrp admins

, а затем назначить пользователей этой группе:

chgrp alice admins

затем добавить группу админов в конфигурационный файл sudoers, например, если группа была

Обновить

Или вы можете добавить любого пользователя в группу администратора:

chgrp alice admin