There’s a fine line between empowerment and impotence in Unix. Is that why it sounds like eunuchs?

I accidentally revoked my power to run the sudo command. Yeah, it was a dumb thing to do. With godlike power comes great responsibility, and there I was like some half-wit sticking a fork in an electrical outlet. I realize the need to be careful as root in Unix systems, and in the case of Ubuntu when running sudo, but still: oops.

Maybe I was lured to incaution by the rapid typing of commands while trying to get something working, in this case: TrueCrypt. I had set the SUID bit on it with sudo chmod u+s /usr/bin/truecrypt so that a regular user could run the program, but I was concerned about security issues.

I find that in both Windows and GNU/Linux, people are quick to suggest and try things that make the systems less secure in order to get things working. Or maybe it’s that Windows starts weak by default in order to make it more “user friendly,” and free software enthusiasts who sneer at the vulnerabilities in Windows are often quick to throw out the hard stuff for convenience anyway. In either case, I don’t want to get in the habit of sacrificing security for the first workaround or kludge that makes something work as desired.

As I start learning about setuid and setgid, I’m leery of latching on to them too quickly. In the case of TrueCrypt, a little poking around revealed that it had a SUID vulnerability in a recent release. It was fixed, but it reinforced my concerns. Better to avoid that avenue of attack altogether if possible.

I was reminded while searching around that sudo can be used instead to limit rights for a program more specifically, which led to looking at the sudo executable and the sudoers file and so on. After getting sudo thoroughly on the brain, I went to change permissions for truecrypt back to the default 755, but typed sudo chmod 755 /usr/bin/sudo.

It took a few moments and follow-up commands for it to sink in what I had done. The great depths of stupidity to which I had suddenly plummeted. It’s kind of like a car accident or slipping and falling on ice and breaking a leg. One moment you’re going about your day with thoughts of more pleasant things to come, and the next, you’re hosed. One mistake, one mix-up, and now you have something for which you’re going to have to suffer the consequences for awhile.

Fortunately, it turned out to be more like locking my keys in the car and having my own Slim Jim at hand.

But for a couple of minutes there was an almost delicious sense of regret and fear. I’m starting to find my way around the labyrinth, but I’m not especially confident about my ability to avoid the minotaur. I know he’s in there, waiting to devour careless seekers like myself. No matter how much I willed it to be so, there was no way I could undo the mistake and change the permissions back. I tried su and was presented with a password prompt, but never having set a root password, it was hopeless. That one file is kind of important for administering the system.

Getting to the exciting conclusion of this misadventure, I searched for [ubuntu sudo permissions] and the first result, Troubleshooting Sudo, had this promising Google excerpt: “How can I edit the /etc/group file if I don’t have sudo permissions?” My problem was easier than the one covered there, but I learned how to get in to recovery mode at startup time, and from there it was simple to fix the sudo file permissions as root. Phew! What a relief.

It was disturbing to me that it was so easy to get in to the system as root, with no password required. I’ve heard that there are plenty of ways to compromise a system if you have physical access to the box, even if the root password is set, but it goes against my comfort zone so I set the root password. I’ve seen warnings about enabling the root account, but so far so good. I don’t see what the problem of having a password on there could be. Maybe someone can enlighten me?

A final note: the Ubuntu project has a nice page about its use of sudo and associated pros and cons.