It seems as if most Linux systems use either /sbin/nologin or /bin/false as the default shell for service accounts. Many hardening guides, such as CIS benchmarks, recommend changing the default shell for these accounts to /dev/null. While many recommendations have an anslysis attached, this is one that I have never seen justified. What concerns are driving this recommendations and what threat it is attempting to mitigate?

4 Answers 4


The only true technical reason I'm aware of is the possibility of malicious file substitution. Consider an attacker who finds a way to write to arbitrary files. If they can overwrite /sbin/nologin or /bin/false with a copy of /bin/bash, then they can conceivably find a way to log in as a service user and continue to elevate their privilege from there.

However, /dev/null cannot be trivially replaced in such a manner, for various reasons:

  • It's a device, not a flat file
  • Anything written to it disappears, so a simple overwrite won't work
  • If someone did replace it with /bin/bash, it might then in turn be overwritten by one of the many programs that use /dev/null as a bit sink, thwarting the attacker
  • If someone did replace it, it could break some system functionality in a way that will alert the administrators that something is wrong, much more so than replacing 'nologin' or even 'false'.

There is also a non-technical reason, which is that many administrators are bound by tradition and/or the habits they learned long ago, and /dev/null was once a more common choice for this use (I'm pretty sure /sbin/nologin didn't exist 20 years ago). Make of that what you will.

  • 1
    +1 The reason we were given aeons ago was exactly this - you can't overwrite /dev/null
    – Rory Alsop
    Jul 27, 2011 at 22:29
  • 1
    That justification seems silly. If the attacker can replace arbitrary files in /bin/, you are already totally hosed. Moreover, it is simply outright wrong to say that /dev/null is easier to replace. If you have permissions to write to /dev (namely, root permissions), then you can replace /dev/null with any file you like. On my machine, the permissions needed to overwrite a file in /dev are exactly the same as the permissions needed to overwrite a file in /bin. I think this claimed justification is completely bogus.
    – D.W.
    Aug 3, 2011 at 7:10
  • 1
    You are assuming the attacker logged in to replace files, but that is not the scenario I'm describing. History is replete with examples of services (ftpd, httpd, what have you) being used to overwrite files but not granting any sort of interactive access or the ability to execute arbitrary commands. Once the attacker has overwritten the file, they leverage that change to improve their access. Consider the current 0-day Wordpress attack. Use 'timthumb.php' to write an arbitrary php file to the web server, then execute it. It's a classic pattern of access elevation.
    – gowenfawr
    Aug 3, 2011 at 12:55
  • (Oops, hit return too early). As for permissions, "echo '' > /dev/null". Good. Now "echo '' > /bin/bash". See the difference?
    – gowenfawr
    Aug 3, 2011 at 12:56
  • 1
    Looking back on this, I can see a difference: overwriting /dev/null breaks pretty much everything. Overwriting /bin/nologin is an easy stealthy backdoor. Jun 6, 2013 at 17:48

I'm no Linux guru, but if I compare this to recommendations for service accounts on Windows, I think this is comparable to removing all privileges, including the possibility for interactive logon.
This is probably just a question of minimizing attack surface / least privilege...:

If you don't need it, shut it off.


Great question! As far as I know, there is no justification for this advice. As far as I know, it is bad advice; /bin/false or /sbin/nologin is just fine. (If I've missed something, I look forward to learning what it is that I've overlooked.)


Using /dev/null would result in no security audit log of an unauthorized interactive shell login attempt.

  • Hardening Linux By James Turnbull (2005) Chapter 1 page 21 is my source for this. I'd imagine extra logging could be configured to catch login attempts even when the shell is /dev/null, but I don't think any distros give that logging out of the box. Jun 6, 2013 at 19:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .