ssh-agentにsgidビットがある理由を理解しようとし、この記事を見つけました。ssh-agentにsgidがあります
別の質問があります。なぜssh-agentのグループ所有権がroot以外の人ですか？その理由は何ですか？グループの所有権がルートであっても引き続き機能しますか？
答え1
setgid rootの場合、エージェントはroot起動されたユーザーよりも広い権限を持つグループとして実行されます。これは、少なくともセキュリティリスクになる可能性があります。不必要に root で何かを実行するのは危険の兆候です。（グループでも）特別な注意が必要です。
グループ所有権をに設定しますnobody。グループには意味のある権限や添付ファイルを含めないでください。ssh-agentユーザーが開始したよりも多くの権限を取得できない。リンクされた質問が示すように、実際には他の権限が必要なためではなく、最初からトラッカーを防ぐように設定されています。内部に別の質問でリンクされたディスカッションスレッド、ある開発者は次のように言及しました。
このグループは影響力がほとんどないようです。バイナリがanygroupに設定されていることが重要です。
nobodyこの便利なグループは、アクション自体ではなくsetgidの副作用だけが必要な場合に使用できます。
私はそれがsetgidルートで動作し続けると思います。ここで試してみましたが、まったく文句を言わず、おおよそのテストではうまくいったようです。つまり、そのような形に変える実用的な理由は思い出されません。誰もがnobodyグループよりもグループの形でうまくいくようですroot。
いずれにせよ、パッケージマネージャがインストールしたファイルの権限を変更しないことをお勧めします。なぜなら、パッケージマネージャは自分が制御するファイルを変更するのが不便になる傾向があるからです。
答え2
setgidを設定する目的ssh-agentは、同じユーザーで実行されているプロセスでもメモリからキーをダンプできないようにプロセスをデバッグできないようにすることでセキュリティを向上させることです。
ssh-agent実際には追加の権限があってはなりません。に脆弱性がある場合は、ssh-agentグループに設定すると、ユーザーにそのグループに対する権限が付与されます。したがってssh-agent、setgidを実行するとセキュリティリスクが高まります...実行中のグループにssh-agent実際に権限がない場合、特にファイルへの書き込みアクセス権がない場合は例外です。
他のプログラムに影響を与えずにsetgidプログラムを実行する最良の方法は、プライベートグループを使用することです。たとえば、Debian が何をしているのかがssh-agentグループとして実行されますssh。 Fedoraはグループを使用しますnobodyが、これはより危険ですが、どのファイルもグループに属してはいけませんので、それでも問題ありませんnobody。このグループはroot多くのファイルを保持しているので、悪い考えです。