Я хотів би встановити певний скрипт bash під назвою 42FileChecker за допомогою команд:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

Але я не знаю, чи 42FileChecker.sh зробить якісь дивні речі на моєму ПК, тому що я новачок і не знаю, що відбувається в цьому сценарії. Чи є спосіб запустити його у фіктивній терміналі чи корінній папці манекена чи щось подібне, щоб побачити, що відбувається, щоб уникнути чогось божевільного, як форматування моїх дисків. Я хотів би знати про будь-який спосіб тестування оболонок на майбутні сценарії оболонки, навіть якщо 42FileChecker.sh безпечний.

Я не експерт з цього питання, але я б рекомендував використовувати straceта docker.

Тому спочатку створіть контейнер Docker відповідно до інструкцій у цій відповіді . Але додаток, що ця напруга, підкаже вам, які системні дзвінки здійснюються. Або цитувати:

strace - це утиліта діагностики, налагодження та інструктивного користувацького простору для Linux. Він використовується для моніторингу та втручання взаємодії між процесами та ядром Linux, які включають системні виклики, доставку сигналів та зміни стану процесу.

Ви можете комбінувати ці команди до

docker exec -it ubuntu_container strace bash ./42FileChecker.sh

Якщо ви не впевнені, що робить сценарій, вам краще не запустити його, поки ви не будете впевнені, що він робить. Способи зменшити радіус ураження поганого сценарію включають запуск його за допомогою нового користувача, запуск його в контейнері або запуск його у віртуальній машині. Але це перше твердження все-таки справедливо: Якщо ви не впевнені, що щось робить, подумайте, чи не виконувати його, поки не зробите.

Як сказав @ctt, спочатку, мабуть, хороша ідея запустити його в пісочниці. Використання VM - це, мабуть, найпростіше рішення. Мультипас досить простий.

Встановіть мультипас (якщо ви цього ще не зробили):

sudo snap install multipass --beta --classic

Спініруйте новий VM:

multipass launch --name myvm

Увійдіть у свій новий VM:

multipass shell myvm

Потім запустіть свій скрипт (всередині вашого vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

Оскільки школа, яку ви відвідуєте, опублікувала сценарії, найкраще висловити свої занепокоєння у ваших інструкторів.

Це означає, що ми можемо допомогти вам розшифрувати код по черзі. Кожен тут, мабуть, недоцільно аналізувати весь код.

Насправді у вас є 40 сценаріїв bash із загальною кількістю 5360 рядків. Я поєднав їх разом і шукав команди bash / shell, якими можна було б зловживати. Вони, як видається, використовуються нормально :

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
      'ROOT')
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

$ 

• Немає rm -rf /команди протирати весь розділ жорсткого диска.
• Немає жодної вимоги, яка sudoвикористовується для запуску сценарію.
• Сценарій фактично гарантує C, що у перевірених файлах використовуються лише авторизовані функції.
• Швидкий перегляд коду bash / shell показує, що це професійно написано та легко дотримуватися.
• Використання оболонок на об'єднаних файлах включають лише три синтаксичні помилки.
• Імена автора ідентифікуються, і головний автор навіть має свою картинку на своїй githubсторінці.
• Хоча гарантій у житті немає, 42FileCheckerвидається безпечним у використанні.

Це не читабельні людські сценарії, про які потрібно так сильно переживати. Це компільовані бінарні об'єкти, які ви не можете прочитати, що викликають занепокоєння. Наприклад, програма під назвою "shiny-bouncy-сфера" може намалювати щось подібне на вашому екрані, але на задньому плані це може стерти всі ваші файли.

Оригінальна відповідь

Найкраще запитати автора сценарію, що він робить. Дійсно, ви можете майже розмістити своє запитання дослівно, як показано вище.

Також запитайте автора:

• Які файли оновлюються?
• Що станеться у випадку аварії через відключення живлення або помилку програми?
• Чи можна виконати міні-резервне копіювання спочатку?

І будь-які інші хороші питання, які ви можете придумати.

Редагувати 1 - Турбує зловмисного автора.

Вам слід використовувати лише програмне забезпечення з великою кількістю хороших відгуків громадськості. Автори, яким ви довіряєте тут, запитуйте Ubuntu, як Сергій, Якоб, Колін Кінг тощо. Інші шановані сайти, такі як Ask Ubuntu та їх шановані члени, також слід вважати "нешкідливими".

