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

Я настраиваю машину Ubuntu (10.10), которая будет использоваться несколькими людьми. Это общая машина в небольшом офисе. Его основными функциями являются размещение виртуальных машин с VirtualBox и обслуживание файлов с помощью Samba.

Для Samba необходимо настроить несколько учетных записей пользователей, чтобы разные люди могли подключаться к общим ресурсам Samba со своих рабочих станций. Однако есть также учетная запись, предназначенная только для запуска виртуальных машин, которую будут использовать несколько человек. Иногда люди пытаются сделать с этой учетной записью действия, требующие повышенных привилегий - это вызывает всплывающее диалоговое окно Gnome «введите пароль администратора». Однако, это диалоговое окно запрашивает мой пароль - когда я настраивал машину, моя была создана первая учетная запись, так что, похоже, предполагается, что я единственный пользователь, которому предоставлены полномочия sudo.

Я хочу назначить другого пользователя, так сказать, «администратором первой инстанции», и он не может быть пользователем общей учетной записи, потому что все должны знать пароль этой учетной записи, поэтому я хочу, чтобы его привилегии были строго ограничены. Это не может быть мой аккаунт, так как я не сообщаю другим людям свой пароль, и я не буду присутствовать на сайте достаточно часто, чтобы ввести его сам. Однако есть кто-то, кто может сделать это лично, поэтому я добавил их /etc/sudoers. Как я могу сказать Ubuntu, что, когда ему нужно повысить привилегии, он должен сначала запросить их учетную запись?

Подвести итоги:

• Счета на автомате: Алиса, Боб, Кэрол, Дейв, Элиза.
• Когда Ubuntu была установлена, Алиса была первым пользователем, добавленным во время процесса установки.
• «Dave» - это учетная запись, которую используют многие люди, которые не могут войти, /etc/sudoersпотому что ее пароль общедоступен.
• Боб был назначен «Административной» учетной записью в Gnome, и в него был внесен соответствующий вклад /etc/sudoers- Боб является начальником в этом офисе.
• Если при входе в систему от имени Боба, Кэрол, Элизы или Дейва предпринимаются действия, требующие повышенных привилегий, система должна запросить учетные данные Боба.
• Когда действия, для которых требуются повышенные привилегии, предпринимаются при входе в систему в качестве Алисы, система должна запросить учетные данные Алисы (хотя Алиса является своего рода системным администратором buckaroo и имеет привычку использовать его su -для выполнения расширенных задач администратора).

Какие изменения в конфигурации мне нужно сделать, чтобы добиться желаемого состояния здесь?

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

1. sudo

2. PolicyKit

Первый используется, когда вы явно запускаете команду с помощью sudoили пункта меню, команда которого обернута gksu(например, Synaptic Package Manager ).
В этом случае требуется пароль вызывающего пользователя, обычно это пользователь, вошедший в систему.

Второй используется, когда приложение с поддержкой PolicyKit пытается выполнить привилегированное действие. В таком случае приложение запрашивает локальный орган PolicyKit (через D-Bus), можно ли выполнить действие. Затем локальный орган через агента аутентификации просит активного пользователя подтвердить свою личность. Диалоговые окна похожи на следующие (к сожалению, с текстом на итальянском языке :)

Вы можете идентифицировать PolicyKit по маленькому черному треугольнику и метке Details . Как видите, если в adminгруппе более одного пользователя , вы можете выбрать из списка, какого пользователя использовать для аутентификации.

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

Возвращаясь к вашему вопросу, когда механизмом, используемым приложением, является PolicyKit, независимо от текущего вошедшего в систему пользователя, требуется пароль Боба или Алисы (только два администратора, если я правильно понимаю), и вы можете изменить из списка, какого пользователя вы хотите использовать для аутентификации.

Когда используется механизм, используемый приложением sudo(для задач администратора, выполняемых через графический интерфейс, это становится все менее частым), у вас нет немедленного и простого способа выбрать пользователя для аутентификации.

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

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

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

поэтому я добавил их в /etc/sudoers

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

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

Теперь я предпочитаю называть users ( 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.

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

root    ALL=(ALL) ALL

Это говорит о том, что пользователь с именем 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с радостью принимает подстановочные знаки, подобные оболочке, чтобы ограничить возможности аргументов, разрешенных для передачи.

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

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

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

#includedir /etc/sudoers.d

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

newgrp admins

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

chgrp alice admins

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

Обновить

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

chgrp alice admin