Linode.com Forum

Dahak · Joined: 18 Jun 2008 Posts: 8

Now that I've got a quick'n'dirty system running with email, wiki, etc., I'd like to start some housecleaning and do it right. One thing I note is there are quite a few users and groups in the default install (using CentOS 5 here, but same for any distro I've tried). I've been unable to find a detailed explanation of why many of them are there--just traditional, or actually needed. Anybody got any inputs?

Here's the fresh /etc/passwd from CentOS:

root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
gopher
ftp
nobody
rpm
dbus
vcsa
haldaemon
sshd
exim

Which ones can I safely delete? Assuming, of course, I'm not using an app that requires it? For example, exim--no exim installed, why do I need it? Mail--Postfix has its own user/group. ftp--no FTP server, safe to delete? gopher--how many people still remember gopher, much less have a gopher server running? etc.

Comments/inputs? I'd like to get users/groups stripped down to the absolute bare minimum necessary, AND understand exactly what is left or deleted, and why--not just "delete x, y, and z"

Jay · Joined: 14 Nov 2004 Posts: 125 Location: NC, USA

The overriding question here is why?

If you look in the shadow file, you'll notice that almost none of these users actually have passwords set. Removing those user accounts isn't actually going to help anything; in fact; you're quite likely to break something in the future (because CentOS will be expecting those users to exist).

Dahak · Joined: 18 Jun 2008 Posts: 8

Jay wrote: The overriding question here is why?

1. General neurotic tidyness. If it's not needed, I don't want it around.

2. Security.

Jay wrote: If you look in the shadow file, you'll notice that almost none of these users actually have passwords set. Removing those user accounts isn't actually going to help anything;

Removing the password only prevents direct login. They are still valid system accounts. All the daemon accounts on the system have passwords disabled; that doesn't mean they can't be exploited.

3. General knowledge.

I like to understand the "why" of a system. How do you know what the effect of removing one of these will be?

Jay wrote: you're quite likely to break something in the future (because CentOS will be expecting those users to exist).

Some users, perhaps. Others not. That's what I'd like to understand. Even if I leave the users there, I'd like to know why they're there, or were originally there.

Incidentally, the Linux Standards Base lists exactly 3 required user names, and 11 optional, which doesn't cover all the above. It also explicitly states that the 11 optional are for use by distributions, NOT applications, and that applications cannot make assumptions about users/groups.

Again, some of this is obvious. "rpm" has to do with the package database ... but why is a separate user needed? What's the difference between root, adm, and operator? I don't use uucp, will anything break (perhaps not until the right moment) if I delete the user/group? I don't print from my linode, can I delete the lp user?

If I'm not using it--user, group, executable, library, whatever--and there's no other reason for it to be around, it just represents an unneeded potential security hole waiting for somebody to discover a way to exploit it. And it clutters things up. Why should I deal with scanning through a list of two dozen usernames when I really only need 4?

chacham · Joined: 04 Mar 2004 Posts: 23 Location: Oak Park, MI

If you want to find out why, buy another linode, copy the current image, and play with it. Slowly you will learn, and be all the better for it.

pclissold · Joined: 24 Oct 2003 Posts: 470 Location: Netherlands

With the exception of root, sync, shutdown, halt and news, the standard CentOS users have their shell set to /sbin/nologin - so as well as having no password, they cannot spawn a useable shell.

The multitude of users is intended to allow processes to run with just enough privileges and access to get their job done. Installing daemons and system software via a package manager will create the appropriate users and groups.

If you really want to trim them back then:

The ones you need:
Code: root (obviously)
vcsa virtual console memory owner
rpm package management programs

The ones you can do without:
Code: adm admin priviliges short of root (legacy - replaced by sudoers)
sync priviliges to sync filesystem (legacy)
shutdown priviliges to shutdown system (legacy)
halt priviliges to halt system (legacy)
operator priviliges for operator (legacy)

The ones you can probably do without
Code: nobody used by NFS (nothing on my Linode runs with this userid, but I haven't deleted it - YMMV

The ones you can do without, but they are part of the core specification:
Code: bin system admin software (legacy)
daemon daemons that don't have their own userid (legacy - they should all have their own user and group id)

The ones you can do without if you are not running the associated service:
Code: dbus system message bus (dbus-daemon - it's not running on my Linode)
haldaemon hardware abstraction layer daemon (hald - it's not running on my Linode)
sshd ssh daemon
lp printer privileges
mail mail privileges
news news privileges
uucp uucp privileges
games games software
gopher gopher software
ftp ftp software
exim default MTA for CentOS

The ones that aren't there but you might want (if you are 'old school'):
Code: sys members can run a bunch of admin commands (if you uncomment the appropriate line in /etc/sudoers)
wheel members can sudo all commands (if you uncomment the appropriate line in /etc/sudoers)

Ciaran · Joined: 13 Feb 2004 Posts: 138 Location: England, UK

pclissold wrote: The ones you can probably do without
Code: nobody used by NFS (nothing on my Linode runs with this userid, but I haven't deleted it - YMMV

Actually, a fair number of other programs tend to use this user too. Apache, for example, by default has it's User/Group directives set to "nobody" and "nogroup" in its out-of-the-box state. Some distributions will use more appropriate usernames, like www-data, but "nobody" is the most common.

Some FTP programs will use it too. I'd class "nobody" as one to keep around if it's being used. I don't know whether CentOS uses it or not in its packages.

SteveG · Joined: 30 Nov 2003 Posts: 212

The tradition of "nobody" and "nogroup" is that they don't own any files or directories, and are thus safe as a default user/group id, since the only things they should be able to access are object that are read (or write) everybody.

Dahak · Joined: 18 Jun 2008 Posts: 8

pclissold wrote: With the exception of root, sync, shutdown, halt and news, the standard CentOS users have their shell set to /sbin/nologin - so as well as having no password, they cannot spawn a useable shell.

The multitude of users is intended to allow processes to run with just enough privileges and access to get their job done.

I know--maybe I'm just being obsessive-compulsive. But it makes me feel better...next step is to figure what packages I can uninstall.

pclissold wrote:
If you really want to trim them back then:
...

Pretty much what I had figured, but confirmation helps. Only one I'm still a bit unsure about:

pclissold wrote:
The ones you can do without if you are not running the associated service:
Code:
...
mail mail privileges
...

I'm going to be running Postfix, which has its own user/group--is there anything else that explicitly expects a 'mail' user/group, or a convention that requires it? I don't see any processes running with that, but note that postfix is also in the mail group ...

Guess I'll just try deleting wholesale and see what breaks ...

SteveG · Joined: 30 Nov 2003 Posts: 212

Dahak wrote:
I'm going to be running Postfix, which has its own user/group--is there anything else that explicitly expects a 'mail' user/group, or a convention that requires it?

Uh, pretty much anything that writes (or could write) to /var/mail?

kupesoft · Joined: 27 Jun 2008 Posts: 3

Dahak wrote:
1. General neurotic tidyness. If it's not needed, I don't want it around.

May I suggest Linux From Scratch?

Dahak · Joined: 18 Jun 2008 Posts: 8

SteveG wrote:
Uh, pretty much anything that writes (or could write) to /var/mail?

Well, yeah. But given that postfix (I think?) maintains its own spool directories, I was wondering if there WAS anything that would need it. I mean, if the MTA isn't putting anything into /var/mail, what good would it do to check?

I know, the real answer is "try it & find out"--but I'm taking the lazy^h^h^h^hefficient way out and trying to leverage what other people might know already ... :D

kupesoft wrote: May I suggest Linux From Scratch?

Indeed ... I played around with that a while ago, and enjoyed it. Our home server is still running on a (badly outdated) hacked-up version. But I don't have the time right now to go that far, especially as far as maintenance goes. I'd rather take something that's supported, and do what I can when I have time, while knowing I'll still get updates when they become available. Unless, of course, I delete something critical ...

SteveG · Joined: 30 Nov 2003 Posts: 212

Postfix, by default, delivers to /var/mail/ (or /var/spool/mail, which is usually the same). If you've got it configured to deliver to user home dirs, then you're probably okay. But users might want to use other tools (like procmail) and expect
to be able to deliver to the "default", which most tools are going to call /var/mail/_username_.

You can, of course, "just try it", but it may fail in an non-obvious way, such as
leaving a file exposed with incorrect ownership when it fails to chown('mail'). You might want to look at the default user list on Debian; I know that some effort has been put into minimizing it, although I don't claim it's the absolute minimum

OverlordQ · Joined: 04 Jun 2004 Posts: 200

pclissold wrote: With the exception of root, sync, shutdown, halt and news, the standard CentOS users have their shell set to /sbin/nologin - so as well as having no password, they cannot spawn a useable shell.

If you have a login on the machine it doesn't matter what that shell value is set to you can use whatever shell you want by passing it as an option to su.

Dahak · Joined: 18 Jun 2008 Posts: 8

OK, so I haven't had time to do much lately (how does everybody else carve time out for hobbies?), but I did do some research and playing around. Starting with others' inputs above, here's what I've come up with. I also looked at what packages I could remove from the base install, and the users that would go with those.

Linux Standards Base Required Users/Groups
Code:
User Group Notes
-------- -------- ---------
bin bin Legacy user/group for system admin software
should not be used by new applications
daemon daemon Legacy user/group for daemons that don't have their own userid
should not be used by new applications
root root Administrative user

CentOS Required Users
Code:
User Group Notes
-------- -------- ---------
rpm rpm Package management
vcsa vcsa virtual console memory owner

Unneeded Users
Code:
User Group Notes
-------- -------- ---------
adm adm admin privileges short of root (legacy)
halt - privileges to halt system (legacy)*
operator - privileges for operator (legacy)
shutdown - privileges to shutdown system (legacy)*
sync - privileges to sync filesystem (legacy)*

* I think the idea behind these was that the password was shared with anybody who needed to carry out the task; the shell for that user was set to the appropriate program, so if you tried to log in as 'sync' the system would execute /bin/sync.

Optional Users/Groups
Code:
User Group Notes
-------- -------- ---------
dbus dbus System message bus (dbus-daemon—it's not running on my Linode)
- dip ?
- disk ?
exim exim default MTA for CentOS
- floppy Owns the floppy drive—irrelevant on a Linode
ftp ftp ftp daemon
games games games software (to allow writing high scores to shared file)
gopher gopher gopher daemon
haldaemon haldaemon hardware abstraction layer daemon (hald--it's not running on my Linode)
- kmem ?
- lock ?
lp lp Printer privileges. Owns /dev/lp*--irrelevant on a Linode.
I deleted the device nodes, too.
mail mail mail privileges
- man Owns man pages
- mem ?
news news news privileges
nobody nobody used by NFS and some other programs (e.g. default Apache
runs as nobody/nogroup?); legacy username/group that should
not own any files or directories, hence considered a safe
default UID/GID because it can't affect anything but world
accessible resources.
sshd sshd ssh daemon (but seriously—how can you not be running sshd?)
- slocate ?
- sys ?
- tty ?
- users ?
- utempter ?
- utmp ?
uucp UUCP uucp privileges
- wheel Restrict users allowed to su to root (legacy).
Not enforced unless enabled in PAM. Better option is to use
sudo and lock down root completely.

Out of this, I think I can do without adm, lp, news, uucp, haldaemon, halt, operator, shutdown, sync, dbus, exim, ftp, games, gopher, and groups dbus, dip, ftp, floppy, games, gopher, haldaemon, news sys.

Here's a script to delete the ones I think I can do without so far:

Code:
# Home is /var/adm, which doesn't even exist?
# No other files
userdel adm
groupdel adm

# Homes are system directories (/, /root, /sbin)
for USER in haldaemon halt operator shutdown sync dbus; do
userdel $USER;
done

# Home is /var/spool/exim, which
# should be deleted by removing package, but
# the user, group and other files are still left
userdel -r exim
groupdel exim
rm -rf /etc/pki/tls/certs/exim.pem \
/etc/pki/tls/private/exim.pem \
/var/spool/exim/ \
/var/log/exim/ \
/etc/exim

# Home is /var/ftp, which doesn't even exist?
userdel ftp

# Home is /usr/games, which is empty
# May be part of FHS?
userdel games

# Home is /var/gopher, which doesn't even exist?
userdel gopher

# Home is /var/spool/lpd, but it's not owned by
# lp and isn't removed by userdel -r
# CUPS isn't even installed, so log is unneeded
# group lp owns /dev/parport*
rm -rf /var/spool/lpd \
/var/log/cups/ \
/var/cache/cups/ \
/dev/parport*
userdel -r lp
groupdel lp

# Home is /etc/news, which doesn't even exist
# Interestingly, this one doesn't have a shell at all!
userdel news

# Home is /var/spool/uucp, which doesn't even exist
# Serial ports not needed on Linode
userdel uucp
rm -rf /dev/ttyS*
groupdel uucp

# These may have been removed already?
for GROUP in dbus dip ftp floppy games gopher haldaemon news sys; do
groupdel "$GROUP"
done

Comments?

FunkyRes · Joined: 02 Oct 2008 Posts: 17

The rpm user is no longer necessary with current upstream RPM, and you can probably remove the user from CentOS as well - I don't think it does anything.

Removing the users though isn't going to make the system more secure, their presence in the passwd file alone does not magically make them potentially exploitable - you either need to exploit a program running as one of those users or have a general exploit that allows you to jump privileges.

In the first case, you need the use accounts if you have programs running as them.
In the second case, if you can jump privileges to another user, there are still going to be plenty of users in the passwd file you can jump to - or you can simply jump to a UID without a user associated with it.

Locking Down Linode: Users/Groups