Автоматический ввод пароля sudo из скрипта.

идиотское использование инструмента ничего не говорит о самом инструменте :) ножичком так-то можно и человека пырнуть и колбаску порезать.
не натягивайте свое видение на мир.

в «рассовоправильном» su для его использования использующему необходимо знать пароль root :) по мне так самая главная дыра su в случае когда все необходимо допускать непривилегированного пользователя до некоторых привилегированных функций.

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

как говорится почувствуй разницу.

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

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

Теоретически, например. Мы даём пользователю sudo доступ к mount, и пользователь делает bind mount /etc, заменяя /etc/passwd и /etc/shadow на свои.

Да, можно наверное разрешить только mount со строго определенными аргументами, но кто поручится, что в большом sudoers нет каких-либо похожих возможностей?..

теоритически совершил глупость ты, а не sudoers :).
не подумавши, дал пользователю неограниченный доступ.
это в принципе и есть стандартная ошибка «запустить от администратора», которую указали чуть выше.

практически надо создать скрипт с четкими параметрами, что куда монтировать, к примеру «mount /dev/sdb2 /тра/ля/ля …»
запретить пользователю его менять и дать доступ на исполнение данного скрипта через sudo.
и профит… пользователь имеет четко ограниченный доступ к привилегированному функционалу.
на ум приходят еще несколько вариантов, чуть более замороченных.

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

Нет, всё не так. sudo как раз заточен на неправильное использование, и практически непригоден для правильного. Его правильное использование, как я уже писал, полностью перекрывается su, и то оно дефективное из-за того что спрашивает не тот пароль.

по мне так самая главная дыра su в случае когда все необходимо допускать непривилегированного пользователя до некоторых привилегированных функций

su это переключение юзера на рута, соответственно выдаются все права рута. Это не дыра, это то что оно должно делать. sudo делает то же самое, но таким мутным способом, что новички начинают думать будто оно делает что-то другое, и это очень плохо.

в «рассовоневерном» sudo имеется куча разграничивающих средств в sudoers,

Эти «средства» сделаны ужасно костыльным способом. Нельзя так делать.

ты наверн в мане до такого даж не дочитывал

Ты глупый?

пользователю запускать четко ограниченные root-овые функции

Вот функции и надо ограничивать. sudo это не умеет. Зато, сюрприз, это умеет делать ядро с начала времён с помощью setuid-бита прав на программе, реализующей разрешённую функцию (не идиотский текстовый фильтр на команду! именно программа которая делает то что нужно). Или, для некоторых, чуть более современные capabilities.

практически надо создать скрипт с четкими параметрами, что куда монтировать, к примеру «mount /dev/sdb2 /тра/ля/ля …»
запретить пользователю его менять и дать доступ на исполнение данного скрипта через sudo.

Ну вот, уже лучше. Осталось только заменить скрипт на программу и выкинуть sudo, поставив программе setuid root.

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

Правила, основанные на строковых операциях, априорно дефективны.

Его правильное использование, как я уже писал, полностью перекрывается su

Ну и как такое через su делать?

zabbix ALL= (ALL) NOPASSWD: /opt/zabbix/zabbix_mdraid.sh

Или предлагаешь suid-обертки делать?

Предлагаю. Не обязательно обёртки кстати.

Я так понимаю речь про это: https://github.com/linuxsquad/zabbix_mdraid/blob/master/zabbix_mdraid.sh

Этой портянке однозначно пойдёт на пользу переписывание на нормальный компилируемый язык. Кстати, автор, такой нехороший человек, ещё и #!/bin/bash туда всунул. Однозначно переписать.

Я так понимаю речь про это

Как пример.

Этой портянке однозначно пойдёт на пользу переписывание на нормальный компилируемый язык.

И это утверждение можно экстраполировать на все shell-скрипты? А интерпретируемые языки «ненужны»?

ещё и #!/bin/bash туда всунул

У меня есть только догадки о причинах возмущения:

• использование bash, вместо sh
• нелюбовь к shebang
• страсть к /usr/bin/env

Хотите сказать что sh лучше, чем bash?

И это утверждение можно экстраполировать на все shell-скрипты? А интерпретируемые языки «ненужны»?

Нет, не на все. Где-то и обёртка сойдёт. Но вобщем-то sudo как раз такой обёрткой и получается, так что бояться их не надо, а вот вместо текстово-ориентированного списочного конфига дать права на конкретный файл - вполне хорошо.

У меня есть только догадки о причинах возмущения:

1) использование баша 2) и это несмотря на то, что в скрипте кажется башизмов нет 3) расширение всё равно оставим .sh чтоб всех запутать 4) ну и да, без env оно не кроссплатформенно, а ведь можно было просто написать /bin/sh, впрочем даже с env кому-то придётся ставить лишний баш (нет конечно, просто шебанг пропатчат)

Чуваки, ну cкрипт то мне уже нафиг не нужен, но как тогда сделать что-то вроде pkexec на пайтоне?

Как быть с группами, пользователями и аргументами?

