Вопрос: Скрипты, которые нуждаются (некоторые) Root Access


У меня есть общий вопрос о сценариях системного администрирования, для выполнения которых требуются «некоторые» команды с правами доступа root, а другие - как обычный пользователь без полномочий root (т. Е. Myusername и т. Д.). Должен упомянуть, что я использую Ruby 1.8.6 для Linux Red Hat 4. Предложения, которые я видел до сих пор:

  1. Разрешить доступ к sudoers:
      USERNAME = NOPASSWD: / path / to / script, /etc/init.d/httpd, / path / to / somethingelse
      Правильно ли этот синтаксис? Если да, исправляю ли я, что я хотел бы указать все конкретные команды, необходимые в скрипте, где мне не нужно было запрашивать пароль?

  2. Установить suid
    http://www.wellho.net/mouth/733_Perl-for-Systems-Admin-suid-scripts.html 
      Чтобы запустить скрипт Perl с привилегией root:
      a) Установите владельца скрипта на root
      b) Установите бит suid в файл (chmod u + s имя_файла)
      c) Отключить разрешение на чтение и выполнить разрешение для файла всем, кроме root (chmod go = x)
      Но другие исследования показывают, что вы можете установить suid на двоичные файлы для более поздних Linux-систем (мой скрипт будет работать на более ранней версии RH4, но мы можем завершить обновление, поэтому я хотел бы быть совместимым с переходом). Я не думаю, что хочу создать двоичный код именно для этого!

  3. 'Использовать ssh с генерируемыми открытыми / закрытыми ключами. Ключ может быть сконфигурирован так, чтобы с ним можно было выполнять только определенные команды. '

  4. Оставьте в sudo для любых скриптовых команд, для которых требуется root:
      system 'sudo rake ts: rebuild' (конечно, у этого есть недостаток наличия всех этих подсказок пароля!)

  5. Выполнять скрипт как root
      Но как насчет команд, которые я хочу запускать, как обычный пользователь?

  6. Выполните команду root su username (для задач, которые должны выполняться как обычные пользователи)
    «Запускайте скрипт как root, выполняйте кучу заданий как root, su newUser выполняет множество задач, как newUser, exit (завершает работу с корневым пользователем) выполняет множество задач с правами root». (предложенный Джеймсом ниже) 

Мне стыдно не иметь лучшего понимания этой темы, но я немного удивлен, сколько Ruby «скриптовых книг», на которые я ссылался, не обращаюсь к этому! Я предполагаю, что это нечто большее, но кажется, что для того, чтобы сделать что-то существенное, вы, вероятно, столкнетесь с этим.

Изменить: некоторые вещи, такие как mysql Я могу использовать параметры в команде, например, -password, поэтому я использовал это для этого:

puts "Remote Password: "
system('stty -echo')
password = STDIN.gets.chomp
puts "Mysql Password (local): "
mysql_local_password = STDIN.gets.chomp
system('stty echo')

И тогда я могу использовать эти пароли из сценария, но они никогда не воспринимаются как чистый текст. Но все это, конечно, не работает.

Другая вещь, которую я должен упомянуть, - это команды, которые должны запускаться как разные пользователи (в дополнение к простому пользователю root и одному нормальному пользователю может быть пользователь «build» и т. Д. И т. Д.),

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

Спасибо всем!


5
2017-12-24 15:40


Источник




Ответы:


Вы когда-нибудь занимались такими вещами, как Capistrano, кукольный, анзибль или шеф-повар для ваших задач?

Вы не говорите, какова ваша работа, поэтому я понятия не имею, насколько они вам полезны.

Я бы избегал «suid» любой ценой. Нет смысла использовать его с установкой sudo, что, по-видимому, является лучшим выбором для ваших требований запуска команд с разными разрешениями / идентификаторами пользователей ('sudo -u user2 command2' и т. Д.).

Также вам может потребоваться выполнить некоторые команды sudo без пароля в качестве разрешенных команд в вашем сеансе ssh на основе ключа (ssh sshkeyaccessonlyuser @ yourhost 'sudo command'). Это может повлечь за собой проблему кэширования, если вы не хотите иметь более длинные пароли в sudo, и ваш скрипт не завершит выполнение команды sudo вовремя.


2
2017-12-31 21:34





Да, вы можете su для любого пользователя в скрипте как root, не требуя пароля. Это немного взломать, но это сработает. У вас могут быть некоторые икоты по пути (например, ваша среда изменяется, когда вы, например), но вы сможете заставить ее работать. Я не думаю, что это «правильно». Кроме того, root может делать все, поэтому вы всегда можете найти способ сделать все как root.

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

Для интерактивных материалов, sudo с подсказками пароля в порядке. Я предпочитаю, чтобы он запрашивал у вас собственный пароль, а не root. Таким образом, вы можете предоставить ограниченные административные права, не отдавая пароль root (и, следовательно, полные привилегии). Чтобы ввести пароль, это хорошо для «эй! Я набираю свой пароль, это означает, что я делаю что-то потенциально опасное, давайте проверим, прежде чем набирать». Вы также можете установить sudo, чтобы не запрашивать несколько раз для паролей (т. Е. Как только вы вводите его, sudo invocations в течение n минут не запрашивает).

