コードが署名されていることを確認するためのシェルはありますか?


19

今週、PowerShellをいじっていましたが、実行するにはスクリプトに署名する必要があることがわかりました。Linuxには、bashスクリプトの実行の防止に関連する同様の安全な機能がありますか?

これに似ている唯一の機能は、特定のキーを必要とするSSHの機能です。


2
私に署名するパッケージに対するアドホックなソリューションのように聞こえます。Windowsに、Linuxのように署名する暗号化パッケージがあるかどうかはわかりません。
ワイルドカード

6
@ leeand00スクリプトはソフトウェアパッケージの特殊なケースであり、そのケースを取り上げる意味はありません。
ジル 'SO-悪であるのをやめる'

2
私が最も好きなメカニズムは、ChromeOSがこれを行う方法です。dm noexec-verityで署名されたブロックデバイスの読み取り専用パーティションにフラグが立てられていない唯一のファイルシステムを配置します。
チャールズダフィー

1
source.android.com/security/verifiedbootは、Androidがその(最初はChromeOS)機能を採用したことについて語っています。
チャールズダフィー

1
bashは、コマンドラインインターフェイスで手動で入力できるコマンドの束と考えることができます。とにかくコマンドラインに内容を入力できる場合、スクリプトを制限するポイントは何ですか?

回答:


11

ユーザーがスクリプトを実行する機能をロックしている場合sudoは、そのdigest機能を使用できます。
実行前にsudoers検証されるスクリプト/実行可能ファイルのハッシュを指定できますsudo。したがって、署名と同じではありませんが、sudoersも変更されない限り、少なくともスクリプトが変更されていないという基本的な保証が得られます。

コマンド名の前にDigest_Specが付いている場合、指定されたSHA-2ダイジェストを使用して検証できる場合にのみ、コマンドは正常に一致します。これは、sudoを呼び出すユーザーがコマンドまたはその親ディレクトリへの書き込みアクセス権を持っている場合に便利です。次のダイジェスト形式がサポートされています:sha224、sha256、sha384、sha512。文字列は、16進形式またはbase64形式で指定できます(base64はよりコンパクトです)。openssl、shasum、sha224sum、sha256sum、sha384sum、sha512sumなど、16進形式でSHA-2ダイジェストを生成できるユーティリティがいくつかあります。

http://www.sudo.ws/man/1.8.13/sudoers.man.html


SE Linuxについて読んでそれを正しく行うまで、それは私を引き止めます。
leeand00

13

はいといいえ。

Linuxソフトウェアの配布は、Windowsソフトウェアの配布とは多少異なります。(非組み込み)Linuxの世界では、ソフトウェアを配布する主な方法は配布(Ubuntu、Debian、RHEL、Fedora、Archなど)を介した方法です。すべての主要なディストリビューションは、約10年間にわたってパッケージに体系的に署名しています。

ソフトウェアが独立して配布される場合、ソフトウェアの出荷方法を決定するのはベンダー次第です。優れたベンダーは、主要なディストリビューションと互換性のあるパッケージソースを提供します(Linuxのすべてに統一されたディストリビューションメカニズムはありません。ソフトウェアディストリビューションはディストリビューションの主な差別化ポイントの1つです)。Linuxディストリビューションはサードパーティベンダーの署名機関としてはほとんど機能しません(CanonicalはUbuntuパートナーでこれを行いますが、ごく少数のベンダーのみを対象としています)。キーを信頼するかどうかを判断するのはユーザー次第です。

ネイティブ実行可能ファイル、データファイル、または複数のファイルで構成されるソフトウェアパッケージから、単一のスクリプトで構成されるソフトウェアパッケージを選択する特別なメカニズムはありません。ソフトウェアパッケージの検証はスクリプトの実行と完全に直交する問題であるため、一般的なスクリプトインタープリターには署名検証も組み込まれていません。

Windowsはファイルにそのオリジンを注釈し、オリジンが「ローカル」ではなく「ダウンロード」されたファイルを実行するにはユーザーの確認が必要だと思います。Linuxには実際に同様のメカニズムはありません。最も近いのは実行権限です。ダウンロードしたファイルには実行権限がありません。ユーザーは明示的に有効にする必要があります(chmod +xコマンドラインまたはファイルマネージャーの同等のアクション)。


