Does /usr/sbin/nologin as a login shell serve a security purpose?

Question

In my /etc/passwd file, I can see that the www-data user used by Apache, as well as all sorts of system users, have either /usr/sbin/nologin or /bin/false as their login shell. For example, here is a selection of lines:

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

Consequently, if I try to swap to any of these users (which I'd sometimes like to do to check my understanding of their permissions, and which there are probably other at least halfway sane reasons for), I fail:

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

Of course, it's not much of an inconvenience, because I can still launch a shell for them via a method like this:

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

But that just leaves me wondering what purpose is served by denying these users a login shell. Looking around the internet for an explanation, many people claim that this has something to do with security, and everybody seems to agree that it would be in some way a bad idea to change the login shells of these users. Here's a collection of quotes:

Setting the Apache user's shell to something non-interactive is generally good security practice (really all service users who don't have to log in interactively should have their shell set to something that's non-interactive).

-- https://serverfault.com/a/559315/147556

the shell for the user www-data is set to /usr/sbin/nologin, and it's set for a very good reason.

-- https://askubuntu.com/a/486661/119754

[system 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
  

-- https://unix.stackexchange.com/a/78996/29001

For security reasons I created a user account with no login shell for running the Tomcat server:

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

-- http://www.puschitz.com/InstallingTomcat.html

While these posts are in unanimous agreement that not giving system users real login shells is good for security, not one of them justifies this claim, and I can't find an explanation of it anywhere.

What attack are we trying to protect ourselves against by not giving these users real login shells?

Solution 1

If you take a look at the nologin man page you'll see the following description.

excerpt

nologin displays a message that an account is not available and exits non-zero. It is intended as a replacement shell field to deny login access to an account.

If the file /etc/nologin.txt exists, nologin displays its contents to the user instead of the default message.

The exit code returned by nologin is always 1.

So the actual intent of nologin is just so that when a user attempts to login with an account that makes use of it in the /etc/passwd is so that they're presented with a user friendly message, and that any scripts/commands that attempt to make use of this login receive the exit code of 1.

Security

With respect to security, you'll typically see either /sbin/nologin or sometimes /bin/false, among other things in that field. They both serve the same purpose, but /sbin/nologin is probably the preferred method. In any case they're limiting direct access to a shell as this particular user account.

Why is this considered valuable with respect to security?

The "why" is hard to fully describe, but the value in limiting a user's account in this manner, is that it thwarts direct access via the login application when you attempt to gain access using said user account.

Using either nologin or /bin/false accomplishes this. Limiting your system's attack surface is a common technique in the security world, whether disabling services on specific ports, or limiting the nature of the logins on one's systems.

Still there are other rationalizations for using nologin. For example, scp will no longer work with a user account that does not designate an actual shell, as described in this ServerFault Q&A titled: What is the difference between /sbin/nologin and /bin/false?.

Solution 2

Definitely it serves a security purpose. For example, look at the below bug filed for a system user who had a shell.

My debian server was compromised due to the daemon account having a valid login shell and having samba open for internet access. The break in was made by setting a password remotly via samba for the daemon account and the logging in through ssh. Some local root exploit was then used to OWN my server.

I would recommend you to read this wonderful answer by Gilles where he has provided links to some of the bugs as well.

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.

Solution 3

To add to the excellent answers of @slm and @ramesh:

Yes, as you have pointed out, you can still switch to users with nologin as their default shell by running sudo with a shell defined, but in this case, you have had to:

1. Log in as another user that has a valid shell
2. Have sudo permissions configured for that user to run the su command, and
3. Had your su attempt logged to the sudoers log (assuming of course that sudo logging is enabled).

The users that have nologin defined as their default shell often have higher privileges/are able to do more damage to the system than a regular user, so having them unable to log in directly attempts to limit the damage that a breach of your system could suffer.

Solution 4

Next to the great answers already given, I can think of the following scenario.

A security bug in a service running as a restricted user allows to write a file as that user. This file can be ~/.ssh/authorized_keys.

This allows the attacker to login directly in a shell which would make it much easier to execute a privilege escalation.

Disallowing a login shell would make this option a lot more difficult.

Solution 5

In addition to the excellent answers that have been given, it serves another purpose.

If you run an FTP daemon on your server, it checks the login shell of users that attempt to login. If the shell isn't listed in /etc/shells, it doesn't allow them to login. So giving daemon accounts a special shell prevents someone from modifying the account via FTP.

View more solutions

Comments

[Parthian Shot]

They both serve the same purpose, but /sbin/nologin is probably the preferred method. From a security standpoint, `/sbin/nologin`` isn't the preferred method; it wastes time and cycles providing a response. Although neither provide particularly good security; they're defense-in-depth measures, but they don't actually stop someone from running a command as a given user.

[Parthian Shot]

...I don't see how that actually depends specifically on the declared shell for the user. If the attacker only ran ssh user@site, and that worked, they wouldn't continue to trying ssh user@site /bin/bash, but I'm pretty sure that'd still work regardless of declared shell.

[metavida]

@ParthianShot, anecdotal evidence: on my CentOS server, when an account's shell is set to /sbin/nologin ssh user@site /bin/bash returns a simple This account is currently not available. message. Also, this answer says nologin protects SSH access

[Franko]

@ParthianShot based on the description, that's not what's happened. What's happened is: Samba was misconfigured; the attacker configured ssh access via Samba; the attacker logged on via ssh. Although this case is obviously the sysadmin's fault, if you replace "misconfigured Samba" with "exploitable service", then preventing login access makes sense, as it reduces the surface of attack. of course, if the exploit grants local execution, having ssh access rather than not, makes little difference.