The default permissions are fine, and needed. If you e.g. didn't leave passwd world readable, a lot of user-related functionality would stop working. File such as /etc/shadow shouldn't be (and aren't) world readable.
Trust the OS to get this right, unless you know very well that the OS is wrong.
why have programs like su access to /etc/shadow
Because programs like su and passwd have set SetUID. You can check by using :
[root@tpserver tmp]# ls -l /usr/bin/passwd
-r-s--x--x 1 root root 21200 Aug 22 2013 /usr/bin/passwd
When you look around in your file permission you will see "s". If anybody is trying to run the passwd program, by default it's taking the privilege of owner (root here) of the file. This means any user can get root privilege to execute the passwd program, because only the root user can edit or update /etc/passwd and /etc/shadow file. Other users cant. When the normal user runs the passwd program on his terminal, the passwd program is run as "root", because the effective UID is set to "root". So the normal user can easily update the file.
You can use the chmod command with the u+s or g+s arguments to set the setuid and setgid bits on an executable file, respectively
Long Answer : Set-User_Id (SUID): Power for a Moment:
By default, when a user executes a file, the process which results in
this execution has the same permissions as those of the user. In fact,
the process inherits his default group and user identification.
If you set the SUID attribute on an executable file, the process resulting in its execution doesn't use the user's identification but the user identification of the file owner.
The SUID mechanism, invented by Dennis Ritchie, is a potential security hazard. It lets a user acquire hidden powers by running such a file owned by root.
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
-rw-r--r-- 1 root root 2232 Mar 15 00:26 /etc/passwd
-r-------- 1 root root 1447 Mar 19 19:01 /etc/shadow
The listing shows that passwd is readable by all, but shadow is unreadable by group and others. When a user running the program belongs to one of these two categories (probably, others), so access fails in the read test on shadow. Suppose normal user wants to change his password. How can he do that? He can do that by running /usr/bin/passwd. Many UNIX/Linux programs have a special permission mode that lets users update sensitive system files –like /etc/shadow --something they can't do directly with an editor. This is true of the passwd program.
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 22984 Jan 6 2007 /usr/bin/passwd
The s letter in the user category of the permission field represents a special mode known as the set-user-id (SUID). This mode lets a process have the privileges of the owner of the file during the instance of the program. Thus when a non privileged user executes passwd, the effective UID of the process is not the user's, but of root's – the owner of the program. This SUID privilege is then used by passwd to edit /etc/shadow.
Reference Link
Best Answer
The idea behind setting
/etc/shadowpermissions to 000 is to protect that file from being accessed by daemons, even when running as root, by ensuring that access is controlled by theDAC_OVERRIDEcapability. Since Fedora 12 and RHEL 6, Fedora-based systems run daemons withoutDAC_OVERRIDE, but grantDAC_OVERRIDEto administrator login sessions (so that the change is invisible to administrators).See lower process capabilities for details.
This relies on the fact that 600 and 000 permissions aren’t functionally identical: 600 grants read-write to the file owner, whereas 000 only grants access to processes with the
DAC_OVERRIDEcapability. Traditionally, running as root always grantedDAC_OVERRIDE, but that doesn’t have to be the case.(SELinux can also be used to limit root’s abilities, but that’s not what’s involved here.
/etc/shadowdoes have its own SELinux context, providing additional access controls.)