The presence of system account such as root, sys, nobody, bin, daemon, etc. has been the topic of many security audits that I've been through over the years and it really comes down to a few things.
Yes these types of accounts can be security holes, especially if they have a shell enabled:
When configured with the
/sbin/nologin or sometimes
/bin/false these accounts are disabled from being logged into, but they can still own processes. They can also own files too.
Let's take the file ownership first, since it's the easier of the 2.
Having these entries in
/etc/group with respect to file ownership introduces zero risk. In this capacity their presence makes the output of tools like
ls display this:
with entry in /etc/passwd
$ ls -l woof
-rwxrwxr-x 1 saml saml 20284 May 31 2012 woof
without entry in /etc/passwd
$ ls -n woof
-rwxrwxr-x 1 500 501 20284 May 31 2012 woof
So from this perspective it's nicer for a admin to be able to see the names of the owners vs. the UID/GID that's written on the disk. But these entries provide no additional enforcement about what UID/GID's can be created on the system, for example:
$ touch afile && chown 10000:10000 afile
$ ls -l | grep afile
-rw-r--r-- 1 10000 10000 0 Jun 11 05:11 afile
The only real risk incurred by having these entries in
/etc/group is that it gives a would be attacker the ability to hide files within the filesystem, and make them appear as though they belong by giving their files more authentic looking ownership's.
This is really the issue that most auditors seem to get hung up on when having system account entries in
/etc/passwd. They're under the impression that the entries in this file limit scope. But here's the rub. In the same way that
/etc/passwd doesn't limit your ability to create files with sporadic UID/GIDs neither does it enforce processes running as whatever UID/GID they want either.
See this SO Q&A titled: setuid sets a large number.
In UNIX there are 4 C functions that control who a process is owned by:
setuid() - set user id
seteuid() - set effective user id
setgid() - set group id
setegid() - set effective group id
If the account you're running in has elevated privledges then you can call these function with anything you want. For example:
setuid(500); setuid(0); Answer: 500/500 (the ﬁrst call generates 500/500, and the second call fails).
seteuid(500); setuid(0); Answer: 0/500 (the ﬁrst call generates 500/500, and the second call generates 0/500).
seteuid(600); setuid(500); Answer: 500/500 (the ﬁrst call generates 600/500, and the second call generates 500/500).
seteuid(600); setuid(500); setuid(0); Answer: 0/500 (the ﬁrst call generates 600/500, the second generates 500/500, and the third generates 0/500).
Above code borrowed from here: Set-UID Privileged Programs - lecture notes.
So given the fact that user nobody has no elevated permissions (i.e.
sudo), there isn't an option where a server/service running as nobody would be able to spawn any child processes as anything other than nobody. If this server/service running as nobody were compromised, only the files owned by nobody would be at risk.
In my dealings with securing systems, really the most critical area to direct focus is in what services are running on a given system, and what software is installed on this system.
For a production system, the installation should most definitely not include any development tools such as gcc/g++, and only the basic services should be running. There should be an update policy in place to periodically update the software installed on this system.
Saying all the above, none of this has anything to do with the presence of additional accounts for system related activities in the
I mention this here because at the end of the day, 9 times out of 10, auditors will be familiar with Windows security, where they may not be as familiar with UNIX security.
If you look at a Windows system you'll see a dozen or so user accounts that aren't directly tied to a specific user. These are system accounts, and they serve the exact purpose that an account such as nobody serves. Without them, or if they were disabled, a Windows system would be effectively in operable. So too for a UNIX system.
Usually when they are explained in this way, most auditors can appreciate why these accounts can/need to be left on a particular system that requires them.