Кроме того, вы можете сделать sudo, чтобы пользователь мог выполнять Любые действие как root, а не только ограниченный набор команд. Я использую это для ящиков i admin; это лучше, чем «su -», дает вам некоторые материалы аудита из коробки, вы всегда можете «sudo -i» (или «-s», иногда), чтобы получить корневую оболочку и т. д.

Для неинтерактивного материала у вас больше выбора.

Я не очень люблю бинарные игры. Это должно использоваться только для очень часто используемых двоичных файлов, которые нуждаются в привилегиях root, которые очень простые и которые были тщательно проверены. Например, ping требует привилегий root для выполнения своей работы. Однако любой недостаток безопасности в двоичном двоичном коде потенциально очень опасен.

Использование ssh - очень сложный способ достижения этого.

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


5
2017-12-24 16:34



Это очень полезно благодаря Алексу. - Rob


Я бы пошел с № 4:

Оставьте в sudo для любого сценария   команды, требующие root: system   'sudo rake ts: rebuild'

Вам не нужно слишком беспокоиться о повторных запросах пароля; sudo будет кэшировать тот факт, что вы прошли проверку подлинности с помощью пароля на короткое время (по умолчанию около 5 минут. На странице man:

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

из man sudoers:

timestamp_timeout

Количество минут, которые могут пройти до того, как sudo спросит   для пароля снова. Значение по умолчанию - 5. Установите для этого значения значение 0:   всегда запрашивайте пароль. Если установлено значение меньше, чем   0 временная метка пользователя никогда не истечет. Это можно использовать   чтобы пользователи могли создавать или удалять свои собственные временные метки   через sudo -v и sudo -k соответственно.

Таким образом, пока сценарий займет менее 5 минут, пользователь должен увидеть только одно приглашение пароля - вообще ничего, если они прошли проверку подлинности в последнее время.


2
2017-12-28 11:07





Я бы тоже пошел sudo, с решением 1 и 5. Обратите внимание, что вы также можете использовать псевдонимы, чтобы сделать вашу настройку более чистой, например:

Cmnd_Alias RUBY_TOOLS = /path/to/cmnd1, /path/to/cmnd2, etc.
Cmnd_Alias RUBY_TOOLS_NPW = /path/to/cmnd3
User_Alias RUBY_USERS = user1, user2, etc.
User_Alias RUBY_SPECIAL_USERS = root
RUBY_USERS ALL=(RUBY_SPECIAL_USERS) RUBY_TOOLS, NOPASSWD: RUBY_TOOLS_NPW

Правило ограничит доступ к команде (-ям) RUBY_TOOLS в качестве пользователя (-ов) RUBY_SPECIAL_USERS и не использует пароль для RUBY_TOOLS_NPW.

Судо очень гибкий. Вы также можете играть с Host_Alias, чтобы указать хосты, на которых применяются правила. Если вам необходимо автоматизировать формирование ваших правил sudo, вы можете использовать Авгий для этого.

Единственным недостатком этого метода, который я вижу, является:

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

Один из способов решения второй проблемы - настроить переменную SUCMD в вашей конфигурации и использовать ее перед всеми вызовами exec. По умолчанию SUCMD будет sudo, но вы можете установить его на «su» позже, если вы хотите использовать другую систему или просто ничего, если вы не хотите использовать SUCMD и настроить свою систему с помощью настроек setuid или group.


1
2017-12-26 21:46





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

Дайте все варианты выше, я не видел возможности запуска скрипта как root и просто запускаю «su username» перед запуском команд в качестве пользователя. Он имеет преимущество, не требуя приглашений пароля (не требуется пароль с правами root), и он должен отвечать всем вашим потребностям.

Запустите скрипт как root, выполняйте кучу задач как root, su newUser выполняйте кучу задач как newUser, exit (выход обратно к пользователю root) выполняйте больше задач с правами root.


0
2017-12-24 15:52



Ruby - общий язык для задач системного администрирования. - womble♦
Собственно, когда я это делаю: su user; система «команда»; Выход; он фактически выходит из сценария, а не возвращается к пользователю root. У меня нет корня, поэтому я должен сделать sudo bash перед запуском, возможно, это проблема для меня, используя этот подход. - Rob
Попробуйте su root; система «команда»; su пользователь;
Вы не знакомы с Ruby потому как это нетрадиционно, или вы думаете, что это нетрадиционно, потому что вы не знакомы с ним? :) - Cawflands


Здесь есть другой метод, который я использовал время от времени. Если вы действительно не хотите пароль и не хотите зависеть от sudo, вы можете использовать сценарий super, который затем вызывает ваш скрипт. «sudo» имеет свои преимущества, но иногда его труднее использовать, чем простая оболочка, скажем, из задания cron или как ЧАСТЬ другого сценария.

Я должен был сделать это в моей обработке веб-журнала. Сценарий, выполняющийся как обычный пользователь, будет отключать файлы журнала, а затем он называется suid-скриптом для отправки HUP в apache, чтобы он снова открывал новые файлы журналов. Только HUP нужно было запустить как root, поэтому только эта часть была suid.


0
2017-12-30 15:22



В моем списке у меня был двоичный код. Это кажется очень небезопасным. - Rob