remove system accounts

I

izotov

Hi,
On a FreeBSD system there are several system accounts that normally can not be accessed (no home, no login shell, etc.). Some customers however fear of them and want me to remove some of these users.

Code: 
toor:*:0:0::0:0:Bourne-again Superuser:/root:
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/usr/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/usr/sbin/nologin
sshd:*:22:22::0:0:Secure Shell Daemon:/var/empty:/usr/sbin/nologin
smmsp:*:25:25::0:0:Sendmail Submission User:/var/spool/clientmqueue:/usr/sbin/nologin
mailnull:*:26:26::0:0:Sendmail Default User:/var/spool/mqueue:/usr/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/usr/sbin/nologin
proxy:*:62:62::0:0:Packet Filter pseudo-user:/nonexistent:/usr/sbin/nologin
_pflogd:*:64:64::0:0:pflogd privsep user:/var/empty:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/local/libexec/uucp/uucico
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/usr/sbin/nologin

So the question is what is the effect of removing each account above? Which of the above must not be removed?
For example: if sendmail is disabled then can smmsp and mailnull be removed?

Thanks!
 
Do not remove any of those accounts. You will run into serious problems if you do. The only notable exception which can be removed without any issue is the 'toor' account. Everything else is actually being used in some form or another.

Just make sure they are indeed locked out, have some random password and their shell is set to /usr/sbin/nologin.
 
Is this even true for the game account? That seems so useless (on a system where there are no games at all)...
 
As you well stated on your first message, you cannot access these accounts. Hence, you have no fear of them. Once you see peculiar events starting from those clients, it means that your system has been compromised. And if those accounts didn't exist, the applications using them would have used the root account instead. And if one of those applications was ever compromised running as root, THEN your customers should be really afraid.
 
What's the purpose of these? Why are they there? What uses them?

Code: 
toor:*:0:0::0:0:Bourne-again Superuser:/root:
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
 
I still remember the day when I was trying to explain to an "auditor" why these accounts are needed in a firewall although user authentication is being done externally. (I used TACACS)

BTW Why do you provide access to /etc/passwd to your customers ?
 
gkontos said:
BTW Why do you provide access to /etc/passwd to your customers ?
Click to expand...
That file must be readable by the 'others' group or things will break.
 
dixonjp said:
What's the purpose of these? Why are they there? What uses them?

Code: 
toor:*:0:0::0:0:Bourne-again Superuser:/root:
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
Click to expand...

Toor is a copy of the root account, primarily used by people that want to change root's shell. It's the only one you can safely delete.

The others all have counterparts in /etc/groups, several files are owned by those groups/users. The www user is the account apache (and other webservices) runs on.
 
I figured out what the games user is for I believe...

There is a feature called a fortune a day for the terminal when you log in, and other little things like that. I think thats what the game user is for but it would be great if a BSD guru could say forsure.
 
dixonjp said:
What's the purpose of these? Why are they there? What uses them?

Code: 
toor:*:0:0::0:0:Bourne-again Superuser:/root:
games:*:7:13::0:0:Games pseudo-user:/usr/games:/usr/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/usr/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/usr/sbin/nologin
www:*:80:80::0:0:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
_dhcp:*:65:65::0:0:dhcp programs:/var/empty:/usr/sbin/nologin
Click to expand...

Look through /etc/inetd.conf to see what uses the news and pop accounts.

Web services like Apache use the www account.

_dhcp is used by ... DHCP servers and clients. :)

games is used by everything under /usr/games, if the games are installed.

Basically, any user or group with an ID number under 100 should not be removed. These are system accounts that server very specific purposes.
 
Anyway, if you remove these accounts and you want to upgrade your system, mergemaster will force you to put them back, or everything will fail to install.
 
Customers can make security audit on the system that is why they are allowed to see /etc/passwd.

I did a little find and there is no file in my systems owned by (user or group):
  • bin
  • news
  • sshd
  • mailnull
  • proxy
  • _pflogd
  • _dhcp
  • pop
  • www
games owns only one directory: /var/games.
What if I remove these? Is it still possible that a process wants to run as a user of these?
 
