Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote 10 down vote favorite
2

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?

share|improve this question

3 Answers

up vote 9 down vote accepted

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.

share|improve this answer
1  
+1 The reason we were given aeons ago was exactly this - you can't overwrite /dev/null – Rory Alsop♦ Jul 27 '11 at 22:29
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 '11 at 7:10
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 '11 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 '11 at 12:56
I agree with D.W. here. If you can overwrite /sbin/nologin, you can also overwrite /etc/passwd, or /bin/login or some other file with the same permissions but that is executed by root. For the last point: that's what tripwire is for. – Gilles Aug 3 '11 at 12:58
show 3 more comments
up vote 3 down vote

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.

share|improve this answer
up vote 3 down vote

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.