Why sudo? What is the best practice for administration?

[pacemkr]

I'm a new FreeBSD user.

One of the things that always perplexed me with Linux distributions is the use of sudo. I kept hearing that sudo is better than using root, but it never made sense to me.

People give ALL access to wheel group, then add "myuser" to wheel. Then use myuser to administer the box using sudo. The whole thing feels like security theater to me. You are effectively root in that account. How is this more secure than just logging in as root to administer the box? What benefit of sudo am I missing? Wouldn't it be installed out the box with FreeBSD if it was "the better way?"

I'm planning to use fabric to automate some setup tasks (installing software, configuring the system, etc) and I intend to use the toor account for this. ie. I login as toor using SSH and then Fabric takes over. Is this a reasonable "FreeBSD-approved" (is there a word for this? similar to Pythonic?) way of doing things?

 

[DutchDaemon]

Logging in as the root/toor user over SSH is severely frowned upon in FreeBSD land, and if you have to (i.e. for automated remote administration tasks or backups), use key-based authentication methods, never passwords. Other than that, log in as a user belonging to the wheel group, and su to root once logged in. I never use sudo for my own admin tasks. I only use sudo to give another user on my systems a limited amount of elevated privileges, e.g. for rebooting or shutting down a system, stuff like that (never ALL).

 

[pacemkr]

It's all keys for me. Curiously, disabling SSH access to root and setting up a user that I can su from is the first thing I do on a fresh install of Debian. It seems that this practice is something that I can (and should) carry over to FreeBSD.

Your post made me reconsider using toor as the user that I connect with in fabric. I now realize that I can connect using a normal user and issue 'su toor' as the first command in each fabric task that requires root privileges. I also like the explicit and self-documenting nature of this approach. Win win.

As for sudo, it seems that my suspicions are correct. Using sudo with ALL privileges makes no sense. In my experience, sudo has always been described as "run something as root." Perhaps that's the source of my identity crisis. "Run something with a limited amount of elevated privileges" is a much better description. I wish people used this later description more often.

Thank you.

 

[phoenix]

The big difference between 'login as root', 'su to root', 'sudo -s to root', and 'sudo specific commands only' is logging.

A straight login as root puts one entry in the auth.log. Nothing you do after that is logged.

A su to root also adds a single entry to the auth.log. Nothing you do after that is logged.

'sudo -s' is no better than 'su -' other than the log entry is more verbose.

However, if you disable root logins via the network, disable the use of su, and limit sudo access to only those commands specific users need, then you get a very nice audit trail. Every invocation of sudo logs the date/time, user calling sudo, command, and user command ran as.

Properly configured and used, sudo is a great security tool following the principle of least privilege.

And the fewer people who know the actual root password, the better.

 

[pacemkr]

I appreciate the details. Proper use of sudo does make sense, especially in the context of having an audit trail. I'm assuming this benefit is null and void once you grant ALL, since the attacker can just go in a edit the logs.

Principle of least privilege is it.

My confusion arose from years of seeing sudo being misused. I mean here is first Google result for "enable sudo".

%wheel        ALL=(ALL)       ALL
usermod -G wheel -a john

This is the thing not to do! Yet, all the materials that I have ever seen regarding sudo -- clearly not a deep enough search on my part -- has suggested doing exactly this.

In my last Debian install I opted not to use sudo at all. I think I'm going to stick to this practice until I have a legitimate reason to use the tool properly.

 

[fluca1978]

There is also another consideration: root (and toor) are well known account usernames. With well known I mean that are accounts you know always exist on a machine, and therefore you can attack via brute force. Having to know that your-strange-username has administrative power is more difficult to guess.
Having said that, sudo also allows you to fine tuning which permissions are going to release to specific users. I've got users that are not going to administer the whole machine but that are able to administer some services.

 

[andyzammy]

There is also another consideration: root (and toor) are well known account usernames. With well known I mean that are accounts you know always exist on a machine, and therefore you can attack via brute force. Having to know that your-strange-username has administrative power is more difficult to guess.
Having said that, sudo also allows you to fine tuning which permissions are going to release to specific users. I've got users that are not going to administer the whole machine but that are able to administer some services.

This brings up an interesting question - is it possible to change the root account name?

 

[anomie]

What benefit of sudo am I missing?

If you're in an environment with multiple sysadmins (all of whom are expected to have root-level privileges), using security/sudo buys you two things:

1. An audit trail
2. A simple account lockout if/when a sysadmin leaves

As for point #1, ongoing monitoring is required. If you find folks are using security/sudo to get a root shell, there needs to be a policy (formal or informal) to discourage it.

As for point #2, you really don't want to have to change root's password on a few dozen (a few hundred?) servers every time turnover occurs.

---

Actually, security/sudo has some additional, more obscure benefits that I utilize for service accounts that only need to perform a single task (of many tasks) with elevated privileges.

 

[anomie]

This brings up an interesting question - is it possible to change the root account name?

Yes, but don't do it. It is not easy to know how many applications are testing for an account name rather than a UID.

 

[kpa]

Yes, but don't do it. It is not easy to know how many applications are testing for an account name rather than a UID.

Also it wouldn't bring any more security if access to root account is otherwise controlled properly. Another point is that attacks that target bugs in setuid programs do not need to know the account names that have uid 0 to succeed.

 

[fluca1978]

This brings up an interesting question - is it possible to change the root account name?

It is, but it will cause more problems than advantages: some applications are using the "root" name, others are using the 0 UID so you are going to break your system sooner or later.