How does the root user work?
I understand it has privileges to everything and should only be used when really needed and then logged out. However I have a couple of questions,
1. Is the root user password hashed/encrypted? 2. If the root account is disabled (like on linux mint) could a "virus" enable it? 3. If a "virus" could enable the root account, couldn't it then also set up the root password since it was never set before? |
1 = yes
2 =yes maybe 3 = yes |
Yes, the root password (and all user account passwords) is/are encrypted.
If you look at /etc/passwd, it will look, in part, something like this: Code:
root:x:0:0::/root:/bin/ksh /etc/passwd is made of of fields separated by colons; the last field contains the shell program started at log in. On my systems, I define that as KornShell rather than BASH, so it's /bin/ksh instead of /bin/bash. The other "optional user command interpreter" (that's the last one) are specified /bin/false so no one can log in to any of those user accounts (they're not really user accounts, they're for system administration). You should not fool around with any of them for any reason, by the way. Now, the second field, "optional encrypted password," contains an "x" indicating that the actual encrypted password is stored in /etc/shadow. That looks something like this (note: you must be root to see the shadow file): Code:
root:$1$a7IEQ/cm$N33kwrt.F6iuXHEKq5/NS/:15106:0::::: Anybody can read /etc/passwd (you can look at); nobody, except root, can read /etc/shadow. The permissions on those two files should never be fiddled around with for any reason. Now, about "viruses." Essentially, you want to use strong passwords: Quote:
For example, "good" passwords include upper- and lower case letters, numeric characters, punctuation characters and are at least eight characters in length (longer is even better) -- read the Wikipedia article. Viruses? Not really applicable (this ain't Windows). You protect yourself with good passwords. You should take some time and read the manual pages for passwd and shadow and, perhaps, the "See Also" references at the bottom of each of those manual pages for a better understanding of how all this works: Code:
man passwd |
From the Wikipedia link posted above..
Quote:
|
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.
|
Quote:
|
I've only tried ubuntu based, debain, and then CentOS. I think CentOS is the most secure, anyways my question is answered thanks
|
You might want to try Slackware if you want control, stability and reliability.
Oh, you will have a root account and you will be prompted to set a password for it during installation. Hope this helps some. |
Disabling root login doesn't mean that root privilages are inaccesible. This root account is still needed for other purposes than login to system, like for maintance by user. To enable root account virus or other user need to known administrator password (or somehow other method of authorization to use this account), it is irrelevant which password it would be (root or other account). Passwordless root account has other purpose, like allowing specified users to execute privilaged commands, or commands as another user, without giving them password for root, therefore full access to system.
Also you can't say "all distributions" - not all of them are multiuser (on some of them only root account exist). Also not everyone want disabled root account, it all depends on actual use of system. And for example, on Ubuntu you can choose during installation (precisely a sudo package) if you want to have disabled root account or not. |
Quote:
|
Quote:
On my desktop/laptops I keep it for convenience, for running some specific commands without the need for a password. |
Quote:
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) |
Quote:
Where I think the system becomes insecure, is that if there is more than one user able to set the root passwd, then there is now two root accounts. Twice the opportunities to compromise the system. |
Have sudon't if you don't like sudo.
Ubunbtu is getting more like windows. |
Quote:
|
Quote:
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. |
Quote:
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. |
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. |
Quote:
|
Quote:
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. |
All times are GMT -5. The time now is 10:36 AM. |