Linuxサーバーを保護しようとしており、SUIDの経験はほとんどありません。実行後
find / -perm +4000
多くのプログラムが発見されました。相反するアドバイスを見たことがあります。ここそしてここアクティブにする必要があるものとアクティブにしないでください。
SUIDが有効
/bin/su
/usr/bin/passwd
/usr/bin/gpasswd
/sbin/unix_chkpwd
SUIDが無効
/usr/bin/crontab
/usr/bin/newgrp
/bin/ping
/bin/ping6
/bin/umount
/bin/mount
/usr/bin/chsh
/usr/bin/chfn
/usr/libexec/pt_chown
/usr/bin/sudo
/usr/bin/sudoedit
/usr/bin/chage
/usr/sbin/userhelper
/usr/sbin/usernetctl
/usr/sbin/suexec
不確実な
/usr/libexec/openssh/ssh-keysign
/sbin/pam_timestamp_check
サーバーは、Linux / SFTPユーザーがほとんどいない複数のサイトをホストします。
何を変えるべきですか？また、テストはどうすればよいですか？
答え1
自分が何をしているのかわからない場合は、ディストリビューションが好きなようにしてください。この質問をするなら、あなたが十分に知らないことを意味します。だから放っておいてください。
setuid が必要なプログラムは、ディストリビューションで setuid がどのように設定されているかによって異なります。たとえば、Fedoraほとんどのsetuidの使用をsetcapに置き換えました。。たとえば、pingにはCAP_NET_RAWIOrawソケットを開く機能が必要です。これsetcap CAP_NET_RAWIOにより、権限の分離が向上したり、setuidルート（従来の方法、setcap実行可能ファイルは不要）になってソケットを取得できます。
あなたがリストしたプログラムは一般ユーザーが実行するようになっていますが、実行するには追加の権限が必要です。 setuid ビットを削除すると、システムが破損します。たとえば、ping操作が停止します（rootとしてログインしていない場合）。あなたはルートになることができますが、suルートになることはできませんsudo。これは全体のポイントを崩しますsudo。ユーザーはcrontabを設定できません。など。
専用サーバーでは、壊れたものの一部が重要ではない可能性があります。ただし、正しいことをしていることがわかっている場合にのみ、ディストリビューションのデフォルト設定を変更する必要があり、その逆ではありません。可用性はセキュリティの一部であることを覚えておいてください。サーバーにアクセスできないようにロックするか、問題を診断して解決できない場合は、セキュリティが侵害されています。
答え2
あなたがリストしたプログラムは通常安全で信頼できると見なされ、個人的には気にしません。たとえば、sudosuidビットを設定しないことは意味がありません。chsh chfnなども同じだ。本当にサーバーを保護したい場合は、次の実行可能ファイルに suid 権限を付与するだけです。
ping/ping6診断上の理由で。suexec他のユーザーとしてcgiスクリプトを実行するsuまたはsudopt_chown持っていない場合devpts
ssh-keysignホストベースの認証にのみ使用されるため、suidビットを削除できます。http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029737.html
また、ユーザーにシェルアクセス権がなく、そのディレクトリがrootとして指定されていないことを確認する必要があります。
本当にサーバーを保護したい場合は、次の点を考慮する必要があります。SELinux。
答え3
selinuxは(それがあるシステムで)多くの仕事を管理します。したがって、 selinux を使用している場合、すべての setuid エントリはそのままにして、 selinux ポリシーが提供するよりも多くの権限を持ってはいけません。