I know that chmod -R 777 / is extremely destructive, and I know that a chmod -R 000 /bin can be recovered by using an additional disk, but I'm wondering about chmod -R 777 /bin.
If I have a root shell, but no additional disk mounted from a healthy VM, can I recover this system?
(This question is for learning purposes as the actual box is not mine, nor was the mistake, and the box is already planned to be rebuilt.)
As argued in the response you link, it depends on your definition of "recover" (i.e. do you still trust a binary after it was potentially changed by anybody on the system, which may be "I guess I'm ok" for your private desktop machine but much much less so on a multi-user company system).
Looking at my box, /bin has a manageable number of files that aren't 0755 or symlinks:
ls -l /bin/ | grep -v '^-rwxr-xr-x' | grep -v '^l' | wc -l
35
and that's mostly because they're setgid or setuid. So in principle, you could chmod 0755 /bin/* and manually fix the permissions on those 30, 40 binaries, if you still have root access. (su and sudo won't work until their proper permissions are restored.)
But for practical purposes, that still means you need a "clean" machine somewhere for comparison purposes, but you don't need to mount its drive.
(Come to think of it, I don't think wrong permissions on the binaries should stop the package manager from working, so you could conceivably try reinstalling every package that has something in /bin, but probably most everything has a dependency on something in /bin, so you might end up removing and reinstalling all packages.)
On my mint system all the files in /bin are 0755 except fusermount, mount, ping, ping6, and su, which are 04755.
0755 is a reasonable permission mask for a shared executable. Which executables are setuid will depend very much on your system's security policies.
Trying:
chmod -R 0755 /bin && chmod 04755 /bin/{{,fuser}mount,ping{,6},su}
(as root) can do little harm at this point (setting setuid root on anything is a potential vulnerability).
