UNIXソケットには通常、ピアプロセスを認証するメカニズムがあります。ただし、オフハンド攻撃を混同しないように注意してください。
SO_PASSCREDたとえば、LinuxにはUNIXソケットを介して資格情報を渡す2つの方法がありますSO_PEERCRED。SO_PEERCREDストリームソケットのみがサポートされ、socketpair(2)ユーザーIDは有効な資格情報から派生し、ソケットを接続したりソケットペアを作成したときに変更されます。
SO_PASSCRED一方、メッセージごとに再生成され、デフォルトでは実際の資格情報から派生します。 FreeBSDには同様のAPIがありますが、詳細は異なります。
通常、プロセスで使用されるソケットは、プロセスで作成され、親プロセスから継承され、UNIXソケットを介して渡されます。ソケットがプロセスによって作成された場合、プロセスはソケットを安全に使用する責任を明示的に引き受けることができます。継承され渡されたソケットの場合、SO_PEERCRED資格情報が作成者から派生するため、特別な問題は発生しません。
SO_PASSCREDwrite(2)プロセス呼び出しが自分が作成したり接続していないソケットを介して自分の資格情報を誤って転送したり、作成されたメッセージを作成者が制御したりすることが多いという問題があります。継承されたソケットの場合、setuid / setgidプロセスは親プロセスとは異なる資格情報を持ちますが、渡された資格情報はプロセスの実際の資格情報に基づいているため、親プロセスは昇格されたプロセスの資格情報を使用できません。
一方、UNIXソケットがUNIXソケットを介して渡される場合、受信者はプロモートされた実際の資格情報を持つことができます。この場合、write(2)デーモンがピアを認識しなくても、ソケットを受け取るデーモンがだまされてしまう可能性があります。
資格情報の誤用を防ぐためにどのような予防措置を講じることができますか？信頼できないソケットをデーモンに安全に渡すことはできますか？
SO_PEERCREDサービスは可能な限り使用する必要があります。- デーモンがソケットを受け取ることを意図していない場合は、
fstat(2)受け取ったファイル記述子を受け取り、タイプを確認する必要があります。 - 権限のあるデーモンは、
SCM_CREDENTIALS信頼できないソケットに送信するときに明示的にメッセージを追加し、権限のないユーザーIDを使用できます。 - サービスは、
SO_PASSCRED単純なwrite(2)資格情報が使用に有効でないことを確認するために認証します。例えば、セカンダリメッセージが必要な場合や、混乱した担当者が従う可能性が低いマルチラウンドトリッププロトコルが必要な場合があります。
一般的に使用されるデーモンはこの問題をどのように解決しますか？