Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
7  
I find it extremely suspicious that your auditors are not familiar enough with Linux to recommend such a thing without pointing out possible side-effects. –  Anthon Jun 11 '13 at 7:18
2  
It's the whole point of nobody to not own any file. That's the user with as few rights as possible. nobody is also sometimes used with NFS. 99 is unusual a uid for nobody. I'd be interested to hear why those auditors want to remove such an essential user as nobody –  Stéphane Chazelas Jun 11 '13 at 7:48
    
Just to emphasize Anthon's comment, I'd challenge your auditors: if they cannot name at least one thing that is likely to break by doing what they suggest, fire them, and put them on a blacklist so no one at your organization wastes money hiring them again. There's a class of "auditor" that just runs automated tools with no understanding of what the tool is telling them. Your auditors may be of this stripe. –  Warren Young Jun 11 '13 at 12:43

2 Answers 2

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.

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

share|improve this answer

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.

share|improve this answer
    
I think you might want -U nobody as well, to see setuid programs. –  l0b0 Jun 11 '13 at 11:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.