Как получить действительный путь из аргумента в сценарии #! / Bin / sh?
I есть скрипт (копия) и вы хотите получить действительный путь.
#!/bin/sh
cp -R $1 $2
Я пробовал использовать такой параметр
./copy.sh /home/apple /home/pie;reboot
, после чего сервер был перезагружен, и это неприемлемо для рабочего сервера.
Я знаю, что путь в Linux состоит только из [a-zA-Z0-9 _- /. ]
Как мне отфильтровать $ 1 и $ 2, чтобы я мог звонить без опасений.
#!/bin/sh
$filtered_path_1=some_filter_funtion($1)
$filtered_path_2=some_filter_function($2)
cp -R $filtered_path_1 $filtered_path_2
Справочная информация
У меня есть jenkinsfile, и я вызываю sh 'sudo /home/copy.sh $ {Workspace} $ {targetdir}' в этом jenkinsfile. Поскольку у пользователя jenkins нет прав на запись в $ {targetdir }, Я дал пользователю jenkins права root только для этого скрипта copy.sh через
sudo visudo jenkins
ALL = NOPASSWD: /home/copy.sh,
. И этот jenkinsfile находится в репозитории git. Если злоумышленник изменит этот jenkinsfile с плохим кодом, например, перезагрузится, и зафиксирует его, затем скопируйте скрипт вызывается автоматически. Поскольку этот сценарий вызывается с правами суперпользователя, он может делать плохие вещи, используя эту слабую точку. Он удалит sh 'sudo /home/copy.sh $ {Workspace} $ { targetdir} ', а добавит sh' sudo /home/copy.sh / tmp / var; reboot '.
Как я могу его защитить?
1 ответ
Это не имеет ничего общего с вашим скриптом. В оболочке Bash ; рассматривается как команда завершения для строки команд, а затем сразу после нее является вторичной командой. Фактически, способ обработки ваших материалов выглядит следующим образом.
Выполнить команду перед
;:./ copycron.sh / home / apple / home / pieВыполнить вторую команду после
;:перезагрузка
Поскольку вы выполняли, вероятно, как root или суперпользователь, перезагрузка прошла успешно.
Однако, если вы сделаете что-то более конкретное и вместо этого выполните другую произвольную команду после ; , вы заметите, что команда запускается. Два ваших аргумента сценария останутся / home / apple и / home / pie соответственно. Сценарий никогда не видит часть ; reboot , потому что она не анализируется как аргумент. Это ограничение Bash, а не что-то в вашем скрипте.
Вы можете проверить это с помощью следующего сценария, а затем вызовы команд:
ФАЙЛ: argecho.sh
#!/bin/bash
echo "Space delimited arguments: $*"
echo ""
echo "------"
echo ""
КОМАНДА ДЛЯ ВЫПОЛНЕНИЯ:
./ argecho.sh foo bar baz /tmp/something.txt;echo Я сделал что-то еще
ВЫВОД:
$ ./argecho.sh foo bar baz /tmp/something.txt;echo I Did Something Else Outside The Script, see?
Space delimited arguments: foo bar baz /tmp/something.txt
------
I Did Something Else Outside The Script, see?
Вы заметите ' echo ', а другие аргументы в нем не были включены в ваши аргументы в вашем скрипте. Это стандартное поведение в Bash.
Основываясь на ваших изменениях, вы опасаетесь, что кто-то собирается захватить ваши команды репозитория Jenkins и выдать вредоносную команду, изменив сценарий с sh 'copycron "$ {Workspace}" "$ {targetdir}" ' to sh copycron / home / boot; shutdown
К сожалению, для вас это абсолютно ничего не может исправить, это приведет к тому, что вы не сможете должным образом контролировать, кто имеет доступ к репозиториям команд. У таких злоумышленников будет гораздо больше возможностей для повреждения вашей системы, а не только для выполнения простой команды, такой как вышеупомянутые изменения. Они с большей вероятностью установят вредоносное ПО в вашу систему, чем что-либо еще, и если вы должным образом не защитите свои репозитории команд, чтобы никто не мог просто «случайным образом редактировать их», ваше отсутствие контроля над репозиториями - вот что вас облажает.
Мы не можем сделать здесь реального усиления защиты, если у пользователя jenkins также есть неограниченные привилегии sudo. Его просто нет, потому что это будет зависеть от того, что вы должным образом защитите свои системы или создадите альтернативный механизм развертывания, который более безопасен и не требует полного sudo для работы со всем.