コードが署名されていることを確認するシェルはありますか？
私は今週PowerShellをいじくり回していましたが、スクリプトを実行するには、署名する必要があることがわかりました。 Linuxには、bashスクリプトの実行防止に関連する同様の安全な機能はありますか？
これに似ている唯一の機能は、私が知っているのは、特定のキーを必要とするSSHの機能です。
Sudoを介してスクリプトを実行するユーザーの機能をロックしている場合は、digest機能を使用できます。sudoersでスクリプト/実行可能ファイルのハッシュを指定できます。これは、実行前にSudoによって検証されます。したがって、署名とは異なりますが、sudoerも変更されない限り、スクリプトが少なくとも変更されていないという基本的な保証が得られます。
コマンド名の前にDigest_Specが付いている場合、コマンドは、指定されたSHA-2ダイジェストを使用して検証できる場合にのみ、正常に一致します。これは、Sudoを呼び出すユーザーがコマンドまたはその親ディレクトリへの書き込みアクセス権を持っている場合に役立ちます。次のダイジェスト形式がサポートされています：sha224、sha256、sha384およびsha512。文字列は16進数またはbase64形式で指定できます（base64の方がコンパクトです）。 openssl、shasum、sha224sum、sha256sum、sha384sum、sha512sumなどの16進数形式でSHA-2ダイジェストを生成できるユーティリティがいくつかあります。
はいといいえ。
Linuxソフトウェアの配布は、Windowsソフトウェアの配布とは多少異なります。 （非組み込み）Linuxの世界では、ソフトウェアを配布する主な方法は、配布（Ubuntu、Debian、RHEL、Fedora、Archなど）を介する方法です。すべての主要なディストリビューションは、約10年間、体系的にパッケージに署名しています。
ソフトウェアを個別に配布する場合、ソフトウェアの出荷方法を決定するのはベンダーの責任です。優れたベンダーは、主要なディストリビューションと互換性のあるパッケージソース（すべてのLinuxに統一されたディストリビューションメカニズムはありません。ソフトウェアディストリビューションはディストリビューション間の差別化の主なポイントの1つです）を提供し、ベンダーのキーで署名されています。 Linuxディストリビューションがサードパーティベンダーの署名機関として機能することはめったになく（CanonicalはこれをUbuntuパートナーで行いますが、カバーするベンダーはごくわずかです）、すべての主要なディストリビューションはTLS公開キーインフラストラクチャではなくPGP Webトラストを使用していると思います。キーを信頼するかどうかは、ユーザー次第です。
ネイティブ実行可能ファイル、データファイル、または複数のファイルで構成されるソフトウェアパッケージから、単一のスクリプトで構成されるソフトウェアパッケージを選別する特別なメカニズムはありません。ソフトウェアパッケージの検証はスクリプトの実行と完全に直交する問題であるため、署名検証は一般的なスクリプトインタープリターに組み込まれていません。
WindowsはOriginでファイルに注釈を付け、Originが「ローカル」ではなく「ダウンロード」されたファイルを実行するにはユーザーの確認が必要だと思います。 Linuxには実際には同様のメカニズムはありません。最も近いのは実行権限です。ダウンロードしたファイルには実行権限がありません。ユーザーは明示的に有効にする必要があります（chmod +xコマンドライン、またはファイルマネージャでの同等のアクション）。
Linuxは、デジタル署名に基づいてbashスクリプトの実行を制限する機能を提供していません。
バイナリ実行可能ファイルの認証に関するいくつかの作業があります。詳細は https://lwn.net/Articles/488906/ を参照してください。
つまり、「いいえ」。
Linuxは実行可能ファイルとスクリプトを実際に区別しません。 #!最初に、入力を評価するために実行するプログラムをカーネルに指示する方法ですが、スクリプトを実行できる唯一の方法ではありません。
たとえば、スクリプトがある場合
$ cat x
#!/bin/sh
echo hello
次に、これをコマンドで実行できます
$ ./x
これにより、カーネルはそれを試行して実行し、#!してから、効果的に/bin/sh x代わりに。
しかし、私はalsoこれらのバリアントのいずれかを実行することもできます：
$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x
あるいは
. ./x
したがって、カーネルがexecレイヤーで署名を強制しようとした場合でも、スクリプトをパラメーターとして使用してインタープリターを実行するだけでこれを回避できます。
これは、コードの署名がインタープリター自体になければならないことを意味します。そして、ユーザーが自分のシェルのコピーをコンパイルするのを止めるにはどうすればよいですかなし署名実施コード？
これに対する標準的な解決策は、署名を使用することではなく、SELinuxなどの必須アクセス制御（MAC）を使用することです。 MACシステムを使用すると、各ユーザーが実行できるレイヤーと移行レイヤーを正確に指定できます。たとえば、「通常のユーザーは何でも実行できますが、WebサーバーとCGIプロセスは/var/httpdディレクトリ;それ以外はすべて拒否されます。」.
Linuxディストリビューションには通常gnupgがあります。必要なのは、分離されたgpgシグニチャーを引数スクリプトと照合してチェックが成功した場合にのみスクリプトの実行に進む単純なbashラッパーのように思えます。
#!/bin/sh
gpgv2 $1.asc && bash "$@"
すぐに頭に浮かぶ反問は、「ユーザーがプログラムを実行できないようにする理由が書いた理由」です。いくつかの可能性があります。
- 最初にコードを作成した人を検出することは文字通り不可能です。スクリプトファイルの所有者は、場所に関係なく、そのファイルのコンテンツを実際に保存した人だけですから来た。したがって、署名の強制は複雑な確認ダイアログボックスの代わりになります：「本当に実行しますか？」 Linuxでは、この問題の一部は署名付きパッケージで透過的に解決され、ユーザーはデフォルトでアクセスが制限されているという事実によって緩和されます。ユーザーは、他人のコードを実行することは危険である可能性があることを知っていることも期待されています*。
- 同様に、スクリプトへの署名は、ファイルの保存よりもはるかに複雑な操作です。最良の場合、これはユーザーにドキュメントへの署名と同様のアクションを実行していることを認識させ、続行する前にその内容を検査する必要があります。ほとんどの場合、スクリプトの実行を許可するユーザー側のtechnical proficiencyの非常に最小限のレベルを保証するだけです。最悪の場合、長い一連のhoopsを飛び越えて、彼らがやりたいことを実行する意欲を示しています。 Linux *では、技術的な熟練を前提としています。
- 一連のコマンドをコマンドラインに入力/貼り付けると、人々は明らかに悪意のあるコードを検出する可能性が高くなります。コピーして貼り付けることを意図した平文スニペットは、通常、何か不適切なことを行うために必要な一連のコマンドよりも小さいです。また、ユーザーはすべての行を個別に注意深くコピーして貼り付けることができ、発生時に何が起こるかを理解できます。スクリプトを使用すると、ユーザーがコードをまったく見たことがない可能性があります。これは、署名されたスクリプトの有用なアプリケーションである可能性がありますが、12回目以降は、自己満足という非常に一般的なコストがかかります。
*これは、Linuxの使用を開始する人が増えるにつれて、ますます真実でなくなります。
システムが異なる形で進化した理由は、Linuxには「exec」ファイル属性があり、Windowsはファイル拡張子を使用して実行可能性を判断するためです。
したがって、Windowsでは、ユーザーをだまして「.exe」、「。bat」、「。scr」の拡張子を持つファイルをダウンロードさせるのは簡単ですデフォルトでは非表示になります。そのファイルをダブルクリックすると、任意のコードが実行されます。したがって、このリスクを軽減するために、Originトラッキングと実行可能ファイル/スクリプト署名の大きなメカニズムが構築されました。
Linuxでは、ユーザーにファイルを取得できる可能性がありますが、「exec」ビットを簡単に設定することはできません。さらに、ファイルシステム全体を「noexec」にすることも可能です。
いずれの場合も、インタープリターを呼び出すことにより、明示的にスクリプトを実行できます。実行時にシェルスクリプトを作成して「sh」にパイプするか、「sh -c」を実行することもできます。
カスタムでは、多くのアーカイブプログラムは、含まれているファイルの実行ビットを保持しません。これにより、任意の実行可能ファイルを実行することが不可能になります。よくほとんど。
要点は、実行ビットの欠如は、そのようなスクリプトを直接bashに渡すことを妨げないという別の回答で説明されていることです。そのようなスクリプトのほとんどがbashスクリプトであることは間違いありませんが、Shebangは任意のプログラムをインタープリターとして指定できます。つまり、実行可能なセマンティクスを無視することを決定した場合、適切なインタープリターを実行するのはユーザー次第です。
これはそれほど多くありませんが、* nixes カーネルとシェルのみで信頼できない実行可能ファイルが実行されるのを防ぐことについてはかなりカバーしています。
コメントの1つで述べたように、もう1つの保護層-SeLinux-があります。これは、一連のルールに基づいてファイルのOriginを追跡します。 SeLinuxを設定すると、たとえば、ファイルをコピーして移動しても、インターネットからダウンロードされた実行可能ビットが設定された実行可能ファイルをrootが実行することはできません。そのようなファイルは、あなたが質問で述べたこととは異なり、署名をチェックする別のバイナリを介してのみ実行できるというルールを追加できます。
つまり、最終的には、一般的にプリインストールされているツールの構成の問題であり、答えはyesです。