How many posts is it going to take? Go ahead, save 1 KB of disk space, remove these completely harmless system accounts (that have virtually zero-access to your systems' resources) and come back a week from now asking for help because all hell has broken loose in your customers' machines. Then you can restore your systems as they were before and start doing what you should already be doing instead: reassuring your customers on how these accounts were completely harmless to begin with.

And as phoenix already said, _dhcp is used by both the DHCP server and the DHCP client, so even if you're using DHCP on a desktop machine, you'll need it. Run top and see for yourself:
Code: 
501 _dhcp           1  44    0  3284K  1428K select   0:00  0.00% dhclient
 
What if I remove these? Is it still possible that a process wants to run as a user of these?
Click to expand...

If it's a daemon, like a web-server, or an MTA, most probably it is going to try to use those accounts.
On the other hand - most daemons are configurable, and there is no actual need of running a web-sever on a regular desktop computer. Still - you are going to have problems with updates (mergemaster mentioned above) if you remove any of those.

I should say that actually it would be very nice if we had a chapter in the handbook or an article which would clearly state and explain raison d'etre of each system account in great detail. Because for the time being all you get is the answer - don't touch them, this is essential part of the system. It is not actually an answer. For example I wonder who or what uses that sshd account - sshd main instance runs as root and forks new instances on connect which are to run under a user account. Though perhaps it is used when you are not using unix accounts for authorization.
 
izotov said:
Customers can make security audit on the system that is why they are allowed to see /etc/passwd.
Click to expand...
I think that your question was adequately answered. But in order to convince an auditor you have to be able to perform audits on your systems yourself. You should really get a deeper understanding on what built-in accounts do regardless of the OS.
 
Beastie said:
How many posts is it going to take? Go ahead, save 1 KB of disk space, remove these completely harmless system accounts (that have virtually zero-access to your systems' resources) and come back a week from now asking for help because all hell has broken loose in your customers' machines. Then you can restore your systems as they were before and start doing what you should already be doing instead: reassuring your customers on how these accounts were completely harmless to begin with.
Click to expand...

You must understand that someone who has no deep BSD knowledge does wonder why the hell a games user there is on a system where there should be no games at all.
 
What you're saying isn't limited to BSD in anyway, every variant of UNIX and UNIX-like operating systems tend to have those accounts and they make zero effort to make it easy to hide or remove them.
 
kpa said:
UNIX and UNIX-like operating systems tend to have those accounts and they make zero effort to make it easy to hide or remove them.
Click to expand...

FreeBSD could be the first to do so... (:

Anyways I try to make myself and my customers understood that it is not safe to remove those accounts as noone really knows what the effect was if doing so.
Thanks for all the answers!
 
izotov said:
noone really knows what the effect was if doing so.
Click to expand...
You're trying to remove accounts* that various system daemons run under. The effect is very obvious: b0rked system.
*very limited accounts presenting low/no security risks
 
izotov said:
Customers can make security audit on the system that is why they are allowed to see /etc/passwd.

I did a little find and there is no file in my systems owned by (user or group):
  • bin
  • news
  • sshd
  • mailnull
  • proxy
  • _pflogd
  • _dhcp
  • pop
  • www
games owns only one directory: /var/games.
What if I remove these? Is it still possible that a process wants to run as a user of these?
Click to expand...

Even if you don't find files and directories this doesn't mean those accounts are not used.
Code: 
[CMD="$"]ls -l /dev/ | awk '{printf "%s\n%s\n", $3, $4}'| sort | uniq -c | sort[/CMD]
   4 dialer
   4 kmem
   4 uucp
   6 tty
  32 operator
  68 wheel
 111 root

Another example is the sshd user
Code: 
[cmd="$"]cd /usr/src/crypto/openssh[/cmd]
[cmd="$"]grep getpwnam sshd.c[/cmd]
        if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
[cmd="$"]# grep SSH_PRIVSEP_USER *[/cmd]
config.h:#define SSH_PRIVSEP_USER "[color="Red"]sshd[/color]"
config.h.in:#undef SSH_PRIVSEP_USER
ssh.h:#ifndef SSH_PRIVSEP_USER
ssh.h:#define SSH_PRIVSEP_USER          "[color="Red"]sshd[/color]"
sshd.c: if ((privsep_pw = getpwnam(SSH_PRIVSEP_USER)) == NULL) {
sshd.c:                     SSH_PRIVSEP_USER);

This is only a short excursion, you can find every user in your list in the system sources.

I hope this gives you now a different view to this accounts and why they are there.

For more information and arguments for your customer read
setresuid(2)
setuid(2)
setgroups(2)
 
You must log in or register to reply here.
Back
Top