2
FWIWは、このPowerShellの上に、署名されたスクリプトのみを実行するように(ポリシー設定によって)構成でき、このポリシーは、すべてのスクリプトに署名するか、「リモートオリジン」スクリプトのみ、またはスクリプトなしに構成できます。キー管理と中央ポリシー管理を備えたAD環境で最適に機能します。それはすることができますバイパスすることが:-)
スティーブン・ハリス

@StephenHarrisまあそうバイパスするように設定した場合
...-leeand00

@ leeand00-どうやらbase64エンコーディングもバイパスとして機能するようですが、PowerShellの新しいバージョンで閉じられているかどうかはわかりません。
スティーブンハリス

1
@ leeand00-darkoperator.com/blog/2013/3/5 / ...を参照してください:-)基本的に、コマンドラインでパラメーターとしてbase64でエンコードされたスクリプトを渡します:-) 簡単にラッピングできます!
スティーブンハリス

2
SeLinuxは、ファイルの作成元に注釈を付けます。それは主要な施設の1つです。
loa_in_


8

一言で言えば、「いいえ」。

Linuxは実際には実行可能ファイルとスクリプトを区別しません。#!冒頭には、入力を評価するために実行するためにどのようなプログラムカーネルに伝えるための方法ですが、それは、スクリプトを実行できる唯一の方法ではありません。

たとえば、スクリプトがある場合

$ cat x
#!/bin/sh 
echo hello

次に、コマンドでこれを実行できます

$ ./x

これにより、カーネルはそれを試行して実行し、見つけて#!から効果的に実行します/bin/sh x代わりにます。

ただし、これらのバリアントのいずれかを実行することできます。

$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x

あるいは

. ./x

カーネルが署名を強制しようとしても execレイヤーでとしても、スクリプトをパラメーターとしてインタープリターを実行するだけでこれをバイパスできます。

つまり、署名コードはインタープリター自体に存在する必要があります。そして、ユーザーが署名強制コードなしでシェルの独自のコピーをコンパイルするのを止めるものは何ですか?

これに対する標準的な解決策は、署名を使用することではなく、などの必須アクセス制御(MAC)を使用することSELinuxです。MACシステムでは、各ユーザーがレイヤーの実行と移行を許可される内容を正確に指定できます。したがって、たとえば、「通常のユーザーはWebサーバーとCGIプロセス/var/httpd以外は何でも実行できますが、ディレクトリの内容にしかアクセスできません。他のすべては拒否されます」と言うことができます。


1
This means that signing code would have to be in the interpreter itself. And what would stop a user from compiling their own copy of a shell without the signing enforcement code?実行を許可していないすべてのユーザーが署名鍵を持っていない場合は、それを行うだろう、符号なしの実行可能ファイル。これにはすでにさまざまな* nixプロジェクトがあります。
アルジー

2

Linuxディストリビューションには通常gnupgがあります。必要なのは、分離されたgpg署名を引数スクリプトに対してチェックし、チェックが成功した場合にのみスクリプトを実行する単純なbashラッパーだけであるように思えます。

#!/bin/sh
gpgv2 $1.asc && bash "$@"

これが存在しない唯一のものは...自分で...誰かがちょうど作ったスクリプトを実行している
leeand00

2

