LINUX.ORG.RU

Запуск bash-скрипта на сервере с правами root через браузер

 , , , ,


0

1

Доброго времени суток!

Необходимо сделать так, чтобы со странички мог запускать скрипты bash от root. Безопастность будет на уровне самой странички так что, если человек оказался на страничке, то скрипт запускать. Пробовал это все сделать на PHP, но не вышло. От простого смертного пользователя еще хоть что-то получалось, а от root - нет.

Подскажите пожалуйста куда копать. ОС, на которой все это будет работать - CentOS 6.4.

Заранее спасибо!

Расскажи лучше, что ты именно хочешь сделать, ибо это явно очень неправильный путь.

derlafff ★★★★★ ()

со странички мог запускать скрипты bash

Небось ещё и данные какие вводить на страничке и в скрипт отправлять? Фееричная дыра получается. Так держать.

Надеюсь запускать webсервер от рута ты ещё не додумался?

100:1 что этот твой скрипт лучше запускать по крону. Ну а со странички лучше создавать сигнальный файл (типа есть - значит выполняться)

ziemin ★★ ()

Отлично, как раз не хватало вычислительных мощностей.

anonymous ()

Запуск bash-скрипта на сервере с правами root через браузер (комментарий) - тут все правильно за исключением того, что sudo тебе ненужно. Сделай скрипт-интерфейс в который будет принимать как параметр то, что надо выполнить.

Ну и IP запости в тред, а то все вкусное только модерам достанется.

Suntechnic ★★★★★ ()
Ответ на: комментарий от Suntechnic

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

leave ★★★★★ ()

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

beastie ★★★★★ ()
Ответ на: комментарий от leave

Почему ты так думаешь? Я тоже когда-то подобное делал. С чего это все вдруг тут взяли, что ТС собрался стрелять В СВОЮ ногу? Ну не напишет же он - хочу веб-консоль запилить на чужом компе/хосте/сайте.

Suntechnic ★★★★★ ()
Ответ на: комментарий от beastie

Оперативно ответить не смог, но рад, что топик не остался без ответов. То что это дыра - я согласен полностью. Может кто поможет что-то получше придумать. Есть 2 задачи, которые я придумал как решить только путем запуска bash со странички, на которую предварительно надо войти по паролю:

1. Есть сервер разработчиков ПО на JAVA и в определенные моменты необходимо сделать чекин из svn и при помощи maven сделать сборку проекта и подложить этот проект в определенное место для тестирования. Сейчас с этой задачей справляется написанный скрипт на bash, который я запускаю при необходимости. Пробовал позволить разработчикам заходить по ssh (в их случае через putty т.к. у них винда) и запускать скрипт, но ничего хорошего из этого не вышло. Те кто пишут код не всегда хорошие администраторы и вообще пользователи ПК, поэтому были нюансы, в итоге сейчас запускаю этот скрипт по требованию.

2. Есть работающая инстанция с системой, написанной на JAVA, систему используют предприятия. У каждого своя инстанция. Так вот надо сделать так, чтобы админы предприятий, имеющие каждый свой личный кабинет могли нажать кнопочку на страничке и им создался бекап системы и они могли его забрать себе. Опять же за этой кнопочкой хочу разместить bash-скрипты, которыми выполняю эту задачу сейчас. В этом случае уж точно вариант с ssh не подходит. Вот как-то так.

Заранее спасибо за помощь!

MakPol ()
Ответ на: комментарий от MakPol

Это всё гораздо безопаснее организовать с помощью маркерных файлов, существование и/или содержимое которых проверяется скриптом по крону.

om-nom-nimouse ★★ ()
Ответ на: комментарий от om-nom-nimouse

Если можно, то подскажите пожалуйста, где можно про это почитать. Я с таким дело не имел, а задачи реализовать надо.

MakPol ()
Ответ на: комментарий от MakPol

Просто создавай из PHP файл, с названием /path/to/file, в крон вставь скрипт, который будет проверять на наличие этого файла. Если файл есть, то выполнять всё что душе угодно и удалять файл. Если файла нет, то и делать ничего не надо. Крон поставь раз в минуту. Если этого недостаточно, то используй supervisord и демона на sh.

