Why does the 'bin' user need a login shell?

Question

During an audit of /var/log/auth.log on one of my public webservers, I found this:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

At first blush, this looks like typical ssh login spam from random hackers; however, as I looked closer I noticed something else. Most failed /var/log/auth.log entries say invalid user in them, like this one:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

The disquieting thing about that failed login message for bin is that it is a valid user in /etc/passwd that even has a login shell:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

I thought I had covered the all the default usernames that could login remotely when I disabled PermitRootLogin in /etc/ssh/sshd_config; discovering this entry opened new possibilities in my paranoid mind. If somehow services ran under bin, then it is remotely possible that someone could somehow insert an ssh key into the bin user's directory from a running service on the box, so I would like to completely disable login for the bin user, if possible.

Questions

• This server is remote, and expensive to fix (i.e. I will pay for remote hands to hook up a KVM, plus KVM rental). I am trying to figure out what I might break if I change the /etc/passwd entry for bin to look like this:

  bin:x:2:2:bin:/bin:/bin/false

• I ran the following commands trying to figure out what bin is needed for... However, these commands came up with no files and I could find no processes owned by bin. What does the bin user do anyway?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Are there any other users that should get their login shells set to /bin/false? FYI, I have already have /bin/false on www-data.

• Am I being too paranoid?

I am running Debian, if that matters.

Answer 1

A user who has a valid shell and no password can still log in by non-password-based methods, the most common being an ssh key. A valid shell is necessary to run cron jobs. A valid shell is also necessary for su bin -c 'wibble' to work (on Linux at least, su bin -s /bin/sh -c 'wibble' will also work).

In the case of bin, most systems never run a command as bin in normal operation, so setting the shell to /bin/false would be ok.

There is no risk of any direct attack allowing bin to log in over SSH, because that would require creating /bin/.ssh/authorized_keys as the user bin or as root. In other words, the only way to get in is to be in. However, having a valid shell does increase the risk of misconfiguration. It can also permit some remote attacks with services other than SSH; for example a user reports that an attacker could set a password for daemon remotely via Samba, then use that password to log in over SSH.

You can plug the SSH hole by listing the names of the system users in a DenyUsers directive in /etc/ssh/sshd_config (unfortunately, you can't use a numerical range). Or, conversely, you can put an AllowGroups directive and only allow the groups that contain physical users (e.g. users if you grant all your physical users that group membership).

There are bugs filed over this issue in Debian (#274229, #330882, #581899), currently open and classified as “wishlist”. I tend to agree that these are bugs and system users should have /bin/false as their shell unless it appears necessary to do otherwise.

Answer 2

You don't have to worry about those as users. They are "users" in the sense of security groups, not users in the sense of "login and use" people. If you look in "/etc/shadow", you will see that all these "users" do not have passwords (either "x" or "!" instead of a long salted hash). This means that these users cannot login, no matter what.

That said, I don't know if it is a good idea to change "/bin/sh" to "/bin/false" for all these users. Because programs run under these groups, it might not allow them to execute the commands that they need to. I'd leave them as "/bin/sh".

There is no need for you to worry about these users. Only worry about the users you create (and ones with hashes in "/etc/shadow")

Answer 3

I believe this is a non-issue, as in order to set up an SSH public key in the bin's home directory (/bin), the attacker would have to have root access to the file system, which means you're screwed anyway.

If you like, you could disable all authentication methods for the bin user in sshd's config using the MatchUser block.

That said, looks like the bin user is unused on modern Debian-derived systems and is purely a nod to tradition or is there for compliance with some standards.