How do you rename root?

Question

Not that it's a very good idea to change it, but for fun. According to this post, there are still some problems even after changing entries in /etc/passwd, /etc/shadow, and /etc/sudoers. Any suggestions?

Answer 1

Theoretically, changing it in /etc/passwd and /etc/shadow would be all you need to 'rename' root. The problem occurs because pretty much every single piece of Unix software in existence assumes that the username 'root' exists and that it is the superuser -- mail aliases, various daemons, cron...

If you're really hell bent on trying it, find /etc -type f -exec grep -l root {} + should be a good start at finding a list of every config file you'll probably need to change - but like you already said, this is a really bad idea in almost every conceivable situation.

EDIT Another thought -- if you haven't already (which you should have), make sure that /etc/aliases contains an entry for root and a username that exists or an email address that evaluates correctly. A lot of automated systemwide tasks (cron for instance) send their output by email to root, which is traditionally aliased to the systems administrator(s) responsible for that system's operations.

Answer 2

All this fear mongering, saying "Don't do it!" is ridiculous. At one time, yeah, it probably did break lots of badly written scripts, but I suspect those are not so common any longer; at least not in the standard distributions.

We've been told to rename the root account on a subset of linux servers. So, after attempting to research how to go about doing this correctly, I, instead found many, many posts saying "Don't do it!" with lots of dire warnings of "bad stuff" happening if you choose to do this. But, I have yet to find any with concrete examples of the "bad stuff" that could happen.

So, let me back up and explain where I am, and how we got here. We're building a PCI compliant environment, and one of the tools that helps us meet those "requirements" is telling us we need to rename the root and administrator and guest accounts to something else. For those uneducated about PCI, you have the option of either following the guidelines or documenting why you either can't or choose not to follow that guideline, and what mitigating strategy you have to keep the systems safe. So, I imagine most places document why they aren't going to rename their root accounts, however, our group has decided that, if we can rename the windows administrator accounts without problem, were going to rename the linux root accounts as well.

I am well versed in the "security through obscurity" arguments; I know just changing the root account name doesn't actually improve security by a lot, root should be disabled at SSH, etc. I know, that's not the point, I'm not interested in hearing more. I'm also not interested in more "the sky will fall" warnings. I'm looking for statements like this: ">this bad thing< will happen with >this standard package< (unless you >do this<)".

So far I have 3 CentOS (RHEL) systems that apparently have no issues with renaming the root account. Here's what I did: I changed the account name in /etc/passwd, /etc/shadow, /etc/group, and /etc/gshadow. Then grepped for the name root in /etc/ and modified the postfix aliases file so that root was an alias to our new account name, call it rojotoro. (Something similar should be done for other email systems). I also found that I needed to change some configurations for logrotate when describing who should own the files it would create automatically. And that has been all I have changed thus far.

I've looked at many init.d scripts, but haven't changed anything, and everything appears to start just fine at boot. I have to specify the new account when using sudo: "sudo -u rojotoro vim /etc/passwd" as an example, but I didn't actually need to change anything within the sudoers file. I expected maybe some issues with selinux which we have on and enforcing, but thus far I've not needed to touch that system.

I can also see that mkdev or mkfs scripts may need to be adjusted, but I don't plan on using those, so I haven't looked at them with the scrutiny they deserve.

If it truly is this easy to change with no ill effects on an selinux enabled system, why the continuation of all the fear mongering?

Answer 3

To my mind, the easiest thing to do is to create a new user (alias), with UID 0 and /root as home.

Why don't you switch your root's default shell to /bin/false or /sbin/nologin (so no one can login to it, but the system still use it) and login to the new alias created?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

If you change root's shell to nologin, the sudo, mail or ftw will not be damaged.

Answer 4

suggestion: do not do that.

Some tools try to talk to root via uid, there you should not have problems. some tools assume your root account is called root, and will break. unless you are prepared to, like, recompile half your system "for fun", just don't try.

Answer 5

Linux is not Windows and root can not currently be renamed easily without creating unknown future problems.

Disabling remote and even local login as root is a safer approach because it actively disables the account root! UBUNTU essentially does this and forces sudo instead of root access.

Essentially no one can use the root account to attack your system since it no longer can be used to login to the system!

It would be nice if a standard way was created to easily modify both the root account name as well as randomly generating its UID upon installation and if ever possible upon every cold start to prevent UID targeting but that currently does not exist.

Adjusting /etc/passwd Modify root:x:0:0:root:/root:/bin/nologin

Create a single fallback admin account for EMERGENCY USE ONLY! fallbackadmin:x:0:0:root:/root:/bin/bash

Implement sudo for all admins so that change log auditing can be implemented to accurately track who makes changes for accountability!

This implements the PCI US Gov requirements to disable default admin/guest accounts and create a single emergency use admin account.

One way to archive logs for auditing is to collect terminal history from all users with sudo account access if centralized AAA is not implemented.

A solution to implement admin only accounts is to create one user only account and one sudo enabled account then force the user to su to their sudo enabled account for administrative access.

You could also implement smart card authentication if you want better security there are solutions available for GNU/Linux that do compare to US Common Access Card CAC Solutions for two factor authentication.