Рейтинг:0

Как я могу получить правильный путь из аргумента в сценарии #!/bin/sh?

флаг cn

У меня есть скрипт (копия) и я хочу получить правильный путь.

#!/бин/ш
ср -R $1 $2

Я пробовал с таким параметром

./copy.sh /home/apple /home/pie; перезагрузить

затем сервер был перезагружен, и это неприемлемо для рабочего сервера.

Я знаю, что путь Linux состоит только из [a-zA-Z0-9_-/. ]

Как я могу отфильтровать $1 и $2, чтобы я мог спокойно коллировать?

#!/бин/ш
$filtered_path_1=some_filter_function($1)
$filtered_path_2=some_filter_function($2)
cp -R $filtered_path_1 $filtered_path_2

Задний план

У меня есть файл jenkins, и я вызываю sh 'sudo /home/copy.sh ${Workspace} ${targetdir}' в этом файле jenkins. Поскольку пользователь jenkins не имеет прав на запись в ${targetdir}, я предоставил пользователю jenkins привилегии root только в этом сценарии copy.sh через

Судо Висудо Дженкинс    
ВСЕ = НЕПАРОЛЬ: /home/copy.sh, 

И этот jenkinsfile находится в репозитории git. Если плохой парень изменит этот файл jenkins с помощью плохого кода, такого как перезагрузка, и зафиксирует его, то сценарий копирования вызывается автоматически. Поскольку этот скрипт вызывается с привилегиями root, он может делать плохие вещи, используя это слабое место. Он удалит sh 'sudo /home/copy.sh ${Workspace} ${targetdir}' и добавит sh 'sudo /home/copy.sh /tmp /var;reboot'.

Как я могу защитить его?

флаг cn
Вставьте свой код на https://www.shellcheck.net, чтобы получить совет, который решит эту проблему.
Denis Turgenev avatar
флаг cn
@glenn, спасибо, и я думаю, что это не дает решения, как изменить $1->$safe1.
флаг ru
@DenisTurgenev Это не имеет ничего общего с разбором аргументов, чтобы сделать его безопасным. Это все, что связано со средой оболочки, в которой вы работаете по умолчанию (например, bash). Мой ответ подробно описывает это полностью. И дает вам тестовый сценарий и набор команд, которые показывают вам это в действии без взрыва вашей системы.
bac0n avatar
флаг cn
`./copy.sh evil.sh copy.sh` упс
Рейтинг:2
флаг ru

Это не имеет ничего общего с вашим сценарием. В оболочке Bash ; рассматривается как команда завершения для строки команд, а затем сразу после нее является вторичной командой. Таким образом, ваш материал был обработан следующим образом.

  1. Выполнить команду до ;:

    ./copycron.sh /дом/яблоко /дом/пирог
    
  2. Выполните вторую команду после ;:

     перезагрузка
    

Поскольку вы выполняли, вероятно, как корень или суперпользователя, он успешно перезагрузился.

Однако, если вы сделаете что-то более конкретное и выполните другую произвольную команду после ; вместо этого вы заметите, что команда запускается. Два ваших аргумента к вашему сценарию останутся /дом/яблоко и /дом/пирог соответственно. Скрипт никогда не видит ;перезагрузка часть, потому что это не анализируется как аргумент. Это ограничение Bash, а не что-то в вашем скрипте.


Вы можете проверить это с помощью следующего сценария, а затем вызвать команду:

ФАЙЛ: argecho.sh

#!/бин/баш

echo "Аргументы, разделенные пробелами: $*"
эхо ""
эхо "------"
эхо ""

КОМАНДА ДЛЯ ВЫПОЛНЕНИЯ: ./argecho.sh foo bar baz /tmp/something.txt;echo Я сделал что-то еще

ВЫВОД:

$ ./argecho.sh foo bar baz /tmp/something.txt;echo Я сделал что-то еще вне сценария, понимаете?
Аргументы, разделенные пробелами: foo bar baz /tmp/something.txt

------

Я сделал что-то еще вне сценария, понимаете?

Вы заметите, что «эхо» и другие аргументы в нем не были включены в ваши аргументы в вашем сценарии. Это стандартное поведение Bash.