Перевага "шанованих авторів" тут у Ask Ubuntu полягає в тому, що вони ставлять свою власну цінність на "репутаційні бали". Якби вони навмисно писали код, який "викрав" або "пошкодив" дані, вони швидко втратили б свою репутацію. Дійсно, автори можуть зазнати "гніву модників" і бути відстороненими та / або позбавленими 10 000 балів репутації.

Редагувати 2 - Не дотримуйтесь усіх інструкцій

Я глибше заглянув у ваші вказівки щодо скриптів bash:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

"Безпечний" метод полягає у запуску лише першого рядка:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

Це завантажує сценарії, але не виконує їх. Наступне використання nautilus(файловий менеджер) для огляду встановлених каталогів та файлів. Дуже швидко ви виявите, що є колекція баш сценаріїв, написана групою студентів у Франції.

Призначення сценаріїв - складання та тестування програм C на предмет неправильних функцій та витоку пам'яті.

Ви можете використовувати Docker. Контейнери Docker ізолюються від хост-операційної системи, тому будь-яка шкідлива діяльність залишатиметься в контейнері, доки ви спеціально не відпускаєте його, пересилаючи порти або монтуючи файлові системи.

Щоб встановити докер:

sudo apt-get install docker.io

Щоб завантажити новий контейнер Ubuntu Bionic:

docker pull ubuntu:bionic

Після цього увійдіть у контейнер

docker run -it ubuntu:bionic

і виконайте операцію хитрості в ньому:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh

Подумайте про використання режиму налагодження, запустивши сценарій як:

$ bash -x scriptname

Подальша корисна інформація про Bash

Режим налагодження не зупинить сценарій робити щось погано, але він дозволить вам пройти сценарій по черзі та вивчити ефекти. Ви також можете перевірити скрипт на наявність деяких поширених можливих помилок та / або подвигів, наприклад, пошукайте сценарії на предмет виникнення rmта перегляньте ці команди дуже уважно. Багато з цих інструментів мають деяку допомогу , побудовану протягом спроби їх, наприклад , фірма не буде видаляти каталог за замовчуванням, він потребує -r, -Rабо --recursiveможливості зробити це.

Можливо, навіть є якісь антивірусні інструменти, які б шукали баш скрипт для цих шаблонів, але я не знаю жодного за назвою. Ваші приклади сценарії - це щось зайве, але в тому сенсі, що вони завантажують інші інструменти, тому кожен з них також повинен бути вивчений. Перевірка серверів, на які вони контактують, також може бути вартим.

Відповідна інформація для надання відповіді, на жаль, знаходиться лише у вашому коментарі:

Я вивчаю C на курсі Ecole 42. Функції, які я створюю, потрібно запустити через цю перевірку норми. Мені потрібно встановити 42FileChecker в Ubuntu, щоб запустити цю перевірку норми.

Тож ситуація така, що на практиці у вас є можливість пропустити курс, або ви можете запустити скрипт для виконання нормативних перевірок ваших джерел. Розмова з вашим інструктором навряд чи є можливою через відсутність колишньої (це не було б варіантом інакше, жодна школа не збирається змінювати свою процедуру, оскільки один учень не задоволений цим).
Тому питання, що робити для обмеження можливого збитку від цього сценарію, навіть не виникає. Це не випадковий сценарій, щоб озлоблена дівчина з великими грудьми надіслала вам електронну пошту, і вам потрібно бігти, щоб побачити її фотографію .
Ти робиш клас програмування. Цеде цей сценарій увійшов у гру. Питання полягає в тому, чи хочете ви виконати рамкові умови для успішного проходження курсу.

Однак, якщо ви по-справжньому переживаєте, все ще існує можливість запуску скрипту в контейнері або віртуальній машині та розміщення джерел у загальній папці або на загальній мережі, відкриті контейнером / віртуальною машиною. Це в значній мірі проходить повний шлях параної, але знову ж таки віртуалізація - це насправді не все так складно, так що це не коштує дуже багато.

Заборона маловірогідної можливості по-справжньому суворої експлуатації, що міститься в цьому скрипті, вхід у систему як будь-який некористувальний користувач (який у вас навряд чи інший вибір робити в Ubuntu) і уникання введення sudo без очевидних причин, в значній мірі заважає 99% всі погані речі, які в будь-якому випадку могли трапитися. Такі як форматування жорсткого диска, про який ви хвилюєтеся. Звичайний користувач просто не може цього зробити. Найгірше, що трапиться, це те, що сценарій стирає домашній каталог користувача. То що, не важливо, насправді.