機密データをプロセス環境に渡すことは安全ですか？
最近、コマンドラインを介さずに、またはファイルシステムエントリを使用せずに、あるプロセスから別のプロセスに（プロセスの起動時に）機密情報を渡す可能性を探しています。これはLinuxに関するものですが、問題は他のシステムにも当てはまります。
特に、MySQLサーバーにアクセスするためのパスワードは、スクリプトからMySQLクライアントに渡されます。これを行うには、コマンドライン（-pPASSWORD）を介してそれを渡すことができますが、単純なプロセスリストが他のすべてのユーザーにパスワードを公開するため、これは厄介です。この正確なケースでは、MySQLクライアントプログラムは、表示されるパスワード文字列をXXXに置き換えてコマンドラインテキストを上書きするのに十分友好的ですが、これは臭いソリューションです。
代わりにプロセス環境を使うことを考えました。スクリプトはプロセス環境でパスワードを設定し、開始されたサブプロセスはそこからそれを読み取ることができます。実際、MySQLクライアントはこれを許可し、環境変数MYSQL_PWDを探します。少なくとも私が知る限り、プロセス環境はrootとプロセスオーナー以外は誰も相談できないため、これはかなり安全でエレガントに見えます。
ただし、 MySQL 5.1マニュアル には次のように記載されています。
MySQLのパスワードを[環境を介して]指定するこの方法は、非常に安全でないと考えられるため、使用しないでください。
psの一部のバージョンには、実行中のプロセスの環境を表示するオプションが含まれています。一部のシステムでは、MYSQL_PWDを設定すると、psを実行する他のユーザーにパスワードが公開されます。そのようなバージョンのpsがないシステムでも、ユーザーがプロセス環境を調べることができる他の方法がないと想定するのは賢明ではありません。」
質問は次のとおりです。プロセス環境に機密データを渡すことは本当に安全ですか？権限を検証せずに別のプロセスの環境を参照できるシステムはありますか？明らかに、スーパーユーザーは自由にパスワードを取得できますが、その場合も、最初からパスワードを必要としません。
私自身の質問に答えるには：
一部のシステム、またはは確かに安全ではなく、他のプロセスに環境情報をリークしているようです。
現在のものと同様の問題が 'mosh'アプリケーションのユーザー 'mitchblank'によるgithub （モバイルシェル）で発生します。著者は書いている：
背景：プロセス内で、argv []とenvp []は同じ方法で互いに隣り合って格納されます。 「クラシック」UNIXでは、/ usr/bin/psは通常setgid "kmem"（または同様のグループ）でした。これにより、アクティブプロセスに関する情報を読み取るために/ dev/kmem内を探索できました。これには、システム上のすべてのユーザーのプロセス引数と環境を読み取る機能が含まれていました。
最近、これらの「特権psハック」の大部分が私たちの背後にあります：UNIXシステムはすべて、そのような情報を照会するさまざまな方法（Linuxの/ procなど）を考案しました。これらのすべて（？）は、プロセスの環境は読み取り可能であると考えていますそのuidによって。したがって、環境内のパスワードなどのセキュリティ上重要なデータは漏洩しません。ただし、古い方法が100％死んでいるわけではありません。ちょうど例として、これは私がアクセスできるAIX 5.2マシンからの例です...」
....
今日、moshはLinux/OSX/FreeBSDにのみ存在するようですが、問題が発生した場合は、「誰もが誰でも環境変数を見ることができる」という旧式のUNIXモデルを使用しているプラットフォームに到達するのではないかと心配しています。
環境変数の漏えいを許可するシステムの存在を確認できませんでした（歴史家や古いインストールにアクセスできる人々のための作業）。
周りを見回すと、2000年には環境変数が実際に機密と見なされていたことがわかります。つまり、潜在的な問題にフラグが付けられていました。 CERT脆弱性22404 を参照してください。確かに、上記のAIX 5.2の弱点はバグでした（修正されたため。残念ながら、インターネット上でこれ以外の詳細情報はありません IBM技術情報 ）
[〜＃〜] cert [〜＃〜] および RISKSフォーラム は、環境変数が安全でない方法で実装されたり、任意の時点で悪用されたりすることについては何も生じません。
他のプログラムが機密データを渡すかどうかはわかりませんが（GPGはそうではありません）、MySQLマニュアルの警告が上にあるようです。
user@example(pts/1)$ cd /proc/1022
user@example(pts/1)$ ls -lha environ
-r-------- 1 root root 0 Jul 22 17:20 environ
したがって、Linuxでは安全です。他のUNIXライクなOSでは安全でない可能性があります...
rootを信頼できない場合を除いて、すべての賭けは無効です。
古い常識は、次のとおりでした。いいえ、環境は安全ではありません。秘密を環境に流さないでください。
古い常識が今も当てはまるかどうかはわかりません。少なくとも最新バージョンのLinuxでは、1つのプロセスが別のプロセスの環境を表示することはできなくなっています（異なるユーザーが所有している場合）。ただし、他のオペレーティングシステムの機能はわかりません。私は環境に秘密を渡すことについてかなりうんざりしています。すべてのオペレーティングシステムが保護できると私が確信しているようなものではありません。
より安全な解決策：パイプをセットアップする（2つのプロセスに何らかの親子関係がある場合）、またはプロセス間通信（IPC）を使用するか、他のユーザーが読み取れないプライベートファイルに保存します。最善の解決策は、おそらく環境によって異なります。アプリケーションコードを記述している場合は、最初の2つのメカニズムのいずれかを検討できます。シェルスクリプトを作成する場合、おそらく最も簡単なのは、他のユーザーが読み取れないようにアクセス許可が設定されたプライベートファイルに保存することです。少なくともそれは私がやろうとしていることです-でも、私は過度に保守的である可能性は常にあります。
もちろん、単一のシステムでのみ動作する必要があるスクリプトを作成している場合は、そのシステムをテストして、他の誰かが環境を表示できるかどうかを確認できます。しかし、広く使用するための一般的なコードを記述している場合は、環境にシークレットを渡すのではなく、前の段落の解決策に傾倒します。 。