Linuxでの環境変数のアクセシビリティ
おそらくこれは簡単な質問ですが、異なるユーザー間でLinuxの環境変数にどの程度アクセスできるでしょうか。
例えばアリスが実行した場合
export FAVORITE_FOOD=`cat /home/alice/fav_food.txt`
イブはアリスの好きな食べ物は何ですか？ （アリスとイブの両方が通常のユーザーであり、イブには/home/alice/fav_food.txtへの読み取りアクセス権がないと仮定）
機密データの流れをたどってみましょう。この分析では、アリスができること、ルートもできることが理解されています。また、「1レベル上」の外部オブザーバー（たとえば、ディスクバス上のスヌープへの物理アクセス、またはコードが仮想マシンで実行されている場合はハイパーバイザー）がデータにアクセスできる場合があります。
まず、データがファイルから読み込まれます。 Aliceのみがファイルの読み取り権限を持ち、ファイルが他にリークされていないと仮定すると、Aliceのみがcat /home/alice/fav_food.txtを正常に呼び出すことができます。その後、データはcatプロセスのメモリにあり、そのプロセスだけがデータにアクセスできます。データはcatコマンドから呼び出し元のシェルにパイプを介して送信されます。関係する2つのプロセスだけがパイプ上のデータを見ることができます。その後、データはシェルプロセスのメモリに格納され、再びそのプロセスにプライベートになります。
ある時点で、データは最終的にシェルの環境に置かれます。シェルによっては、これはexportステートメントが実行されたとき、またはシェルが外部プログラムを実行したときにのみ発生します。この時点で、データは execve システムコールの引数になります。その呼び出しの後、データは子プロセスの環境に置かれます。
プロセスの環境は、そのプロセスの残りのメモリと同じくらいプライベートです（プロセスのメモリマップで mm->env_start からmm->env_endへ）。 初期スレッドのスタックに隣接 です。ただし、他のプロセスが環境のコピーを表示できるようにする特別なメカニズムがあります。プロセスの /procディレクトリ （/proc/$pid/environ）内のenvironファイル。このファイルは その所有者のみが読み取り可能 であり、誰が プロセスを実行しているユーザー です（特権プロセスの場合、これは有効なUIDです）。 （一方、/proc/$pid/cmdlineのコマンドライン引数はすべてのユーザーが読み取り可能です。）カーネルソースを監査して、これがプロセスの環境をリークする唯一の方法であることを確認できます。
execve call の実行中に、環境をリークする可能性のある別のソースがあります。 execveシステムコールは、環境を直接リークしません。ただし、execveを含むすべてのシステムコールの引数をログに記録できる汎用の 監査メカニズム があります。したがって、監査が有効になっている場合、環境は 監査メカニズム を介して送信され、ログファイルに記録されます。きちんと構成されたシステムでは、管理者のみがログファイルにアクセスできます（私のデフォルトのDebianインストールでは、これは/var/log/audit/audit.logであり、rootのみが読み取り可能で、rootとして実行されているauditdデーモンが書き込みます） 。
私は上に嘘をついた：私はプロセスのメモリが別のプロセスによって読み取られることができないと書いた。これは実際には当てはまりません。すべてのuniceと同様に、Linuxは ptrace システムコールを実装しています。このシステムコールにより、プロセスはメモリを検査し、別のプロセスのコンテキストでコードを実行することもできます。それがデバッガーの存在を可能にするものです。アリスだけがアリスのプロセスを追跡できます。さらに、プロセスに特権（setuidまたはsetgid）が付与されている場合は、rootだけがそれを追跡できます。
結論：プロセスの環境は、プロセスを実行しているユーザー（euid）のみが使用できます。
データをリークする可能性のある他のプロセスはないと想定していることに注意してください。通常のLinuxインストールでは、プロセスの環境を公開する可能性のあるsetuidルートプログラムはありません。 （一部の古いuniceでは、psはカーネルメモリを解析するsetuidルートプログラムでした。一部のバリアントはプロセスの環境をすべての人に喜んで表示します。Linuxでは、psは特権がなく、その/procのデータを他のみんなと同じように。）.
（これはLinuxの妥当な現在のバージョンに適用されることに注意してください。非常に昔のカーネル1.x時代には、環境は誰でも読み取り可能でした。）
最初は「いいえ」と言っていました。環境変数の値はユーザーごとであり、他のユーザーは別のユーザーの環境に対して読み取りまたは書き込みを行うことができません。 vars。ただし、SOには興味深いヒントがあります。これは、rootが少なくとも/proc/<pid>/environを介してこの情報を読み取ることができることを示しています。このLinux固有のインターフェースは今まで知りませんでした。
https://stackoverflow.com/a/532284/643314
そうは言っても、たとえ同じグループに属していても、このインターフェースは他のユーザーにはまだ読めないようです。 environファイルの権限は400に設定されており、/ procはchmodによる影響を防ぎます。ユーザー間で環境変数を分離するためのセキュリティドメインはまだ影響を受けておらず、通常の方法では回避できないと思います。
Gillesの理論的に正しい答えにもかかわらず、私は環境変数に秘密を入れません。
- 環境変数は通常、プロセスツリーの最上部近くで定義されます（例：
$HOME/.profile）。 - ユーザーは環境の内容を秘密として扱いません。
単一のプロセスが環境変数を誰でも読み取り可能なファイルに記録するだけで十分です：env >> env-traces.txt または類似。あなたはそれを制御することはできません。
ほとんどの場合、別のユーザーは環境変数を読み取ることができません。ただし、setuidプログラムのインスタンスが、setuidプログラムの他のインスタンスと同じユーザーとして実行されるというよく知られたセキュリティホールが悪用される可能性があります。つまり、誰かがsetuidプログラムを実行し、他の誰かが同じユーザーにsetuidされている別のプログラムを利用して/proc/<pid>/environから読み取ることができる場合、プログラムの環境変数を読み取ることができます。これが、nobodyユーザーを悪用する代わりに、作成するデーモンに新しいユーザーを使用する必要がある理由の1つです。
厳密なポリシーがない場合、理論的には、このエクスポートがAliceのbashログインユーザースクリプトで行われる場合、Eveはenvを出力するスクリプトを作成し、chmodにSETUIDGIDビットを設定して、それをAliceに割り当てます。次に実行されます。スクリプトはAliceのuidで実行され、bash自動実行はAliceのuidになります。次に、stdout =）を介してデータを漏らしますが、そのようなトリックを実行するには非常に弱いシステム設定が必要です。私は法医学の実習でこのようなひどく設定されたボックスを見たので、それは冗談ではありません。