Existe algum risco de segurança aumentado com shells personalizados?

Question

Especificamente, eu uso o fish shell . Eu realmente gostaria de usar isso no meu servidor de produção, e também configurá-lo como o shell padrão para a conta de root, mas eu estou querendo saber se há alguma preocupação de segurança específica, dado que é um shell, que eu deveria estar ciente de antes de fazer isso. Eu diria que não é mais um risco de segurança do que qualquer outro aplicativo no servidor, uma vez que ele só é executado após um login ocorrer, mas de alguma forma usá-lo como o shell raiz padrão em um servidor de produção menos seguro.

Minha principal questão é: existe algum risco de segurança adicional ao instalar um shell não-padrão e configurá-lo como o shell padrão para o usuário root do que quando instala qualquer outro aplicativo?

Editar: as respostas atuais não abordam a questão, talvez porque eu não tenha ficado claro. Deixe-me tentar ser mais preciso, explicando porque sinto que as respostas estão incompletas.

Claro, quando você instala qualquer novo software, existe o risco de que ele tenha um bug de segurança. Certos softwares, dependendo do uso, exigem mais cautela do que outros - por exemplo, instalar um servidor da Web introduz um novo vetor de ataque por sua própria natureza e, portanto, seríamos mais cautelosos ao instalar algum navegador menos comum do que, digamos, uma imagem utilitário de conversão. Eu quero saber se as conchas, por natureza, devem ser escrutinadas com mais cuidado também e, em caso afirmativo, por que.

Além disso, gostaria de saber se a configuração de um shell não padrão como padrão para o usuário root teria implicações de segurança adicionais . Minha prática até agora, mesmo em minhas máquinas domésticas, foi executar o fish shell como padrão para meu próprio usuário, mas não executá-lo como raiz. Esta preocupação é justificada e, em caso afirmativo, por quê?

Até agora, as respostas indicaram que eu não deveria fazer isso, mas, na minha opinião, não satisfizeram satisfatoriamente o porquê . Praticamente ninguém usa apenas o software padrão em um servidor, muitos programas adicionais são instalados no topo sem muita preocupação de segurança, então por que um shell, em particular, é algo sobre o qual se deve ter mais cuidado? Idealmente, gostaria de ver um cenário de exemplo em que instalar um shell não padrão como padrão para o root levaria a um comprometimento que de outra forma não teria acontecido se o shell tivesse sido algum outro tipo de programa (digamos, um programa de conversão de imagem ).

    

Answer 1

O shell é um componente crítico do sistema, e eu ficaria muito desconfortável ao usar um shell não padrão ou não amplamente implementado em servidores de produção e / ou com acesso à Internet.

O ponto é que (quase) todo shell tem recursos de script / programação mais ou menos poderosos que, associados a devoração e expansão, podem resultar em efeitos colaterais muito inesperados (por exemplo: veja shellshok, por exemplo).

Além disso, já é muito difícil dominar uma única shell bem documentada (como bash), e muito menos usar vários shells diferentes ...

    

Answer 2

Devo alterar meu shell padrão

Sua pergunta e a declaração variam um pouco, já que você está alterando o shell para raiz em seus servidores de produção. Eu sugeriria que a resposta é não, com base em minhas experiências.

Impacto na segurança

Existe risco. Você introduziu um novo comportamento em qualquer coisa que possa potencialmente gerar um shell. Vulnerabilidades que não se aplicam ao bash podem se aplicar ao seu shell personalizado. Você teria que pesquisar isso. Espero que o fish seja pelo menos suportado pela sua distro do SO e você não esteja instalando manualmente.

Impacto operacional

Alterar o shell padrão do root está causando problemas. Você deve configurar sistemas de teste e induzir problemas que exijam o modo de usuário único e qualquer outro cenário de falha que seus planos DR / bakup locais / remotos não considerem. Você pode achar que sua substituição de shell funciona sem problemas, mas você teria que considerar todos os cenários de falha.

Se eu estivesse seguindo esse caminho, eu proporia essa ideia ao meu provedor de suporte ao sistema operacional e começava seus pensamentos e experiências primeiro, se eu realmente sentisse a necessidade de fazer isso. Sou minimalista e a experiência me diz para manter as coisas tão simples e padronizadas quanto possível, especialmente em ambientes com receita ou impacto contratual de SLA.