2

Specifically, I use fish shell. I would really like to use this on my production server, and also set it as the default shell for the root account, but I'm wondering if there are any specific security concerns, given that it is a shell, that I should be aware of before doing so. I would guess that it is no more of a security risk than any other application on the server, since it only runs after a login occurs, but somehow using it as the default root shell on a production server feels less secure.

My main question is: is there any additional security risk in installing a non-standard shell and setting it to be the default shell for the root user than there is when installing any other application?

Edit: The current answers do not address the question, perhaps because I was unclear. Let me try to be more precise by explaining why I feel the answers are incomplete.

Of course, when you install any new software, there is a risk that it has a security bug. Certain software, depending on usage, requires more caution than other - for example, installing a web server introduces a new attack vector by it's very nature, and therefore we would be more cautious about installing some less common web browser than, say, an image conversion utility. I want to know if shells, by nature, should be scrutinized more carefully as well, and if so, why.

In addition, I would like to know if setting a non-standard shell as default for the root user would carry additional security implications. My practice thus far, even on my home machines, has been to run the fish shell as default for my own user, but not run it at all as root. Is this concern warranted, and if so, why?

So far, the answers have indicated that I should not do this, but have not, in my opinion, satisfactorially addressed the why. Practically no one uses only default software on a server, plenty of additional programs are installed on top without too much of a security concern, so why is a shell, in particular, something to be more cautious about? Ideally, I would like top see an example scenario where installing some non-standard shell as default for root would lead to a compromise that wouldn't otherwise have happened if the shell had been some other type of program (say, an image conversion program) .

Improve this question

2 Answers 2

Reset to default
1

The shell is a critical system component, and I would be very uncomfortable in using a non standard or not widely deployed shell into production and/or internet facing servers.

The point is that (almost) every shell has more or less powerful scripting/programming capabilities which, coupled with gobbling and expansion, can result in very unexpected side effects (ie: see shellshok for example).

Moreover, is already quite difficult to master a single, well documented shell (as bash), let alone using multiple, different shells...

Improve this answer
3
  • It sounds like your answer is that I should not use a non-standard shell because I may make a mistake when using it, or it may contain a bug which ends up damaging something (while I'm using it). I see your point, however I am personally more familiar with this other shell than I am with bash, so the argument could be flipped. The shellshock example shows that a bug in a shell could result in a security risk. On the other hand, since this is an example of a serious bug within bash, it sort of argues against the idea of using bash anyway. I've edited my question to highlight my concern.
    – mboratko
    Jan 4, 2017 at 21:16
  • Yes, but as many more peoples use bash, there are more probabilities for serious security problem to be detected and fixed. Well, it should be that way, even if shellshok seems to tell another story ;)
    – shodanshok
    Jan 4, 2017 at 21:18
  • I don't know, I think this is just the flip-side of a specious security-by-obscurity argument. (One could argue that, since bash is so widely used, the incentive for hackers to exploit it is much higher than the incentive to exploit a lesser used shell.)
    – mboratko
    Jan 4, 2017 at 21:29
1

Should I change my default shell

Your question and the statement vary a little, as you are changing the shell for root on your production servers. I would suggest the answer is no, based on my experiences.

Security Impact

There is risk. You have introduced a new behavior on anything that could potentially fork a shell. Vulnerabilities that did not apply to bash may apply to your custom shell. You would have to research this. Hopefully fish is at least supported by your OS distro and you are not manually installing it.

Operational Impact

Changing the default shell for root is asking for trouble. You should set up test systems and induce problems that would require single user mode and any other failure scenerio that your local/remote DR/bakup plans do not account for. You may find that your shell replacement works without issue, but you would have to account for all failure scenerios.

If I were going down this path, I would propose this idea to my OS support provider and get their thoughts and experiences with it first, if I felt I really had a need to do this. I am a minimalist and experience tells me to keep things as simple and standard as feasible, especially in environments that have revenue or contractual SLA impact.

Improve this answer
3
  • 1
    You mention "There is risk", which is obviously true any time you install any software on a computer, but what I'm interested in is: is there any special risk since this is a shell? If you've answered this above and I've misunderstood, could you please explain in more detail? How is this more dangerous than, say, allowing end-users to install some Wordpress modules, which typically undergo very little scrutiny?
    – mboratko
    Jan 5, 2017 at 3:14
  • I know the answer above is a little vague, but that is on purpose. When you are using the standard tools provided by your OS vendor, then you are using something that has been tested and scrutinized by many people, security orgs, audit vendors, etc, that each company using those tools must go through. Once you deviate from that, you are creating an unknown-unknown, which must be tested. If you are asking about vulns very specific to the fish shell, I don't have a good answer for you, as I would have to research that. My answer was more generalized on purpose.
    – Aaron
    Jan 5, 2017 at 20:24
  • Thank you. I'm not asking about vulnerabilities for a particular shell, however. I'm asking if there is anything implicitly more dangerous about setting a non-standard default shell, especially for the root user, than there is about installing some other applications. Is there anything about it being a shell - either by what it has access to, how it is used, the fact that it is run when the user logs in, etc. - that means I should scrutinize it more than, say, installing some server monitoring software from the repos? It feels like there is, but I can't come up with a decent reason.
    – mboratko
    Jan 5, 2017 at 20:51

You must log in to answer this question.

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