VirRaa ★★★ ()
Ответ на: комментарий от MakPol

Ещё есть всякие rabbitmq, которые не совсем для этого предназначены, но твою задачу решить тоже смогут.

VirRaa ★★★ ()
Ответ на: комментарий от MakPol

у тебя ведь под юзером получилось? Вот и делай так (пока нормально не умеешь).

А то, что надо сделать от рута, оформляй в самом скрипте, через sudo, и пропиши в /etc/sudores команды, которые можно выполнять скриптам. Можешь и скрипты вызывать апачем с sudo.

drBatty ★★ ()
Ответ на: комментарий от VirRaa

Просто создавай из PHP файл, с названием /path/to/file, в крон вставь скрипт, который будет проверять на наличие этого файла.

чем это решение лучше system(sudo ..)?

drBatty ★★ ()
Ответ на: комментарий от drBatty

чем это решение лучше system(sudo ..)?

Тем, что файл создается в пределах DOC_ROOT. И никаких sudo - не нужно, и тем более system'ов, exec'ов и прочего.

VirRaa ★★★ ()
Ответ на: комментарий от VirRaa

Тем, что файл создается в пределах DOC_ROOT. И никаких sudo - не нужно, и тем более system'ов, exec'ов и прочего.

то, что в DocRoot создаются какие-то файлы - это минус, а не плюс. Ну а root доступ всё равно нужен для доступа к его crontab. Файл - это лишняя сущность, которая, вобще говоря для этого и не предназначена. Cron не будет писать лог, не будет оповещать админа о попытках взлома, и даже не будет проверять, кто, что и откуда пытается запустить. А вот sudo - будет. Ибо специально для этого заточена. Кроме того, в данном случае права рута и не нужны, если у юзера апача есть там свой доступ к какому-то системному аккаунту, его и можно прописать в sudoers. Тогда одни юзеры не смогут запускать команды других юзеров. А в твоей схеме - могут, ибо по файлу в DocRoot не понятно, какой юзер его создал. Любой может, даже аноним.

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

MakPol ()
Ответ на: комментарий от MakPol

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

MakPol ()
Ответ на: комментарий от MakPol

я бы хотел не просто запустить задачу добавив ее в планировщик, а увидеть, что выполнение пошло.

я для этого sudo и предлагаю.

drBatty ★★ ()
Ответ на: комментарий от MakPol

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

их потому и много, что для каждого случая хорош свой.

drBatty ★★ ()
Ответ на: комментарий от drBatty

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

MakPol ()
Ответ на: комментарий от MakPol

Сделать, чтобы от другого пользователя скрипт работал и от него пускать

ага. там же надо что-то с svn делать? Ну значит юзер для этого локальный есть. Вот от него и надо. Тогда враг сможет только этого svn юзера сломать, даже если доступ получит.

drBatty ★★ ()
Ответ на: комментарий от drBatty

то, что в DocRoot создаются какие-то файлы - это минус, а не плюс

Под маркерные файлы можно выделить место где угодно. Хоть среди сессий.

Ну а root доступ всё равно нужен для доступа к его crontab.

При этом рут не нужен апачу, он может хоть под nobody работать. И доступа апач к кронтабу иметь не будет. Что логировать и что запускать, будет определяться в самом скрипте. Взламывать скрипт, находящийся непонятно где - это довольно непросто.

Тогда одни юзеры не смогут запускать команды других юзеров. А в твоей схеме - могут, ибо по файлу в DocRoot не понятно, какой юзер его создал. Любой может, даже аноним.

У юзеров не должно быть доступа к серверу. Только к вёб-интерфейсу. И никто никакие файлы самостоятельно создавать не будет.

om-nom-nimouse ★★ ()
Ответ на: комментарий от om-nom-nimouse

ТС говорил про баш-скрипты, ты сказал про суид.

leave ★★★★★ ()
Ответ на: комментарий от om-nom-nimouse

Под маркерные файлы можно выделить место где угодно. Хоть среди сессий.

«можно» в том смысле, что ты так делаешь? Молодец. Кстати, попробуй сессии хранить не в файлах.

При этом рут не нужен апачу, он может хоть под nobody работать. И доступа апач к кронтабу иметь не будет. Что логировать и что запускать, будет определяться в самом скрипте. Взламывать скрипт, находящийся непонятно где - это довольно непросто.