Основываясь на ваших изменениях, вы обеспокоены тем, что кто-то собирается захватить команды вашего репозитория Jenkins и выполнить вредоносную команду, изменив сценарий с sh 'copycron "${Workspace}" "${targetdir}"' к sh copycron /home/boot;shutdown

К сожалению для вас, вы ничего не можете исправить, это приведет к тому, что вы не сможете должным образом контролировать, кто имеет доступ к репозиториям команд. Такие субъекты угроз будут иметь гораздо больше возможностей нанести ущерб вашей системе, а не просто выполнить простую команду, подобную вышеупомянутым изменениям. Скорее всего, они установят вредоносное ПО в вашу систему, чем что-либо еще, и если вы не защитите свои репозитории команд должным образом, чтобы никто не мог просто «случайно редактировать их», отсутствие контроля над репозиториями — это то, что вас погубит.

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

Denis Turgenev avatar
флаг cn
У меня есть jenkinsfile, и я вызываю `sh 'copycron ${Workspace} ${targetdir}'` в jenkinsfile. И этот jenkinsfile находится в репозитории git. пользователь jenkins имеет привилегии root только для этого сценария copycron через `sudo visudo jenkins ALL = NOPASSWD: /home/copycron`, потому что у jenkins нет прав на запись в ${targetdir}, и если злоумышленник изменит этот файл jenkins с помощью плохого кода, например, перезагрузится и зафиксирует его, то скрипты copycron вызываются автоматически, и потому что этот скрипт вызывается в привилегиях root, он может делать плохие вещи.
флаг ru
Это ограничение вашего вызова через `sh`, а не ограничение всего остального или даже вашего скрипта. Проблема в том, что `sh` выполняет это в оболочке точно так же, как если бы я выполнял это в Bash. Вы должны заключать свои аргументы в полные кавычки, если хотите, чтобы они «очищались», а не запускались. т.е.`sh 'copycron "${Workspace}" "${targetdir}"'` Таким образом он обрабатывает ; как часть строки. Тогда ваш скрипт просто выдаст ошибку, потому что targetdir не может быть найден.
Denis Turgenev avatar
флаг cn
Проблема в том, что плохой парень может легко изменить мой мелкозернистый сценарий. `sh 'copycron "${Workspace}" "${targetdir}"'` -> `sh copycron /home/boot;shutdown` Потому что файл jenkins находится в репозитории git.
флаг ru
@DenisTurgenev Я думаю, мне нужно задать другой вопрос: почему вы обеспокоены тем, что замешан «плохой парень»? Если репозиторий надежно защищен, у злоумышленника не будет доступа к редактированию скрипта. Если плохой парень *получит* доступ к сценарию, вы в любом случае попадете под шланг, нет никакого способа дезинфицировать команду, которую вы указываете. Это неспособность контролировать ваши репозитории, а не проблема сценария Bash и * не * то, от чего вы сможете защититься, если не защитите свои репозитории команд должным образом.
Denis Turgenev avatar
флаг cn
Кстати, как вы называете такого плохого парня в терминах безопасности? :) Я не эксперт по безопасности, а также не эксперт по английскому языку.
Denis Turgenev avatar
флаг cn
Это проект, разработанный 50 разработчиками, и, конечно, только эти люди могут получить доступ под своей учетной записью. Например, одного разработчика уволили, а пока он уходит из компании, говоря «иди к черту!», можно и это исполнить. Но не слишком ли это резкое предположение? :) Я очень люблю воображать, так что простите меня, если я был слишком резок.
флаг ru
Это более широкое обсуждение, чем могут вести комментарии, и оно потребует от меня надеть шляпу безопасности, чтобы дать вам правильное объяснение проблемы «внутренней угрозы», неправильного управления пользователями и неправильного аудита с вашей стороны. Если вы хотите пообщаться, я могу создать чат для вас и меня, чтобы обсудить это подробно, однако это гораздо более глубокая проблема, чем можно обсудить в комментариях.
Denis Turgenev avatar
флаг cn
спасибо, я соберу еще несколько вопросов безопасности и скоро свяжусь с вами. спасибо за ваше время и ценную помощь.

Ответить или комментировать

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