How does the root user work?

mreff555 · 05-07-2013, 07:20 AM

Quote:

Originally Posted by TobiSGD

Would work also. But is lacking a feature of sudo that most people simply forget: with a proper configured sudo you can have logging which user used sudo for invoking which command, which can make things much easier for the admin.

True, I suppose logging is easier to implement.

I guess as long as you don't use a stupid password and you don't give half a dozen user full sudo access, it is fairly secure.

jpollard · 05-07-2013, 09:03 AM

Quote:

Originally Posted by suicidaleggroll

As Tobi said, secure servers are better off with a properly configured sudo. It enables users to do the operations they need without having to dig out the huge root password every time, which makes things both faster and more secure (fewer people have access to the root password, the root password doesn't need to be accessed as often, etc.). As it's set up on many systems though, with the first user created on the system having full sudo power, it is certainly less secure than without sudo though.

In my opinion, in order of most secure to least secure, it goes:
1) true root user plus properly configured sudo
2) true root user with no sudo (RHEL/CentOS default)
3) no root user and the first user account has full sudo power (Ubuntu default)

Left out one:

0) no root user plus properly configured sudo

This is possible when using good MAC rules. This seems to be the direction that Fedora is working toward.

chrism01 · 05-07-2013, 08:10 PM

The problem with no root user would be that a cracker only has to guess one passwd to get into the sudo acct, then up to root.
With a true root, you also need the root passwd (disable remote root) and any sudo is only for specific users, for SPECIFIC cmds, definitely not full root/any cmd.

btmiller · 05-07-2013, 08:40 PM

Quote:

Originally Posted by Altiris

Alright but so shouldn't all distributions when installing allow someone to set a root password and then after installation disable the account? It's better to have some type of password in there than none at all since it may be possible for a virus to enable the root user account. I see this as a major flaw in Linux right now.

You would need to have access to the root account somehow to reset the password. Since root can write anything he/she wants into /etc/shadow, someone with root access does not need to know root's current password in order to change it. If the system is already root-compromised, then all hope for security is lost. If the root account is disabled, having a root password vs. not having one doesn't particularly matter in terms of overall security.

jpollard · 05-08-2013, 06:08 AM

Quote:

Originally Posted by chrism01

The problem with no root user would be that a cracker only has to guess one passwd to get into the sudo acct, then up to root.
With a true root, you also need the root passwd (disable remote root) and any sudo is only for specific users, for SPECIFIC cmds, definitely not full root/any cmd.

There is no "up to root".

No single account has the privileges - each password only gets access to a small subset of the capabilities. Second, using a second password SHOULD cancel any privileges obtained from the first. Thus, a network admin can only configure and test the network interface - but no privileges to install software, no configuration access to apache, no configuration access DNS (unless it is also counted as part of the network), no privileges to VMs, no security privileges, no access for adding/removing users... Even if the same person does all the jobs, it requires knowledge of all the passwords.

Each role gets a different password.

The problem is that setting this up is difficult, and a generic configuration will not fit all organization structures. This is when politics of system administration meet the security models provided by vendors.

One place I worked had a network section that handled all network configurations... but they were not allowed to alter individual systems - that was up the system administrators. They did not even (at first) configure DNS for the same reason. Security administration and auditing were yet another group - and they could not add users... That was reserved for the user administrator, who could not add software - that was reserved for yet another group.

Unfortunately, the base UNIX administration role could not be separated that way (at least not at the time), so it ended up with each system having about 25 people with root for all systems. An external security audit broke that deadlock. At the time I left we were down to 5 people with root, but the class of systems was broken up such that no single system had more than 5.

The advantage was that finger pointing (or the "notme", "notme" situation) failures were reduced and the general security awareness raised.