☰

sudoなしで破損したsudoersファイルを修復する方法は？

tag-icon • tag-icon linux sudo
sudoなしで破損したsudoersファイルを修復する方法は？

次のエラーが発生しますsudo。

$ sudo ls
sudo: /etc/sudoers is owned by uid 1000, should be 0
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

もちろんchown、root使用されていない場合は、sudo当社のアカウントにパスワードはありませんroot。

正直なところ、システムがどのように混乱したのかはわかりませんが、今は私が直すべき時です。

通常、回復モードで起動しますが、システムはリモートであり、通常の起動時にVPNを介してのみアクセスできます。同じ理由で、Live CDやUSBスティックから起動するのは非現実的です。

システムはUbuntu 16.04（EOLシャットダウン、質問なし）ですが、質問と回答はおそらくより一般的です。

答え1

説明された手順ここ（それ自体が不完全なコピーである可能性があります。Ubuntuの回答に尋ねる）奇跡を起こしました。ここにコピーして説明を追加します。

プログラム

  1. ターゲットサーバーへの2つのSSHセッションを開きます。

  2. 最初のセッションで、次を実行してbashのPIDを取得します。

     echo $$

  3. 2番目のセッションでは、次のコマンドを使用して認証ブローカーを起動します。

     pkttyagent --process 29824

    手順1で取得したpidを使用してください。

  4. 最初のセッションに戻り、次を実行します。

     pkexec chown root:root /etc/sudoers /etc/sudoers.d -R

  5. 2番目のセッションパスワードプロンプトにパスワードを入力します。

説明する

sudoと同様に、pkexec承認されたユーザーが他のユーザー（通常は）としてプログラムを実行できるようにしますroot。特に認証にpolkitを使用しますorg.freedesktop.policykit.exec。

これは次のように定義されています/usr/share/polkit-1/actions/org.freedesktop.policykit.policy。

  <action id="org.freedesktop.policykit.exec">
    <description>Run programs as another user</description>
    <message>Authentication is required to run a program as another user</message>
    <defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
  </action>

auth_admin管理ユーザーがこれを実行できることを示します。誰が管理ユーザーになることができますか？

この特定のシステム（Ubuntu 16.04）では、構成は次のとおりです /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf。

[Configuration]
AdminIdentities=unix-group:sudo;unix-group:admin

したがって、グループ内のすべてのユーザーがsudoそれをadmin使用できますpkexec。

最新のシステム（Arch Linux）では、次の場所にあります/usr/share/polkit-1/rules.d/50-default.rules。

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:wheel"];
});

したがって、ここではwheelグループ内の誰もが管理ユーザーです。

マニュアルページには、pkexec現在のセッションの認証プロキシがない場合は、pkexec独自のテキスト認証プロキシが使用されることが示されていますpkttyagent。実際にプロセスを最初にpkexec起動せずに実行すると、pkttyagentシステムにメッセージが表示されます。同じシェルでパスワードを入力しましたが、パスワードを入力した後に失敗します。

polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie

そうだポルケットの古いバグこれは牽引力が得られないようです。もっと議論する。

2つのシェルを使用する秘訣は、ただ解決策この質問について。

答え2

ライブ環境で起動し、そこから修正してください。

これには明らかに「物理的に同等の」物理アクセスが必要ですが（VMまたはVPSを扱う場合）、どの初期化システムを持っているかルートパスワードがあるかに関係なく、ほとんど常に機能します。

一般的なアプローチは比較的簡単です。

  1. 使用しているオペレーティングシステムと互換性のあるLive CD（または他のブートメディア）を準備します（ほとんどの場合、これはルートファイルシステムをマウントするために必要なストレージドライバとファイルシステムの特定の組み合わせをサポートするためのものです）。
  2. ブートメディアを使用して影響を受けるシステムを起動します。
  3. 影響を受けるシステムのルートファイルシステムをどこかにマウントします。
  4. ファイルを編集して保存します。
  5. 再起動。

この修正は、影響を受けるシステムのアクセス制御を完全に迂回し、必要なほとんどすべてのタスクを実行できるようにするために有効です。システムへのこのレベルの無制限のアクセスは、物理的なセキュリティが重要な理由の1つです。

このアプローチを使用している場合は、「通常の」システムで再起動したときに正しく機能させるためにいくつかの特別な作業を実行する必要があります。これはデフォルトのUbuntuインストールでは必要ありませんが、SELinux（およびIMAおよびEVMの可能性はほとんどありません）を使用している場合は、追加の起動オプションを追加し、起動したシステムでコマンドを実行してセキュリティラベルを変更する必要があります。

その人のためにするルートパスワードを使用すると、シングルユーザーモードを使用できます。

Systemdではこれを「構造モード」と呼びますが、他の人はこれをシングルユーザーモードと呼びます。これは、本質的に重要なサービスを実行する以外に、ほとんど何もせずにルートシェルから起動します。伝統的に固定に使用されています正確にこの種の問題です。

これの1つの欠点は、適切に保護された最新のシステムでは、シングルユーザーモードはパスワードで保護され、rootとしてログインする機能が必要であることです（つまり、システムコンソールへのアクセスはシステムハードウェアへの物理アクセスを意味します）しないからです。

答え3

設定を試みるたびに、sudo別のルート端末を開いたままにしておくことをお勧めします。問題が発生した場合に備えて、既に問題を解決する権限があります。

端末を開いたままにすることができない場合（例：再起動に関する実験）、ユーザーの実際のパスワードを設定してくださいroot。その後、破損している場合は、sudo単にログインしてroot（新しいコンソールを開いたり起動したりsu）システムを回復できます。

関連情報