Логику быдлокодеров понять на самом деле довольно просто. И куда вы скрипты пихаете - тоже догадаться не сложно. И как юзера зовут известно.

У юзеров не должно быть доступа к серверу.

подумай, что значит «доступ к серверу».

Только к вёб-интерфейсу.

но ты предлагаешь дать юзеру возможность запускать какой-то скрипт откуда-то с правами рута. Будет лучше запускать вполне определённый скрипт командой sudo с аудитом и проверкой. И от имени специального юзера.

И никто никакие файлы самостоятельно создавать не будет.

их будет создавать апачь из быдлокода на php, которым управляет злоумышленник. Причём - в файлах сессий. Я прекрасно понял твою идею ☺ Уже видел несколько реализаций, которые очень хорошо работают. Даже слишком хорошо.

drBatty ★★ ()
Ответ на: комментарий от om-nom-nimouse

Дай пруф, где я говорил про suid на bash-скрпите для начала.

ты не говорил про google:suid+bit? К чему он вообще в этой теме?

Да, suid bit можно ставить на *.sh, но эффекта от него нет никакого. Или ты его на апач ставить собрался?

drBatty ★★ ()
Ответ на: комментарий от drBatty

«можно» в том смысле, что ты так делаешь? Молодец.

Ахунг! Телепаты вернулись из отпуска! Всем шапочки из фольги!!!

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

Логику быдлокодеров понять на самом деле довольно просто.

У тебя, смотрю, большой опыт в быдлокодинге.

подумай, что значит «доступ к серверу».

В данном случае - у юзеров не должно быть шелла.

но ты предлагаешь дать юзеру возможность запускать какой-то скрипт откуда-то с правами рута.

Обрати внимание, я предложил это сделать до постановки ТСом нормальной задачи. После постановки «концепция изменилась».

Будет лучше запускать вполне определённый скрипт командой sudo с аудитом и проверкой. И от имени специального юзера.

Да. И запускать его через крон, с проверкой всего, что ему дают на вход и логированием. Без прямого доступа к нему апача или вообще кого-либо. Всё общение - «только письмами».

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

Их будет создавать апач там, где это будет удобно.

Я прекрасно понял твою идею

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

om-nom-nimouse ★★ ()
Ответ на: комментарий от drBatty

ты не говорил про google:suid+bit? К чему он вообще в этой теме?

Совершенно ВНЕЗАПНО, SUID можно ставить не только на скрипты, для обхода ограничений. Отличный метод выстрелить себе в ногу, да.

om-nom-nimouse ★★ ()
Ответ на: комментарий от om-nom-nimouse

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

уровень у нас довольно высокий. Уровень опасности. И это не я такое начал, а ТС, с первого поста. Потому решения не должны быть тупыми и первыми попавшимися. Не?

У тебя, смотрю, большой опыт в быдлокодинге.

да, это так. На ошибках, знаешь-ли, учатся.

А у тебя большой опыт писать код без единой ошибке и сразу?

В данном случае - у юзеров не должно быть шелла.

в любом случае - должно подумать, что будет, если они такой шел прямо или косвенно получат. Особенно учитывая, что они его таки ПОЛУЧАЮТ, хоть и на одну команду, хоть и из crontab'а.

А твои слова - всё равно как «взломщика консьержка не пропустит!».

Обрати внимание, я предложил это сделать до постановки ТСом нормальной задачи. После постановки «концепция изменилась».

crontab в любом случае не самое лучшее решение.

Да. И запускать его через крон, с проверкой всего, что ему дают на вход и логированием. Без прямого доступа к нему апача или вообще кого-либо. Всё общение - «только письмами».

ага. Такими «письмами», которые может писать кто угодно, и когда угодно. Причём скрипт не только ЭЦП письма не проверяет, он его даже не читает - зачем? Всё равно написать его мог кто угодно.

Их будет создавать апач там, где это будет удобно.

срать надо в сортире, а не там «где удобно».

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

не. Я просто видел такие велосипеды. Не поверишь - их ещё и продают.

drBatty ★★ ()
Ответ на: комментарий от om-nom-nimouse

