web-dev-qa-db-ja.com

環境変数を介して秘密を渡すことが「非常に安全でない」と考えられているのはなぜですか?

環境変数を介してシークレット(パスワード)をプログラムに渡すことは MySQL docs に従って「非常に安全でない」と見なされ、 その他のリソース では(セキュリティの観点から)不十分な選択と見なされます。

理由を知りたいのですが、何が欠けているのですか?前述のMySQLマニュアルでは(例としてこれを使用しています)、コマンドラインの-pオプションを介してパスワードを渡すと、「insecure」と見なされ、env var 「extlyly insecure」のように、太字の斜体フォント。

私はエキスパートではありませんが、基本的なことは知っています。権限のないユーザーが発行した単純なpsコマンドは、コマンドパラメータとともにすべてのプログラムを読み取ります同じユーザーのみ(およびroot、もちろん)プロセスの環境を読むかもしれません。したがって、ハッキングされたwww-dataスクリプトがrootを介してすべてを読み取る一方で、johndoejohndoeのみがps-開始されたプロセスの環境を読み取ることができます。

ここで私が見逃している大きな問題があるに違いありません-何が足りないのか説明してください。

私の目的は、あるプログラムから別のプログラムにシークレットを転送する手段を持つことです。一般的には、非インタラクティブです。

8

非常に安全ではないため、使用しないでください。 psの一部のバージョンには、実行中のプロセスの環境を表示するオプションが含まれています。一部のシステムでは、MYSQL_PWDを設定すると、psを実行する他のユーザーにパスワードが公開されます


herevia )の詳細:

背景:プロセス内で、argv []とenvp []は同じ方法で互いに隣り合って格納されます。 「クラシック」UNIXでは、/ usr/bin/psは通常setgid「kmem」(または同様のグループ)でした。これにより、アクティブプロセスに関する情報を読み取るために/ dev/kmem内を探索できました。これには、システム上のすべてのユーザーのプロセス引数と環境を読み取る機能が含まれていました。

最近、これらの「特権psハック」の大部分が私たちの背後にあります。UNIXシステムはすべて、このような情報を照会するさまざまな方法(Linuxの/ procなど)を考案してきました。そのuidによって。したがって、環境内のパスワードなどの機密性の高いデータが漏洩することはありません。

ただし、古い方法が100%死んでいるわけではありません。例と同じように、私がアクセスできるAIX 5.2マシンからの例を、非rootユーザーとして実行しています。

[サポート終了:2009。最近のAIXについて誰か知っていますか?]

...

記録のために、しばらく前に(IRCで?)OpenBSD 5.2が他のローカルユーザーに環境を漏らすというこのセキュリティ上の危険にさらされていることを発見しました(ただし、このリリースの直後に修正されました)。

[リリース年:2012]

6
sourcejedi

環境変数でシークレットを渡す場合の主な問題は、このシークレットを使用するプロセスにその環境を適切にスコープすることと、シークレットを持たないはずのプロセスにそれを与えないことです。

環境変数を使用する特定のプロセスを開始するためにのみ、環境変数を設定しても安全です。

ただし、シェルでグローバルに(現在のセッションの)環境にシークレットを設定することは安全ではありません(さらに悪いことに、シェルのグローバルスタートアップファイル(.bash_profile.bashrc.profile ))そのシェルから起動されたすべてのプロセスは、環境にこの秘密を持っているためです。一部は、意図的(マルウェア)であるかどうかにかかわらず、それらをリークする可能性があります(シェルコマンドの履歴、またはログファイルまたはリモートサーバーの環境の全内容をダンプするクラッシュレポートモジュールについて考えてください)。

残念ながら、アプリケーション開発者の観点からは、アプリケーションのユーザーが環境を適切にスコープすることを強制することは不可能です。私は個人的に~/.profileに保存されている非常に多くの秘密を見てきました。

したがって、ユーザーによる環境の悪用を回避するには、環境に直接シークレットを読み込まない方が(リークの影響を減らすため)、代わりに環境変数を使用して、シークレットが実際に格納されている場所へのリンクを渡します。インダイレクションの追加レイヤー。

2
dolmen

MySQLのドキュメントにあるこのアドバイスは、言葉遣いが不適切です。

逆に、環境変数でパスワードを渡すことは、それをコマンドラインで渡すよりも安全ではありません。最近のuniceのほとんどは、psコマンドおよびその他の同様のソフトウェアを通じて、プロセスのコマンドライン引数を公開しますが、環境は公開しません。例外はありますが、反対のシステム(引数を公開せずに環境を公開する)については聞いたことがありません。

パスワードがシェルの履歴に残るため、対話型シェルで入力されるコマンドにパスワードを含めることはお勧めできません。シェルの履歴をオフにしても問題ありませんが、必ずオフにする必要があります。これは、パスワードが引数として渡されるか、環境で渡されるかに関係なく適用されます。

環境変数でより危険なのは、変数が他のプロセスに渡される場合です。たとえば、.profileにデータベースパスワードを設定することは、すべてのプログラムから見えるため、非常に悪い考えです。同様に、mysqlを超えて多くのコマンドを実行するexport MYSQL_PWD=…を上部に配置してスクリプトを実行するのは好ましくありません。しかし、環境変数がmysqlコマンドにのみ渡される場合は、何も問題はありません。

MySQLのドキュメントでは、環境変数を介してパスワードを渡すことを、コマンドライン引数を介して渡すよりも安全性が低いと評価する言語を使用しないでください。それは逆です。 (環境がmysqlコマンド以上に設定されている場合を除き、それはドキュメントで説明されているシナリオではありません。)