コンピューターへの害を避けるために、「安全な環境」でシェルスクリプトをテストするにはどうすればよいですか？
次のコマンドを使用して、42FileCheckerという特定のbashスクリプトをインストールします。
git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
cd ~/42FileChecker &&
bash ./42FileChecker.sh
しかし、42FileChecker.shがPCで奇妙なことを行うかどうかはわかりません。私は初心者であり、そのスクリプトで何が起こっているのかわからないからです。ドライブのフォーマットのようなおかしなことを避けるために、ダミーターミナルやダミーのルートフォルダーなどでそれを実行して何が起こるかを確認する方法はありますか？ 42FileChecker.shが安全であるとしても、将来のシェルスクリプト用にシェルをテストする方法を知りたいのですが。
私はこれについての専門家ではありませんが、straceとdockerの使用をお勧めします。
したがって、まず this answer の指示に従ってDockerコンテナを作成します。しかし、straceがどのシステムコールが行われたかを教えてくれることも追加されました。または引用するには：
straceは、Linux用の診断、デバッグ、および教育用のユーザー空間ユーティリティです。システムコール、シグナル配信、プロセス状態の変更など、プロセスとLinuxカーネル間の相互作用を監視および改ざんするために使用されます。
これらのコマンドを組み合わせて、
docker exec -it ubuntu_container strace bash ./42FileChecker.sh
スクリプトの機能がわからない場合は、スクリプトの機能がはっきりするまでスクリプトを実行しないことをお勧めします。不正なスクリプトの損傷範囲を小さくする方法には、新しいユーザーを使用してスクリプトを実行する、コンテナで実行する、仮想マシンで実行するなどがあります。しかし、その最初のステートメントはまだ保持されます。何かが何をするかわからない場合は、実行するまで実行しないことを検討してください。
@cttが言ったように、まず何らかのサンドボックスで実行することはおそらく良い考えです。 VMを使用するのがおそらく最も簡単なソリューションです。 Multipass は非常に単純です。
マルチパスをインストールします（まだ実行していない場合）：
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
あなたが通っている学校が台本を公開しているので、あなたの懸念を表明するのに最適な場所はインストラクターと一緒です。
とはいえ、コードを1行ずつ解読できるようにお手伝いします。ここでコードを分析allすることは、おそらく実際的ではありません。
実際には、合計5,360行の40個のbashスクリプトがあります。私はそれらを組み合わせて、悪用される可能性のある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コードをざっと見ると、それが専門的に書かれており、簡単に理解できることがわかります。
- マージされたインクルードファイルで shellcheck を使用すると、3つの構文エラーのみが明らかになります。
- 著者名が識別され、主要な著者は自分の
githubページに自分の写真を掲載しています。 - 保証はありませんが、
42FileCheckerは安全に使用できます。
それはあなたがそれほど心配する必要がある人間が読めるbashスクリプトではありません。これは、問題の原因となる、読み取ることができないコンパイル済みのバイナリオブジェクトです。たとえば、「shiny-bouncy-sphere」と呼ばれるプログラムは、画面にそのようなものをペイントしますが、バックグラウンドではすべてのファイルを消去している可能性があります。
元の答え
スクリプトの作者にそれが何をするか尋ねることが最善です。実際、上に表示されているとおり、質問をそのまま投稿することができます。
また、作者に尋ねます：
- どのファイルが更新されますか？
- 停電やプログラムのバグが原因でクラッシュした場合はどうなりますか？
- 最初にミニバックアップを実行できますか？
そして、あなたが考えることができる他の良い質問。
編集1-悪意のある作成者の心配。
あなたは多くの良い評判のあるソフトウェアだけを使うべきです。代わりに、Serge、Jacob、Colin Kingなど、Ask Ubuntuで信頼できる著者。AskUbuntuなどの尊敬されるサイトとその尊敬されるメンバーも「悪意のない」と見なされます。
ここ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（ファイルマネージャ）を使用して、インストールされているディレクトリとファイルを検査します。フランスの学生グループによって書かれたbashスクリプトのコレクションがあることにすぐに気づきます。
スクリプトの目的は、不適切な関数とメモリリークがないかCプログラムをコンパイルしてテストすることです。
Dockerを使用できます。 DockerコンテナーはホストOSから分離されているため、ポートの転送やファイルシステムのマウントによって明示的に許可しない限り、悪意のあるアクティビティはコンテナー内にとどまります。
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 情報
デバッグモードでは、スクリプトが何か悪いことをするのを防ぐことはできませんが、スクリプトを1行ずつ実行してその影響を調べることができます。また、いくつかの一般的な潜在的なミスやエクスプロイトについてスクリプトをチェックすることもできます。スクリプトでrmが発生していないか検索し、それらのコマンドを非常に詳しく調べます。これらのツールの多くには、それらを試すためにいくつかのヘルプが組み込まれています。 rmはデフォルトではディレクトリを削除しません。削除するには、-r、-R、または--recursiveオプションが必要です。
これらのパターンをbashスクリプトで検索するウイルス対策のようなツールもいくつかあるかもしれませんが、名前ではわかりません。スクリプトの例は、他のツールをダウンロードするという意味で、特別なものになっているので、それらもそれぞれ検討する必要があります。彼らが接触するサーバーをチェックすることも価値があるかもしれません。
回答を提供するための関連情報は、残念ながらあなたのコメントでのみ見つかります。
エコール42コースでCを学んでいます。私が作成している関数は、このノルムチェックを実行する必要があります。この標準チェックを実行するには、42FileCheckerをUbuntuにインストールする必要があります。
したがって、状況は実際にはコースをスキップするオプションがあるか、スクリプトを実行してソースの規範的なチェックを実行できます。前者が不足しているため、インストラクターと話すことはほとんど選択肢の1つではありません（いずれにせよそれは選択肢ではありません。1人の生徒がそれに不満を持っているため、どの学校も手順を変更しません）。
そのため、そのスクリプトから生じる可能性のある損傷を制限するために何をすべきかという問題は発生しません。大きな胸を持つ角質の女の子があなたに電子メールで送信したランダムなスクリプトではありません彼女の写真を表示するには実行する必要があります。
あなたはプログラミングクラスをやっています。 Thisは、このスクリプトが登場した場所です。問題は、コースを正常に完了するためのフレーム条件に準拠するかどうかです。
ただし、本当に心配している場合でも、コンテナーまたは仮想マシンでスクリプトを実行して、ソースを共有フォルダーに置くか、コンテナー/仮想マシンによって公開されているネットワーク共有に置く可能性があります。それはほぼ完全なパラノイアの道を進んでいますが、仮想化は最近では本当にそれほど複雑ではないので、それほど多くのコストはかかりません。
そのスクリプトに含まれる本当に過酷なエクスプロイトのありそうもない可能性を排除して、非rootユーザーとしてログインし（Ubuntuで他の方法で選択することはほとんどできません）、入力を避けるSudo明らかな理由もなく、とにかく起こり得るすべての悪いことの99％をほとんど防ぎません。ハードディスクのフォーマットなど、気になるところ。通常のユーザーはそれを行うことはできません。最悪の事態は、スクリプトがユーザーのホームディレクトリを消去することです。では、何の問題もありません。