dpkg-statoverrideでsuを強化する方法は？
私はUbuntu14強化ガイドを読んでいますが、これは提案の1つです。
ルートとして機能する（またはルートになる）ために、Sudoグループのユーザーのみがsuコマンドを実行できるようにすることは一般的に賢明な考えのようです。
dpkg-statoverride --update --add root Sudo 4750 /bin/su
dpkg-statoverrideコマンドを調べましたが、それでも上記のコマンドが何をしているのか正確に理解できませんか？
Ubuntu14ではデフォルトで誰でもSudoを使用できるようになっているようです。テストするために、新しいユーザーを作成し、そのユーザーとしてログインし、Sudoを試行しましたが、失敗しました。これは良いことです。
では、上記の提案の目的は何ですか？
目的は、通常のユーザーがsuコマンドを実行できないようにすることです（suはSudoに似ていますが、Sudoが1つのコマンドを実行し、suが新しいユーザーとして新しいセッションを開始し、そのユーザーがexitを実行するまで続きます）
Suのデフォルトモードは4755またはrwsr-xr-xで、「s」はコマンドがset-UIDであることを意味します（つまり、コマンドを実行するユーザーではなく、常にコマンドを所有するユーザーとして実行されます。この場合、suはrootが所有しているため、常にroot権限で実行されます）
suには、それを実行するユーザーが別のユーザーになる権限を持っていることを保証するための独自のセキュリティ対策があります（通常は他のユーザーのパスワードを要求することによって）が、攻撃者を許可するセキュリティの脆弱性がsuに存在する可能性がありますどういうわけか、権限なしで何か他のことをするように説得します。
モードを4750に変更することで、通常のユーザー（root以外のユーザーとSudoグループのユーザー）がそもそもモードを読み取ったり実行したりできないようにするため、攻撃者はそのファイルの所有権を変更するか、変更する必要があります。ファイルのモード、またはsuのこの理論上の脆弱性を悪用しようとする前に、独自の有効なUID/GIDを変更します。
Dpkg-statoverrideコマンドは、新しいバージョンに置き換えられた場合でも（つまり、aptアップグレードを介して）、そのファイルの所有権/モード値を使用するようにパッケージマネージャーに指示するため、この場合に役立ちます。言い換えれば、それは単なるchownとchmodよりも永続的になります。
このインスタンスに推奨する汎用の戦術は次のとおりです。Linux/ UNIXマシンでsu/Sudoまたは認証コンポーネントの構成を微調整するときはいつでも、そのサーバーに対して別のssh/PuTTYセッションを開き、次のようにログインします。 rootユーザーであり、そのセッションを別のウィンドウで開いたままにしておきます。そうすれば、何かを台無しにして自分自身を締め出す場合、私はすでにログインセッションを持っており、そこで壊れたものを修正することができます。
ユーザーに応じて、それは良い考えかもしれませんし、悪い考えかもしれません。
suコマンドは、アカウントのパスワードを知っていれば、スーパーユーザーだけでなく他のアカウントにログインするために通常のユーザーが使用できます。
これは便利です。 2人のユーザーがプロジェクトで協力している場合、一方（userA）がログインしており、もう一方のユーザー（userB）のみがアクセスできるファイルを読み取る必要があります。単に走る
su -c 'cat /home/userB/file' userB >file
ログインしたユーザーのホームディレクトリにファイルをコピーするために使用できますが、これは、userAがsuコマンドの実行を許可されている場合にのみ可能です。
PostgreSQLデータベースサーバーでは、通常、データベース管理者がpostgresユーザーに切り替えて、データベースサーバーの稼働中は実行できないメンテナンスタスクを実行することができます。これが機能するためには、su - postgresを実行できる必要があります。
同じ考慮事項がSudoコマンドにも当てはまります（これはsuとは異なり、はるかに複雑です。このグループはsudoersとして任意のコマンドを実行できるため、コマンドを主にrootグループに役立つようにするのはデフォルトの構成のみです。 、カスタムルールを追加する場合、たとえば、任意のユーザーが引数なしでupdatedbを実行できるようにする場合、sudoersグループ外のユーザーには、Sudoに対する実行権限が必要です。
また、setuidであるsuだけでなく、
sg（グループパスワードが設定されている場合、一時的にグループに参加できます）passwd（パスワードの変更を許可します）chfn（ユーザー情報の変更を許可）chsh（デフォルトのシェルを変更できます）
と他のいくつか。これらのツールはsuコマンドと多くのコードを共有するため、/bin/suのモードを変更するだけではあまり購入できません。また、すべてのツールのモードを変更すると、特にpasswdの場合、ユーザーを苛立たせることになります。
強化されたサーバーでは、setuid/setgidバイナリをできるだけ少なくする必要があります。特に、特定のツールを必要としないユーザーアカウントで実行できるものは、1つの単純な理由からです。
あなたは、誰かがそれらを使って何をするかを監視するためにこれらのツールを絶対に信頼しているわけではありません。ユーザーがそのようなポリシングを回避することを可能にするそのようなプログラムまたはそれらの依存関係のバグは頻繁に発見され、セキュリティ研究者および攻撃者によって積極的に求められています。設定ミス（suの動作はPAMライブラリの設定に依存します）は、同じ問題を引き起こす可能性があります。したがって、特定の（サービスまたはユーザー）アカウントが実行できるすべてのsetuid/setgidバイナリは、不要なルートアクセスを取得するための潜在的なベクトルです。
このようなソフトウェアの既知の問題により、通常、パッチ/アップデートがすぐに利用可能になりますが、それらを迅速にインストールすることを余儀なくされると、混乱が生じる可能性があります。
したがって、緊急の問題を解決する可能性を最小限に抑えるには、次のようなことを行うのが理にかなっています https://stackoverflow.com/questions/2189976/find-suid-and-gid-files-under-root =次に、これらのどれを取り除くことができるかを調査します（専用サーバーを実行していて、何をしているのかを知っている場合はほとんどです）。できれば、パッケージ管理システムがそのような変更を維持するためにサポートするdpkg-statoverrideなどのメソッドを使用します。パーマネント。
古い学校のNFSを使用した特定の設定で、「su」へのアクセスを制限する別の理由があります。本質的に政治的な理由で、rootアカウント（一部のユーザーは政治的な理由で取得する可能性があります。それでも悪い習慣です）の使用を制限する場合があります。これは、NFSマウントのroot_squashフラグを回避するためです。