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

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

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

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

таким образом, я добавил их к /etc/sudoers

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

В сценарии такой как Ваш я буквально написал бы сценарий нескольких действий, которыми должен быть ограничен Bob. На самом деле это - то, что я сделал на сервере, который я поддерживаю, чтобы позволить двум конкретным пользователям перезагружать конкретного гостя KVM на хосте. Сценарии содержали бы hashbang с полным путем к интерпретатору (например. #!/bin/dash вместо #!/usr/bin/env bash) и вероятно выполненный с оболочкой, которая используется в другом месте для привилегированных задач (/bin/dash или /bin/sh). Это - просто меры предосторожности. Кроме этого, я удостоверился бы к hardcode все полные пути к двоичным файлам и использованию как можно меньше из них. Например, при использовании bash/dash Я предпочел бы builtins commands (см. 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 файл, но Вы могли точно также использовать a 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.

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

root    ALL=(ALL) ALL

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

Но назад Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

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

Я последовательно находил, что администраторы не используют sudoers путем это должно использоваться, который является, почему я ценил соответствующий "Взлом" из двух книг "Взломы Сервера Linux" и "Объем Взломов Сервера Linux Два", который запустил меня с более сложного использования этого большого средства.

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

NB: имеет в виду, что можно также создать новый файл внизу /etc/sudoers.d/ если Вы чувствуете себя настолько склонными. Это принимает Ваш /etc/sudoers содержит строку:

#includedir /etc/sudoers.d