Rename /etc/passwd and /etc/shadow for security reasons [closed]

The Filesystem Hierarchy Standard for unix-like systems includes /etc/passwd at a fixed location, and tools are consequently usually hardcoded to look there for it. While in theory you could re-compile all the relevant utilities to look in a new location, any attacker could always just look for strings in those binaries to locate the new file, or use regular expressions to find files with passwd-like contents.

The shadow file should be readable only to root (and possibly to a group called shadow). If an attacker has managed to get root access to your system, they have complete control and whether or not they can read your passwd/shadow files is pretty irrelevant at that point.

There are conceivably a few situations where having files not in expected places might help, eg if you have a badly-configured web server which lets someone request http://myserver/../../etc/passwd, but in general this sort of indirection will require a lot of work for a minimal security benefit.

The best thing that would be is "completely useless" as you put it. (It doesn't provide an additional hurdle for an intruder)

/etc/passwd does contain account names, but anybody who has shell access to the system will be able to find them.

/etc/shadow contains sensitive information (the password hashes) but it is readable for root only. If an intruder managed to get root privileges - well how do you spell disaster?

In modern Unices (and Unix-likes, including Ubuntu), /etc/passwd doesn't contain any secrets. Renaming it would be more trouble than it is worth, given how many utilities would have to be rebuilt to look for it in its new location.

/etc/shadow is another matter, since there are secrets in that file, but renaming it won't help. It's only readable by root, so even if a hacker gets into the system as some other user, that's not enough to get to the file. This is why passwords were taken out of /etc/passwd in the first place: everyone needs to be able to read /etc/passwd, but only root needs to be able to get at the actual passwords, so the passwords were moved to a file that only root could read.

If the hacker does get root, then a rename won't save you. A simple recursive grep could give the hacker a list of files in an /etc/shadow-like format, and then the hacker only has to look through them to find the data he wants. You've delayed him by a few hours at most, and probably less: again, not worth the amount of time it would take to modify and recompile all the utilities that depend on /etc/shadow's location.

You cannot just rename these files. A lot of processes and programs will search for them, since this is a standard in Linux systems. What you can do is to securize your server in the proper way.

While it's probably no use to rename the /etc/passwd and /etc/shadow files, if you want added security you might want to look at PAM (pluggable authentication modules) and NSS (Name Service Switch). Like here.

PAM can be used to add authentication modules that, instead reading their authentication ifnormation from the standard files, read it from an other source, like from ldap or a database. Using it would mean the /etc/shadow can be almost completley eliminated.

NSS complements PAM by making some of the name resolution (like which groups does this user belongs to) independent from the standard files (/etc/passwd, /etc/groups). Using it would mean your passwd file will potentially only contain a fallback option for root, and nothing more. Using SSH keys to validate root login would also eliminate the need to have a root password inside the shadow file (although it might be desired if the SSH connection breaks).

Alternatively if you don't want to authenticate your users via a separate database or ldap host, you can also create your own PAM and NSS modules, which read their data from a non-standard file, although I wouldn't recommend this option.

When you want to try to use them never forget to keep some kind of fallback to a known, working authentication layer, otherwise you can lock yourself out of the system, even with root.

Note that not all applications support PAM (a lot of them do however). NSS however can be used to implement authentication for apps that don't support PAM, and some sites I've read about NSS actually suggest this approach. This however means that the NSS module will supply the (potentially) hashed password to anyone who can access the NSS authentication layer, which is almost always something you want to avoid (it's basically the same as giving non-root read access to the shadow file)! So if you're going this approach always make sure that NSS is only used to provide the user with the basic data (like the contents of /etc/passwd), and PAM is used as the authentication layer.