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?
Best Answer
If you take a look at the
nologin
man page you'll see the following description.excerpt
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?.