Change root logon id

[Walt Watson]

Why doesn't UNIX allow changing 'root' to another ID (since internally its user 0 anyway)? This seems to be a simple approach to better security.

[Steven E. Protter]

Because the whole OS is structured for id zero to be omnipotent and all powerful.

Probably a bit of hard coding depending on the Unix.

I don't think your approach is going to provide better security.

Limiting where root can log on to and under which circumstances it can log on is a much better idea.

I bet Bill Hassell has a good historical take on this one.

SEP

[Pete Randall]

How isn't it allowed? You can just create a user called walt and give it a uid of 0, not that I would recommend doing so.


Pete

[Paul F. Carlson]

Sounds like security through obscurity. Having another account with a UID of 0 will raise an immediate red flag with almost any auditor.

[Walt Watson]

obscurity can be a good thing in this case. would make it much harder for someone from guessing your superuser id. auditors always ask for you to set up a real user id anyway.

I know the options are to restrict root to a console complemented by using su after logging in with a valid account.

Just want to think outside the UNIX box.

[A. Clay Stephenson]

First of all, it would provide no real increase in security because /etc/passwd must be readable to all users. All one would have to do is cat /etc/passwd and look for any other UID 0 entries. You might argue that someone logging in from outside at least knows a user name but normally long before the root password is cracked too many attempts have occurred and disabled the login.

Secondly, UNIX has decades of legacy applications that expect "root" to have UID = 0.

You should probably think outside the box on someone else's box.

[Paul F. Carlson]

HPUX already comes with proven ways to provide better security. Convert your system(s) to trusted mode, set up /etc/default/security, set up password aging, and have a written policy that requires strong passwords.

[Walt Watson]

Have already taken these other steps; all valid. One irritant is our security team's scanning software that likes to try to crack 'root', locking it out, making us to go to the data center to unlock it, etc. Exercise may be good, but it seems to happen at the least convenient times. Seems like if we could just change the logon from 'root' to 'beer' (levity intended) and obviously keeping the uid of 0, it would stop that particular irritant.
Will probably just limit 'root' to console.

[Steven E. Protter]

Some things you can't change. Unix works the way it does because it was designed to. Respectfully I disagree with the premise of your question. It is not inherently insecure because of this fact.

It is quite easy to make it impossible to do root login except for console. One entry in /etc/securetty and you are done.

Harden your system with Bastille and it will be quite secure.

Don't let the irritation get out of hand.

Unix isn't perfect.

It is quite secureable.

Obviously not in it for the points here but its you against Unix and Unix wins. If you don't like it write your own OS.

SEP

[Walt Watson]

Didn't mean to imply it was inherently insecure...heavens, no! Just wish I could make 'root' something else, but I actually can just follownig another branch...

[A. Clay Stephenson]

and moreover, can you imagine the hundreds of thousands of pages of documentation that would have to be changed if your modest proposal were implemented. and , of course, all of these documentation changes would have to be reviewed by the security auditors. Now the thought of thousands of auditors carefully checking documentation does have a certain appeal ...

[Bill Hassell · Accepted solution]

For a simple, unTrusted system, you can certainly change "root" to "nhgsd3t" and you can login. Of course, all ownership of system files and directories will be nhgsd3t. While you're at it, you can change other system usernames like bin, lp, sys, and so on. In the password file, these are simple strings. But as Clay points out, this will become a nightmare for sysadmin tasks later on.

"Security through obscurity" is no security at all. You improve security using HP-UX tools like Trusted system and Bastille and the security patch checker. Start with the Chris Wong book on HP-UX Security. It is a very bad mistake to use techniques from another version of Unix to improve security. There is just too much code underneath that is not similar.

[Walt Watson]

It was an interesting thought, but disabling 'root' except access via the console and having a validated user su to perform root functions will address the scan locking issue. Bastille is also a good suggestion.

No, don't feel like writing my own o/s any time soon ;-)