How to restore a broken sudoers file without being able to use sudo?

Question

I'm getting the following error from 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

Of course I can't chown it back to root without using sudo. We don't have a password on the root account either.

I honestly don't know how the system got into this mess, but now it's up to me to resolve it.

Normally I would boot into recovery mode, but the system is remote and only accessible over a VPN while booted normally. For the same reason, booting from a live CD or USB stick is also impractical.

The system is Ubuntu 16.04 (beyond EOL, don't ask), but the question and answers are probably more general.

Answer 1

The procedure described here (which may itself be an imperfect copy of this Ask Ubuntu answer) performed the miracle. I'm copying it here, and adding some more explanations.

Procedure

1. Open two SSH sessions to the target server.

2. In the first session, get the PID of bash by running:

    echo $$
   

3. In the second session, start the authentication agent with:

    pkttyagent --process 29824
   

   Use the pid obtained from step 1.

4. Back in the first session, run:

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

5. Enter the password in the second session password promt.

Explanation

Similar to sudo, pkexec allows an authorized user to execute a program as another user, typically root. It uses polkit for authentication; in particular, the org.freedesktop.policykit.exec action is used.

This action is defined in /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 means that an administrative user is allowed to perform this action. Who qualifies as an administrative user?

On this particular system (Ubuntu 16.04), that is configured in /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf:

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

So any user in the group sudo or admin can use pkexec.

On a newer system (Arch Linux), it's in /usr/share/polkit-1/rules.d/50-default.rules:

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

So here, everyone in the wheel group is an administrative user.

In the pkexec manual page, it states that if no authentication agent is found for the current session, pkexec uses its own textual authentication agent, which appears to be pkttyagent. Indeed, if you run pkexec without first starting the pkttyagent process, you are prompted for a password in the same shell but it fails after entering the password:

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

This appears to be an old bug in polkit that doesn't seem to be getting any traction. More discussion.

The trick of using two shells is merely a workaround for this issue.

Answer 2

Boot into a live environment and fix it from there.

This obviously requires either physical access of ‘physical-equivalent’ access (if dealing with a VM or VPS), but it almost always works, doesn’t care about what init system you have, and does not care about whether or not you have a root password.

The general approach is relatively simple:

1. Prepare a live CD (or other boot media) that is compatible with the OS you are using (mostly, this just comes down to supporting the particular combination of storage drivers and filesystems needed to mount the root filesystem).
2. Boot the affected system using that boot media.
3. Mount the root filesystem of the affected system somewhere.
4. Edit and save the file.
5. Reboot.

This kind of fix works because it completely sidesteps the access controls of the affected system, letting you do pretty much whatever you want. This level of unrestricted access to the system is part of why physical security is so important.

Note that if taking this approach, you may need to do something special when rebooting back into the ‘normal’ system to make things work properly. On a stock Ubuntu install this should not be needed, but if you’re using SELinux (or even less likely, IMA and EVM), you may need to add extra boot options and then run a command from the booted system to fix security labels.

---

For those who do have a root password, just use single-user mode.

Systemd calls this ‘rescue mode’, but everyone else just calls it single-user mode. This essentially boots to a root shell with almost nothing but critical services running. It’s traditionally used for fixing exactly this type of issue.

The one downside to this is that on any properly secured modern system, single-user mode is password protected and requires being able to log in as the root user (the reason for this being that access to the system console does not inherently imply physical access to the system hardware, so some authentication should be used).

Answer 3

Whenever you plan to experiment with sudo config, it's a good idea to keep another root terminal open: in case you break something, you will already have the rights to fix it.

If it's not possible to keep a terminal open (e.g. your experiments involve a reboot), set an actual password for the root user. Then if sudo is broken, you can simply login as root (open new console or run su) and fix you system.