http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474024

If you are trying to break into a remote computer, with most Linux systems, you can guess that the root account is “root”, but with Ubuntu, not only do you need to know/guess the password, but you also need to know/guess the account name that has the sudo privileges. That would seem to me to be an additional layer of security.

To me, having millions of computers all with the root username of “root” just seems to be a huge security hole waiting to be exploited.

Enterprise Implementations:-
sudo has its place for allowing access to a limited number of resources to different line(s) of support staff.

Root user should be a very secure password if it is enabled and and ever used.

Id like to know more about the traps and logger out to syslog, cause I think this is normally a very grey area (and seen some ways to do it but none what Id want to deploy).

A lot of us cringe at the thought of generating multiple user accounts, but under certain high-level administration circumstances, and with proper configuration, especially when regulatory needs in the mix, it makes quite a bit of sense.

Ubuntu providing sudoer accounts on *home desktops* by default is a problem at all. The truth is, for most people that’s perfectly fine, even on those “other” OSes (OSX does it too). The problem is when these same ideologies are applied blindly to enterprise implementations. When they are it’s either a result of poor training or pure lazy sysadmining.

Sudo is another case of “it’s not the tool, it’s how you use it”. Sudo has it’s place, and until a replacement is fleshed out, it is necessary as has been stated. You just have to know exactly what its use means before building your implementation.

OK. What are the differences?

(Yes, I have looked at the man page. I see that there is some difference with the way sudo -i handles some environment variables compared to the other two commands. I think.)

Substituting a wrapper script for sudo where sudo has a timeout is a way of getting root transparently:
http://mihaiv.wordpress.com/2009/07/17/security-issues-with-sudo/

I was speaking strictly of the sshd config. *If* you have set a root password, the default sshd_config allows root to authenticate with a password.

Sysadmins who read their man pages will run “sudo -i” to do their work from a root shell.

They can brute force all they want, but it does nothing. If you have something like denyhosts running, it means it’s all but impossible to ‘get in’ via SSH when this is configured.

Regarding sudo – I can see it’s use as a general replacement for ‘su’ in the case it is configured to require the root password. However, if the user is compromised and a keylogger is running, what difference does it make if it’s a root or user password that gets captured? The attacker still gets his/her path to root. In either case, they can’t go straight for the money in /etc/shadow, they HAVE to capture you type it. Whether you type your own password or the magical root password is not really relevant.

Desktop users shouldn’t need root access. The GNU/Linux desktops seem to be building on top of the same broken desktop security model that has plagued Windows. Users are expected to grant desktop software installation scripts root access (assuming they use the bundled packaging system) and to grant software read-write access to all their user data. It shouldn’t be necessary (it isn’t on Android).

I do understand sudo quite well, and I realize it is highly configurable. I was mainly trying to get one point across in the article: “using ALL(ALL) is considered harmful.”

Most sudo implementations, even at the large IT organization level, do this.

mpt: I didn’t say I’ve never seen mistakes cause damage, but I don’t believe they are the *big* problem. And writing down passwords is not a problem. I’ve written about that topic before, but I defer to the real expert: http://www.schneier.com/blog/archives/2005/06/write_down_your.html

We use traps and logger to log all commands to syslog channels and then also remotely log to a syslog server which is mined using spelunk. We notifications about what users do what, how and where. Using sudo is nearly bone stock required period for PCI-DSS.

If the traps are disabled, we get notifications as well.

I’ve become quite the su purist. Even PolicyKit bothers me. There are a few things in which I believe users should have access, like wireless roaming. Other than that I see no reason for regular users to be given access to the system.

Its just asking for trouble.

No I should just sit back and wait for the flames from the sudo camp.

I think really need to go through the sudoers configuaration file properly.And understand what it says.

You can restrict ordinary users many ways(SELinux is best possible thing)..but can restrict users to some specific command bunch.

So they cannot fire whatever they want at their will.

I want you investigate more on this topic then posting you comment.

In the enterprise the security story is quite different.There will be “ring” of security not just one method deployed.

Moreover security is an constant process…just cannot be left behind.You will be always on your toes to get along with it..otherwise chances are high to be get compromised.

Cheers
Bhaskar

If you haven’t seen human errors as a problem, then well done for being unusually careful. But even ignoring safety, any extra security from having a separate root account with its own password may be outweighed by the increased probability of people needing to write down both their passwords to remember them.

As for having “users” separate from “sysadmins”, that distinction may make sense for medium-to-large organizations, but it makes scant sense for home use. And it will, I hope, make little sense for organizations 20 years from now too: vendors who assume that computer systems will always need constant “administration” will eventually get beaten by competitors who dare to imagine otherwise.