Deleting users with nologin shell

Question

On a security audit performed on our production Linux servers , we were asked to remove nobody user if no application are using it.

I checked and could see that there are no files owned by 'nobody' user.

find / -path /proc -prune -o -user nobody -ls

'nobody' user does not have a login shell, similarly any user who does not have a login, Can it pose any security threat? Is it advisable to delete these users without a login shell?

# grep nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin

Please give your thoughts.

Answer 1

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:

• Bad

  bin:x:1:1:bin:/bin:/bin/sh
  

• Good

  bin:x:1:1:bin:/bin:/sbin/nologin
  

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.

File Ownership

Let's take the file ownership first, since it's the easier of the 2.

Having these entries in /etc/passwd and /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/passwd and /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.

Process Ownership

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 first call generates 500/500, and the second call fails).
• seteuid(500); setuid(0); Answer: 0/500 (the first call generates 500/500, and the second call generates 0/500).
• seteuid(600); setuid(500); Answer: 500/500 (the first call generates 600/500, and the second call generates 500/500).
• seteuid(600); setuid(500); setuid(0); Answer: 0/500 (the first 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.

Services

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 /etc/passwd file.

Windows

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.

• List of Hidden / Virtual Windows User Accounts
• Well-known SIDs - Security Identifiers
• Becoming NT AUTHORITY\SYSTEM on Windows

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.

References

• Unix LS Command: 15 Practical Examples
• Changing user and group ID system wide (including file system attributes)?

Answer 2

IIRC it is common for daemons to run as user nobody. So it is explicit that they have no more rights than necessary (none) after starting up.

E.g. if I do:

ps -u nobody

on my system it shows dnsmasq as a process.

I cannot find confirmation but I don't think it wise to remove these accounts, I am not sure if the processes that use the account name have a reasonable fall-back.