Ubuntu 14強化ガイドを読んでいますが、次の提案の1つです。
sudoグループのユーザーだけがsuコマンドを実行してrootとして機能する（またはrootになる）ことを可能にするのが賢明なアイデアのようです。
dpkg-statoverride --update --root 追加 sudo 4750 /空/数
コマンドを探しましたが、dpkg-statoverrideまだ上記のコマンドが正確に何をしているのかわかりませんか？
これは、Ubuntu 14では基本的に誰でもsudoを使用できることを意味するようです。テストするために新しいユーザーを作成し、そのユーザーとしてログインした後、sudoを試してみましたが失敗しました。大丈夫です。
それでは、上記のアドバイスの目的は何ですか？
答え1
目的は、通常のユーザーがsuコマンドを実行するのを防ぐことです（suは、sudoがコマンドを実行し、suが新しいユーザーで新しいセッションを開始し、ユーザーがシャットダウンを実行するまで続くことを除いて、sudoに似ています。 ）。
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 としてログインして実行します。セッションを別のウィンドウで開いたままにします。これにより、私が何かを台無しにして自分自身をロックしても、私が壊したすべてを修正できるログインセッションがあります。
答え2
ユーザーによっては、これは良い考えかもしれないし、悪い考えかもしれません。
一般ユーザーは、suそのアカウントのパスワードを知っている場合は、このコマンドを使用してスーパーユーザーアカウントだけでなく他のアカウントにもログインできます。
たとえば、2人のユーザーがプロジェクトでコラボレーションしている場合、そのうちの1人（ユーザーA）がログインしていて他のユーザー（ユーザーB）のみがアクセスできるファイルを読む必要がある場合に便利です。単に実行
su -c 'cat /home/userB/file' userB >file
ログインしたユーザーのホームディレクトリにファイルをコピーするために使用できますが、これはsuuserAがコマンドを実行できる場合にのみ可能です。
PostgreSQLデータベースサーバーでは、データベース管理者はpostgresデータベースサーバーの実行中に実行できないメンテナンスタスクを実行するようにユーザーに切り替えることができますsu - postgres。
このコマンドにも同じ注意が適用されますsudo（このコマンドとは異なり、より複雑です。su基本的な構成であるため、このコマンドは主にグループに役立ちます。グループsudoersはすべてのコマンドを実行できるためrootです）。定義ルールを追加した場合、すべてのユーザーが引数なしで実行できるようにするには、グループ外のユーザーに対する実行権限がupdatedb必要です。sudoerssudo
しかもsusetuidだけでなく
sg（グループパスワードが設定されている場合は、一時グループ登録が許可されます。）passwd(パスワード変更の許可)chfn(ユーザー情報の変更を許可)chsh(基本シェルの変更を許可)
そして他の何人か。これらのツールはコマンドと多くのコードを共有するため、suモードを個別に変更しても/bin/su多くの利点は得られず、すべてのツールのモードを変更すると特にpasswd。
答え3
強化されたサーバーでは、できるだけ少ないsetuid / setgidバイナリ、特に特定のツールを必要としないユーザーアカウントで実行できるバイナリが必要です。その理由は次のとおりです。
誰かの使用を監視するために、これらのツールを正確に信頼するわけではありません。セキュリティ研究者や攻撃者は、ユーザーがこれらの規制をバイパスできるようにするプログラムや依存関係でバグを見つけて積極的に見つけることがよくあります。誤った設定（su動作はPAMライブラリの設定によって異なります）が原因で同じ問題が発生する可能性があります。したがって、特定の（サービスまたはユーザー）アカウントが実行できるすべてのsetuid / setgidバイナリは、不要なルートアクセスを取得する可能性のあるベクトルです。
これらのソフトウェアの既知の問題により、パッチ/アップデートが迅速に提供されることがよくありますが、強制的に迅速にインストールすると中断が発生する可能性があります。
したがって、緊急の問題を解決する可能性を最小限に抑えるために、次のことをお勧めします。https://stackoverflow.com/questions/2189976/find-suid-and-gid-files-under-rootその後、それらを削除できるかどうかを調べます（主に専用サーバーを実行していて実行していることがわかっている場合）。これらの変更を永続的に維持するには、パッケージ管理システムでサポートされているdpkg-statoverrideなどの方法を使用することをお勧めします。
従来のNFSの特定の設定で「su」へのアクセスを制限する別の理由があります。本質的に政治的な理由でルートアカウントに制限がある可能性があります（一部のユーザーは政治的な理由でアカウントにアクセスする可能性がありますが、これはうまくいきません）。練習）suはNFSマウントのroot_squashフラグをバイパスするので簡単です。