Группе adm я хочу дать возможность пускать одни программы, группе support - другие. А группе web я хочу дать возможность выполнять часть команд, но от пользователя www-data, а не от рута. А если я хочу дать права на выполнение команды только с определёнными аргументами? И всё это вместе и в перемешку. Setuid тут не справляется.

Но вобщем-то sudo как раз такой обёрткой и получается

Совершенно верно. Ты предлагаешь написать ещё миллион обёрток под каждый отдельный случай вместо использования универсального sudo.

Что вы мне мозги своим sudoers пудрите? Я может быть ещё пишу на пайтоне pkexec. Лучше скажите как передать в пайтоне это

Как быть с группами, пользователями и аргументами?

В чём проблема? Ну и повторю: то, как проверяет аргументы sudo (с помощью сравнения строк) - никуда не годится. Проверять надо осмысленные сущности, а не строковое их представление.

Группе adm я хочу дать возможность пускать одни программы, группе support - другие.

Ты не поверишь:

$ ls -al /usr/sbin | grep rws
-rwsr-xr--  1 root dip    408644 янв  7  2021 pppd

А группе web я хочу дать возможность выполнять часть команд, но от пользователя www-data, а не от рута.

Аналогично.

А если я хочу дать права на выполнение команды только с определёнными аргументами?

Аргументы должна проверять алгоритмическая обёртка. И не с помощью сравнения строк или регулярок на командную строку, а с помощью парсинга argv[] аналогично той программе, которую запускаешь и дальнейшего моделирования того, что произойдёт. А ещё она может сама их составить из более простого собственного синтаксиса (ведь если ты хочешь ограниченную функциональность то незачем синтаксис от полной тащить).

Совершенно верно. Ты предлагаешь написать ещё миллион обёрток под каждый отдельный случай вместо использования универсального sudo.

Универсально-костыльного. Такая универсальность не нужна.

Я pkexec у себя удалил ещё раньше чем sudo, так что с этим помочь не могу, кроме как отговорить с ним связываться.

Передать что? Пароль? Я в первом комментарии сказал - используй expect(или соответсвующий модуль для питона).

Дак я хочу попробовать написать pkexec просто для практики.

expect можно запустить одной комманой? Типо expect command(Например echo test)

Ты не поверишь, но все аргументы командной строки передаются всем программам как строка, которую потому эта программа парсит. Ты предлагаешь в каждой обёртке дублировать этот функционал. Для управления правами нам достаточно белого листа на список аргументов. Для того, чтобы разрешить ls -l dirname мне не нужно анализировать, что делает ключ -l, достаточно только добавить этот ключ в наш белый список и выставить ограничение на количество аргументов. С твоим подходом обёртка будет реализовывать часть внутренней логики программы. Ты предлагаешь написать ещё более переусложнённый SELinux.

Далее, группы. Группа adm должна запускать команду от пользователя admuser, группа web от пользователя www-data. Какие права надо выставить на эту команду с твоим подходом?

Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. (с)

Пока что ты предлагаешь только более запутанные костыли.

expect реализует мини-скрипт. Ты пишешь, что ожидаешь увидеть на вводе и передаёшь ему ответ.

# Код по памяти, не проверенный.
user=username
password=userpass
expect {sudo password for $user: }
send $password

ок

ls -l dirname мне не нужно анализировать, что делает ключ -l,

А если юзер захочет ls -l --sort=size ? А если ls --sort=size -l ? А если ещё какой незначимый флаг всунет? А если там есть опасные, которые надо запретить? А если ему можно делать ls только на поддиректории пути /ls_sandbox/ и при этом там внутри могут быть симлинки наружу? Разумеется, тупым текстовым сравнением все эти случаи не покрыть, и будет очередное убожество по типу «вот тут это нельзя потому что наш кривой инструмент так не умеет».

С твоим подходом обёртка будет реализовывать часть внутренней логики программы.

Именно так. Иначе будет убожество (см. выше). И, повторю, во многих случаях вполне желательно будет вообще иметь свой синтаксис на конкретные нужды, который обёртка будет конвертировать в синтаксис своего бекэнда.

Ты предлагаешь написать ещё более переусложнённый SELinux.

Он тут ни причём и ни разу не похож.

Группа adm должна запускать команду от пользователя admuser, группа web от пользователя www-data

chown admuser:adm adm_program && chmod 4750 adm_program chown www-data:web web_program && chmod 4750 web_program

Если хочешь чтобы одна и та же команда так работала (что весьма странное требование, ну да ладно), тогда делаешь suid-root, внутри getuid() и по результатам setgroups(), setgid(), setuid().

Unix - это не свалка костылей и подпорок. Это стройная, логичная система костылей и подпорок. (с)

У тебя - может быть, а мне нравится когда не костыли а нормальный софт.

А это писать куда? В интрепритатор expect или в bash?

# Код по памяти, не проверенный.
set user ""
set password ""
expect {\[sudo\] пароль для $user: }
send $password

Вот правильный вариант кода, но он почему-то не работает(Я юзера указал и пароль)

Ааа, понял

Или не понял, почему не работает.

set user "я юзер"
set password "мой парольчик"
spawn sudo echo test
expect {\[sudo\] пароль для  $user: }
send $password  

без env оно не кроссплатформенно

