This is a theoretical question. What if I run those commands with correct privileges? How could I restore su and sudo?

  • 1
    If you deliberately cut off all your paths to root privileges, sometimes the only way to recover is to boot a rescue system and/or even reinstall. – frostschutz Sep 17 '17 at 20:02
  • Reinstall is the most obvious solution to just about everything. – Weylyn Savan Sep 17 '17 at 20:14
  • 2
    @frostschutz But they do not disable init=/bin/bash – Hauke Laging Sep 17 '17 at 20:40
  • 1
    Why the downvotes? I think it would be a useful question to ask oneself. How can I get in?. Personal story: some years ago I forgot the keys to my summer home in my home town, 300 km distant. The spare keys were inside the home. Desperation was enough that I came up with a nondestructive way of burgling the house and fetching the keys, a way that had been available to any observant burglar for the three years past. In those three years I had been lucky. – LSerni Sep 17 '17 at 20:40
  • 1
    @HaukeLaging They don't need to disable it. It's automatically disabled once you use initramfs. But of course the initramfs or init system may choose to deliberately re-implement the same functionality. While speaking of initramfs, it might have its own criteria for dumping you to a root shell. But some people strive to prevent those too ( silly example hmarco.org/bugs/CVE-2016-4484/… ). – frostschutz Sep 17 '17 at 21:05

Neither of these binaries are required to reinstall the packages - so you simply need to gain root access and reinstall the packages containing those binaries with apt, yum or what ever package manager your system uses - there should be no need to do anything more dramatic then that.

The trick is gaining root access. This is trivial if the root account is unlocked and you know the password (which if you were using su then you do). At which point just log into the system as root and reinstall the packages.

If you do not have root access then you can try to reboot into recovery mode if your distro has that enabled - if so it will give you a root prompt which you can reinstall the required packages.

If you cannot get recovery mode to work or it is not enabled then you need to boot a live cd. Once booted with a live cd you can mount the root filesystem of your system somewhere, chroot into it and reinstall the packages that way. Such as:

cd /location/of/new/root
mount -t proc proc proc/
mount --rbind /sys sys/
mount --rbind /dev dev/

cp /etc/resolv.conf etc/resolv.conf

chroot /location/of/new/root /bin/bash

# <install packages here>

Log onto console as root, scp the /bin/su and /usr/bin/sudo from a "known, good" neighboring server.

  • And how to do that? This is the first time I heard of scp and a quick looking at its manpage doesn't explain it to me. – Weylyn Savan Sep 17 '17 at 20:10
  • 2
    @WeylynSavan If this is the first time you heard of scp then you probably should not bother with this kind of theoretical problems anyway. – Hauke Laging Sep 17 '17 at 20:37
  • Okay. I was just curious, because Joel Lee, who written '9 Lethal Linux Commands You Should Never Run' forgot to mention how to fix the system if someone was dumb enough to run any of those commands. At least in case, there's something left to fix. Unlike after mv / /dev/null or command > /dev/hda. – Weylyn Savan Sep 17 '17 at 20:53

If root access is available via SSH, then restore the binaries from another server (or upload the two files from the latest backup - you did backup your system, didn't you? - on any suitable server and download them from there):

ssh root@woundedserver "cd /usr/bin; wget http://myamazonserver/files/su; chmod 4755 su"


scp /usr/bin/su root@woundedserver:/usr/bin
# I never remember whether scp preserves permissions, so just to be sure:
ssh root@woundedserver "chmod 4755 /usr/bin/su"

or even (I just tried, the md5sums match after the copy)
cat /a/good/su/binary | ssh root@woundedserver "cat >/usr/bin/su; chmod 4755 /usr/bin/su"

If root isn't allowed to SSH in, or you disabled that possibility or closed the SSH port too, I suspect the only way is booting with the init "hack", or boot from a rescue CD. That ought to work.

If you also secured GRUB and maybe encrypted the filesystem, either wait for an exploitable vulnerability to be discovered, or reinstall everything from the latest backup. You did backup your system, didn't you? :-)

  • Backup? What is a 'backup'? :-) – Weylyn Savan Sep 17 '17 at 20:17
  • 1
    In my native language I could make a lewd pun, but let's say it's the thing that saves your back :-) -- and saved mine, more times than I choose to remember - shudder – LSerni Sep 17 '17 at 20:19
  • Of course, I know what it is. But let's pretend like most users, I don't have one either. Now what? Would downloading sudo's deb from the repo and installing it "somehow" work? – Weylyn Savan Sep 17 '17 at 20:22
  • Yes, I don't see why not. To be safe, you would need the same distribution, then you would upload with any tool available. – LSerni Sep 17 '17 at 20:34
  • Well just before rebooting for e.g. the initrd "hack", I can open any installed browser and google on package sudo distro_codename, and download the one with the correct architecture. After "hacking" into my own system, I can simply install it with dpkg -i. – Weylyn Savan Sep 17 '17 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.