Совершенно ВНЕЗАПНО, SUID можно ставить не только на скрипты, для обхода ограничений.

дык я так и не понял, на что ты предлагаешь ставить этот бит? На crontab что-ли? У меня и так стоит.

Отличный метод выстрелить себе в ногу, да.

не. В ногу ты не выстрелишь - ты ружьё держишь не с той стороны.

drBatty ★★ ()

1-Напиши скрипт мониторящий файл(запусти его от рута). 2-Напиши морду для веба который тебе будет изменять этот файл.

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

или/и

use incron

Dron ★★★★★ ()
Ответ на: комментарий от drBatty

уровень у нас довольно высокий. Уровень опасности.

Внутренний сервер разработчиков? Ты серьёзно?

А у тебя большой опыт писать код без единой ошибке и сразу?

Быдлокод может быть и без ошибок, но при этом оставаться быдлокодом. Качество кода слабо связано с количеством ошибок.

в любом случае - должно подумать, что будет, если они такой шел прямо или косвенно получат. Особенно учитывая, что они его таки ПОЛУЧАЮТ, хоть и на одну команду, хоть и из crontab'а.

Можно хоть сколько подчёркивать своё мнение большими буквами, обычные пользователи из-за этого шелл тем не менее не получат. С помощью файла-триггера будет несколько сложно «взламывать» скрипт, к которому у апача нет доступа в принципе.

crontab в любом случае не самое лучшее решение.

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

ага. Такими «письмами», которые может писать кто угодно, и когда угодно.

За ради бога. ТС изначально ставит задачу, что если пользователь знает пароль к сайту, он имеет право запустить процесс. Я бы ещё поставил туда проверку на отсутствие конкурентных процессов, чтобы скрипт два раза не запускался по одному и тому же поводу, плюс проверку на работу скрипта в коде сайта, чтобы до выполнения предыдущего задания следующее нельзя было запустить в принципе. Но это всё уже мелкие детали.

срать надо в сортире, а не там «где удобно».

Ты не поверишь, но срут в сортире именно потому, что это удобно по совокупности всех факторов.

Не поверишь - их ещё и продают.

Оффтопик вон тоже продают, так что не удивительно.

om-nom-nimouse ★★ ()
Ответ на: комментарий от om-nom-nimouse

Внутренний сервер разработчиков? Ты серьёзно?

да. Всё когда-то начиналось с локалхоста. Да и вообще - плохая идея открывать рут-доступ через веб

Быдлокод может быть и без ошибок, но при этом оставаться быдлокодом. Качество кода слабо связано с количеством ошибок.

значит нет у тебя никакого опыта. Быдлокод - чуть менее чем полностью состоит из ошибок. Даже если он и работает. Даже стилистические ошибки - это ошибки. В потенциале это дыры и глюки. Например запуск скрипта от рута - это ошибка, ну и что, что она работает?

Можно хоть сколько подчёркивать своё мнение большими буквами, обычные пользователи из-за этого шелл тем не менее не получат. С помощью файла-триггера будет несколько сложно «взламывать» скрипт, к которому у апача нет доступа в принципе.

Слушай, если кто-то имеет доступ к железной палке, которой тебя бьют по голове, то у него есть доступ к твоему мозгу?

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

не «напрямую», а через sudo, которая для того и предназначена кстати. Это лучше, чем планировщик, который вообще для другого.

Ты не поверишь, но срут в сортире именно потому, что это удобно по совокупности всех факторов.

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

Оффтопик вон тоже продают, так что не удивительно.

ну вот и я о том же - если что-то работает, то это ещё ничего не значит.

drBatty ★★ ()
Ответ на: комментарий от drBatty

да. Всё когда-то начиналось с локалхоста. Да и вообще - плохая идея открывать рут-доступ через веб

Никто никому не даёт рут-доступ через вёб. Если сервер в строго оговоренной ситуации делает строго оговоренные действия, это не значит, что у пользователя есть рут. Заявление, что выполнение скрипта по триггеру есть предоставление рута - то же самое, что заявить, что спаун вторичного процесса vsftpd для авторизации пользователя предоставляет ему рута.

Даже стилистические ошибки - это ошибки.

Угу. И орфографические ошибки в комментариях ещё сюда запиши.