Недавно в каком-то треде обсуждали что и env не везде есть.

Но вобщем-то sudo как раз такой обёрткой и получается

Да. И вполне удобной оберткой. Зачем мне делать обертку на компилируемом языке, если мне нужно просто дать возможность запускать пару стандартных утилит с фиксированными аргументами? Мне куда удобнее засунуть команду их в .sh и выдать через sudoers на него права.

полностью перекрывается su, и то оно дефективное из-за того что спрашивает не тот пароль.

Есть несколько админов администрирующих один сервер. Иногда кто-то добавляется, иногда кто-то удаляется. Они все должны знать рутовый пароль? После каждого удаления администратора рутовый пароль надо сбрасывать?

enot_obrmot

Хотите сказать что sh лучше, чем bash?

Просто есть системы где bash отсутствует.

если мне нужно просто дать возможность запускать пару стандартных утилит с фиксированными аргументами?

Если аргументы фиксированные то незачем их каждый раз набирать, они должны быть зашиты в обёртке.

Есть несколько админов администрирующих один сервер. Иногда кто-то добавляется, иногда кто-то удаляется. Они все должны знать рутовый пароль? После каждого удаления администратора рутовый пароль надо сбрасывать?

Спрашивать собственный пароль это то же самое что не спрашивать никакого.

Как раз один рутовый пароль на всех - это проходной двор. Судя по этому и предыдущему комментам, ты исключительно про локалхост говоришь. Городить громоздкие обёртки для каждого приложения, в обход пакетного менеджера бинарники копипастить с разными именами, кастомные права выставлять, одним паролем на всех пользоваться и т.д. Это не работоспособно в реальных условиях и требует слишком много ручной работы. Если ты сможешь подобную систему написать и предоставить прототип хотя бы с настройками для base-system утилит, можно посмотреть. А пока что это всё очень похоже на обрастающую всё большими и большими костылями здоровую помойку.

Нет, всё не так. sudo как раз заточен на неправильное использование, и практически непригоден для правильного. Его правильное использование, как я уже писал, полностью перекрывается su, и то оно дефективное из-за того что спрашивает не тот пароль.

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

любое незнакомый инструмент работает непонятно :) новичок незнакомый как с работой su так и sudo накосячит и там и там :)

Зато, сюрприз, это умеет делать ядро с начала времён с помощью setuid-бита прав на программе, реализующей разрешённую функцию (не идиотский текстовый фильтр на команду! именно программа которая делает то что нужно)

чет я не вижу от тебя кучи узкозаточенных прог. взял бы и написал (и главное отладил) прогу, выполняющую хотелку топикстратера.
командная строка аккурат и сделана для упрощения интерфейса человек-машина. ни один человек не смогет напрямую кидать бинарные команды ядру или приложению :) тут промах.
к примеру постановка setuid setgid битов на mount не даст никакой защиты.

Ну вот, уже лучше. Осталось только заменить скрипт на программу и выкинуть sudo, поставив программе setuid root.

коль с твоей стороны это правильно, давай быстренько сгенерь прогу пот заданию в первом сообщении:) а мы посмотрим.

Правила, основанные на строковых операциях, априорно дефективны.

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

У тебя - может быть, а мне нравится когда не костыли а нормальный софт.

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

про локалхост говоришь. Городить громоздкие обёртки для каждого приложения, в обход пакетного менеджера бинарники копипастить с разными именами, кастомные права выставлять, одним паролем на всех пользоваться и т.д.

Ты о чём вообще? Хватит теоретизировать.

Если ты сможешь подобную систему написать и предоставить прототип хотя бы с настройками для base-system утилит

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

Какие теории? Ты сам выше по треду на мои вопросы предлагаешь проводить манипуляции с бинарниками и писать обвязку над каждой утилитой с использование внутренней логики самих утилит.

Ты собрался избирательно выдавать права на echo и grep что ли? не неси чушь. Речь шла про те случаи, где надо непривилегированному юзеру дать способ запустить что-то привилегированное. Таких случаев МАЛО и никаких «каждых утилит» там явно нет. А вот вменяемая (никакого бреда типа регулярок на командную строку) обработка аргументов необходима.

ты еще не написал компилируемую прогу по условиям топик стартера.

а дальше… обучение системных администраторов, сетевых инженеров и прочих обслуживающий серверы персонал программированию на компилируемом языке, чтоб они все скрипты делали лишь в виде конечных бинарей, на которые можно поставить setuid-бит.
результат можешь услышать, зайдя в любую серверную и доведя свою «абсолютно правильную» идею до целевой группы :)
ответ можешь приложишь сюда - я думаю он будет интересен в плане филигранности использования обсценной фразеологии…

ты еще не написал компилируемую прогу по условиям топик стартера.

Я и не собирался. Топикстартер хочет какую-то муть и не может нормально объяснить зачем.

а дальше…

Прекращай бредить. У тебя представления о работе ИТ-систем из какого-то подвала 90-х.

дык этож твой бред :) про компилируемые скрипты на каждый чих с установленным setuid. или что-то в твоих теориях неправильно понял…
расскажи правильную сторону жизни.