すぐに思い浮かぶ反論的な質問は、「ユーザーが作成したプログラムユーザーが実行できないようにしたいのはなぜですか?」というものです

  1. そもそも誰がコードを作成したかを検出することは文字通り不可能です。スクリプトファイルの所有者は、どこから来たかに関係なく、そのファイルのコンテンツを実際に保存した人だけです。そのため、署名を強制することは、確認ダイアログボックスの複雑な代替にすぎませんません。「これを実行してもよろしいですか?」Linuxでは、この問題の一部は署名付きパッケージで透過的に解決され、ユーザーがデフォルトでアクセスを制限しているという事実によって軽減されます。また、ユーザーは他人のコードを実行することは危険である可能性があることを知っている必要があります*。
  2. 同様に、スクリプトへの署名は、ファイルの保存よりもはるかに複雑な操作です。最良の場合、これにより、ユーザーはドキュメントに署名するのと同様のアクションを実行していることを認識し、続行する前にその内容を調べる必要があります。ほとんどの場合、スクリプトの実行を許可するユーザー側の技術的な習熟度を最小限に抑えます。最悪の場合、それは彼らが望んでいたことを実行するために長い一連のフープを飛び越えようとする意欲を示しています。Linux *の場合は、技術的なスキルが必要です。
  3. 一連のコマンドをコマンドラインに入力または貼り付けると、明らかに悪意のあるコード検出される可能性が高くなります。コピーして貼り付けることを目的としたプレーンテキストスニペットは、通常、適切に不正な操作を行うために必要な一連のコマンドよりも小さくなっています。また、ユーザーは各行を慎重にコピーして貼り付け、個別に行を作成して、発生する状況を把握できます。スクリプトを使用すると、ユーザーがコードをまったく見たことがない可能性があります。これは、署名スクリプトの有用なアプリケーションかもしれませんが、12回目以降は一般的な自己満足のコストがかかります。

*多くの人がLinuxを使い始めるにつれて、これはおそらくますます真実ではなくなってきています


1

システムの進化が異なる理由は、Linuxには「exec」ファイル属性があり、Windowsはファイル拡張子を使用して実行可能性を判断するためです。

そのため、Windowsでは、ユーザーをだまして、「。exe」、「。bat」、「。scr」の拡張子を持つファイルをダウンロードするように簡単に設定できます。そのファイルをダブルクリックすると、任意のコードが実行されます。したがって、このリスクを軽減するために、オリジントラッキングと実行可能/スクリプト署名の大きなメカニズムが構築されました。

Linuxでは、ユーザーにファイルを取得できる場合がありますが、「exec」ビットを簡単に強制的に設定することはできません。さらに、ファイルシステム全体を「noexec」にすることもできます。

いずれにしても、インタープリターを呼び出すことにより、スクリプトを明示的に実行できます。実行時にシェルスクリプトを作成して「sh」にパイプするか、「sh -c」を実行することもできます。


0

カスタムでは、多くのアーカイブプログラムは、含まれているファイルの実行ビットを保持しません。これにより、任意の実行可能ファイルを実行できなくなります。よくほとんど。

重要なのは、別の回答で説明されたように、実行ビットがなくても、そのようなスクリプトをに直接渡すことを妨げないということですbash。このようなスクリプトのほとんどはbashスクリプトであると言えますが、シバンはどのプログラムもインタープリターとして指定できます。これは、実行可能なセマンティクスを無視することにした場合、適切なインタープリターを実行するのはユーザー次第であることを意味します。

これはそれほど多くはありませんが、これは、カーネルとシェルだけを使用て、信頼できない実行可能ファイルを* nixes 実行することの防止をほぼカバーしています

コメントの1つで述べたように、もう1つの保護層がSeLinuxあります。これは、一連のルールに基づいてファイルの発信元を追跡します。セットアップは、SeLinuxたとえば、あなたがコピーして、周りのファイルを移動しても、ルートは、インターネットからダウンロードした実行可能なビットがセットされた実行可能ファイルを実行することができません。そのようなファイルは、質問で述べたものとは異なり、署名をチェックする別のバイナリーでのみ実行できるというルールを追加できます。

したがって、最終的には、一般に事前にインストールされているツールの構成の問題であり、答えはyesです。


多くのアーカイブプログラムは、含まれているファイルの実行ビットを保存しません。幸い、実行ビットtar 保持されます。
pjc50

tar -p ソース
loa_in_

-p, --preserve-permissions, --same-permissionsファイル許可に関する情報を抽出することを意味します(スーパーユーザーのデフォルト)
-loa_in_

いいえ、-pは必要ありません。マニュアルページに書かれていることはわかりますが、実際にはそうではありません。touch permtest; chmod +x permtest; tar cf permtest.tar.gz permtest; rm permtest; tar xf permtest.tar.gz; ls -l permtest-ここでは実行可能です。私はルートではありません。
-domen

その答えを改善しようと思います。
loa_in_
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.