Например запуск скрипта от рута - это ошибка, ну и что, что она работает?

Поэтому давайте выполнять скрипт от рута напрямую через sudo, чтобы к нему имел доступ каждый Вася, попавший на сайт! Оригинальная аберрация мышления.

не «напрямую», а через sudo, которая для того и предназначена кстати.

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

скорее потому там удобно, что в других местах тебе не разрешат срать

Если тебе ещё нет десяти лет, то да, «не разрешат». А если уже больше десят лет, то сам уже должен понимать, почему не разрешат и почему срать нужно в специально отведённых для этого местах. А, к примеру, заниматься половым сексом в других отведённых для этого местах.

Проблема в том, что если у тебя апач срёт сессиями, то туда же может срать и триггерами.

Триггерами он будет срать в специально отведённую под это дело папку. Которую можно примонтировать в другую песочницу, если уж совсем заморочиться на безопасности. Примонтировать в другую песочницу sudo не получится в принципе.

Ибо он же, а у системы нет возможности апачу не разрешать срать как-то по разному в разные места.

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

om-nom-nimouse ★★ ()
Ответ на: комментарий от om-nom-nimouse

Заявление, что выполнение скрипта по триггеру есть предоставление рута - то же самое, что заявить, что спаун вторичного процесса vsftpd для авторизации пользователя предоставляет ему рута.

представляет. Подумай, что случится, если там будет хоть одна незначительная ошибка? Подумай, куда надо встроить закладку, если хочешь получить доступ? Подумай, почему этот код такой простой?

Угу. И орфографические ошибки в комментариях ещё сюда запиши.

они ни на что не влияют. Ну кроме (не)понимания, но это обычно можно исправить.

Поэтому давайте выполнять скрипт от рута напрямую через sudo, чтобы к нему имел доступ каждый Вася, попавший на сайт! Оригинальная аберрация мышления.

Как ты не понимаешь такой простой мысли, что создать файл может намного более широкое множество «вась», чем выполнить скрипт. И защитить этот скрипт куда как проще, чем файл. Например ничего не стоит сделать его нечитаемым, можно и вообще скрыть его. Злоумышленнику, для запуска, придётся получить шелл от имени апача, а у апача этого шелла как раз и нет по дефолту, только путём php-скрипта, который читать/писать никому нельзя. А апачу - в принципе нельзя писать.

Ты можешь наконец понять, что sudo оно вообще не только для повышения прав используется, а обычно как раз и для _понижения_ этих прав.

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

почему именно «от рута»? От рута - не нужно. Нужно от другого юзера. Если юзер попытается запустить что-то другое, то администратор будет оповещён, и будет запись в логе. А вот если юзер понаделает 100500 файлов - ничего не произойдёт. Или - произойдёт доступ.

Вообще - каждую минуту должен запускаться скрипт от рута, и просматривать все файлы, которые сделаны в общедоступной директории, в поиске нужного триггера. Очевидно, что этот триггер ещё и удалять файлы должен, потому директория должна быть доступна ВСЕМ НА ЗАПИСЬ, ну или скрипт должен иметь права рута. И то и другое - очевидная дыра.

Если тебе ещё нет десяти лет, то да, «не разрешат». А если уже больше десят лет, то сам уже должен понимать, почему не разрешат и почему срать нужно в специально отведённых для этого местах. А, к примеру, заниматься половым сексом в других отведённых для этого местах.

У нас в Питере есть место, где видно семь мостов. Я там девушку поимел. И что? А то, что мне пофиг, до ваших правил. От злоумышленника нужно ждать того же отношения. Поверь мне.

Триггерами он будет срать в специально отведённую под это дело папку. Которую можно примонтировать в другую песочницу, если уж совсем заморочиться на безопасности. Примонтировать в другую песочницу sudo не получится в принципе.

во первых - папки у мамки. Во вторых - какие там права должны быть, что-бы и апач и скрипт могли там файлы создавать/удалять? В третьих, sudo не надо никуда «монтировать», достаточно задать чёткие правила - кто, откуда, кем, и что. Для каталога это невозможно, даже с ACL.

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

а я вижу проблему. Контроля-то нет. Проблемы нет тогда, и только тогда, когда доступа нет.

drBatty ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.