Locking Down Linode: Users/Groups

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).

@Jay:

The overriding question here is why?

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

2. Security.

@Jay:

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:

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?

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.

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:

root       (obviously) 
vcsa       virtual console memory owner 
rpm        package management programs 

The ones you can do without:

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

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:

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:

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'):

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) 

@pclissold:

The ones you can probably do without

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.

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.

@pclissold:

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:

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:

The ones you can do without if you are not running the associated service:

...
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 …

@Dahak:

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?

@Dahak:

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

May I suggest Linux From Scratch?

@SteveG:

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:

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 …

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

@pclissold:

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.

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

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

User      Group     Notes
--------  --------  ---------
rpm       rpm       Package management 
vcsa      vcsa      virtual console memory owner 

Unneeded Users

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

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:

# 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?

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.