子プロセスにパスワードを渡すには？

プロセスパラメータはすべてのユーザーに表示されますが、環境は同じユーザー（少なくともLinuxでは、そして私はすべての最新のUNIXバリエーションについて考えます）。したがって、環境変数を介してパスワードを渡すのは安全です。誰かが環境変数を読むことができれば、その人もあなたと同じようにプロセスを実行できるので、ゲームは終了します。

psたとえば、何かを調査し、誤って結果（機密環境変数を含む）をコピーして公共の場所に貼り付けると、環境コンテンツが間接的に漏洩する危険性があります。もう1つのリスクは、環境変数を必要としないプログラム（パスワードが必要なプロセスの子プロセスを含む）に環境変数を渡し、そのプログラムが環境変数を秘密にしたくないために公開することです。この二次漏洩リスクの重大度は、パスワードのあるプロセスの役割（実行期間、子プロセスが実行されるかどうか）によって異なります。

パイプなどの盗聴用に設計されていないチャネルを介してパスワードを渡すと、誤ってパスワードが漏洩しないようにするのが簡単になります。送信側ではこれを行うのは簡単です。たとえば、シェル変数にパスワードがある場合は、次のようにします。

echo "$password" | theprogram

theprogram標準入力にパスワードが必要な場合。これはecho内蔵されているので安全です。外部コマンドを使用すると、パラメータが出力psに公開されるため安全ではありません。同じ効果を得るもう一つの方法は、ここでドキュメントを使用することです。

theprogram <<EOF
$password
EOF

パスワードが必要な特定のプログラムには、特定のファイル記述子からパスワードを読み取るように指示できます。他に標準入力が必要な場合は、標準入力以外のファイル記述子を使用できます。たとえば、次のようにしますgpg。

get-encrypted-data | gpg --passphrase-fd 3 --decrypt … 3<<EOP >decrypted-data
$password
EOP

プログラムにファイル記述子を読み込むように指示することはできませんが、プログラムにファイルから読み取るように指示できる場合は、「/dev/fd/3」などのファイル名を使用して、プログラムにファイルから読み取るように指示できます。記述子。

theprogram --password-from-file=/dev/fd/3 3<<EOF
$password
EOF

ksh、bash、またはzshでは、プロセスの置き換えによってこれをよりきれいにすることができます。

theprogram --password-from-file=<(echo "$password")

パラメータまたは環境変数を介して直接パスワードを渡すのではなく

#!/bin/bash
#filename: passwd_receiver
echo "The password is: $1"

同じパラメータまたは環境変数を使用して渡します。ファイル名:

#!/bin/bash
#filename: passwd_receiver
echo "The password is: $(< "$1")"

それで合格できます。権限で保護された一般ファイル（同じユーザーとして実行される他のプロセスから保護されていませんが）、/dev/stdinまたは管路場所は次のとおりです（わかっている限り、同じユーザーとして実行されている他のプロセスからユーザーを保護します）。

 echo PASSWORD | ./passwd_receiver /dev/stdin 

/dev/stdinここを使うとパイプでなければなりません。。端末の場合は、同じユーザーで実行されている他のプロセスから読み取ることができます。

別の目的ですでに必要な場合は、次のものを/dev/stdin使用できます。プロセスの交換これは、パイプをサポートするシェルを使用する場合、パイプの使用と基本的に同じです。

./passwd_receiver <(echo PASSWORD)

名前付きパイプ（FIFO）は同じように見えますが、傍受することができます。

これらのソリューションは完全に安全ではないどちらも問題ありませんが、頻繁に交換するメモリ制約のあるシステムを使用しない限り、十分に似ています。

理想的には、これらのファイル（パイプもファイルです）をラベル付きメモリに読み込みます。時計ロック(2)非可用性のため、これはパスワードハンドラ（gnupgなど）が通常行うことです。

メモ:

1. 理論的には、ファイルディスクリプタ番号を渡すのはファイル名を渡すのと同じくらい良いですが、filenameはファイルディスクリプタ番号ではなく<()ファイル名を提供するので、より実用的です（そしてcoprocsはタグ付きファイルディスクリプタを提供します）FD_CLOEXECこれにより、このコンテキストではこれらのファイル記述子を使用できなくなります）。

2. 
   /proc/sys/kernel/yama/ptrace_scopeメモリに設定されたLinuxシステムを使用している場合0）

3. 他の（rootではない）ユーザーとして実行されているプロセスからパスワードを離れる必要がある場合は、パラメータ、環境変数、パイプ、および権限で保護されたファイルはすべて問題ありません。

いいえ、環境変数も読みやすく、サブプロセスに漏洩します。パイプを使用して通過します。

他の適切なオプションがない場合は、Linuxキー保持サービス（カーネルキーリング）を検討してください。

次から始めましょう：セキュリティ/keys.txt。主キーリングの1つは、親プロセスと子プロセスの間で複製できます。

最も単純な解決策ではありませんが、存在し、維持され使用されているようです（昨年はAndroidのバグでもこれについて説明しました）。

私はそれが「政治的」状態であるかどうかはわかりませんが、同様の必要性があり、Guileバインディングを調べ始めました。既存のPerlサポートは発生しませんでした。