É comum instalar o zsh nos servidores de produção? [fechadas]

Question

A pergunta pode não ser clara e ampla, mas qualquer resposta, por mais curta ou ampla que seja, é muito apreciada.

Algum tempo atrás, pedi para instalar o zsh em nosso servidor de produção. Minhas empresas de administração responderam que isso não pode ser feito, já que isso é produção, não servidor de desenvolvimento.

Eu usei zsh & oh-my-zsh nos últimos 5 anos e estou muito ligado a ele, o zsh torna meu trabalho mais fácil e rápido. Mas não foi o argumento suficiente.

Eu não sou strong em questões de segurança ou outras que podem estar envolvidas aqui, é por isso que minhas perguntas são:

1. A instalação do zsh no servidor de produção é inofensiva para o sistema?
2. Você permitiria instalar o zsh neste caso e por quê?
3. Faz sentido restringir usuários com o bash no servidor de produção?

Answer 1

zsh é apenas um shell, ele não inicia nenhum serviço, ele não vem com nenhum comando setuid. Assim, a mera instalação do pacote não fará nada até que alguém ou alguma coisa realmente o use. Como não precisa de nenhum privilégio, qualquer usuário pode instalá-lo sozinho em seu diretório pessoal ou onde quer que tenha acesso.

Se não for qualidade de produção , pode-se argumentar que tornar o shell de login e o usuário admin introduziria algum risco, mas com sua sintaxe muito melhor do que outros shells como bash ou tcsh , eu diria que isso melhoraria consideravelmente as coisas.

Embora seu uso principal seja como um shell interativo, eu diria que escrever scripts em zsh provavelmente criaria scripts mais seguros e confiáveis do que bash scripts (veja quantas pessoas, sem saber, escrevem bash scripts em zsh syntax quando eles esquecem de citar suas variáveis e como a mudança do shebang de #! /bin/bash para #! /bin/zsh consertaria muitos dos bugs em seus scripts).

Em qualquer caso, a instalação de zsh está entre as primeiras coisas que tenho feito em todas as implantações de servidores em todos os lugares em que trabalhei.

No entanto, eu geralmente não faço o shell de login de qualquer usuário por padrão, já que não é incomum que alguns softwares esperem um ambiente centrado no bash.

    

Answer 2

Outras opiniões disponíveis, mas aqui está a minha.

1. Is installing zsh on production server harmless to the system?

A introdução de novos softwares raramente é inofensiva. Por exemplo, ele vem com a necessidade de garantir que quaisquer vulnerabilidades associadas a ele sejam identificadas e corrigidas.

2. Would you allow to install zsh in this case, and why so?

Não. Gostaria que um benefício tangível fosse identificado.

3. Does it make sense to restrict users with bash on production server?

Sim, bash é ótimo :-) E se algum grupo de usuários de nicho na empresa começar a escrever zsh scripts sem que as equipes de suporte mais amplas tenham conhecimento, eles serão eliminados.

    

Answer 3

Na minha experiência, sim, é incomum instalar o zsh em um servidor de produção. Dito isto, trabalho com mais clientes "conservadores" (bancos, administrações, etc.) para que sua milhagem possa variar.

1. O próprio Zsh é inofensivo . É 'apenas outro shell', como bash, ksh, ... No entanto, em muitas empresas, a política de segurança é limitar o máximo possível a superfície de ataque , ou seja, não instale nada a menos que é requerido. Mesmo que o zsh seja inofensivo, sua base de código pode conter bugs . Leia sobre Shellshock se você ainda não sabe sobre isso. :)
   Dito isto, há uma certa clemência por "commodities", como ter vim em vez de apenas vi. Zsh pode se encaixar nessa categoria.

2. Não em produção , não acontecendo. Além de reduzir a superfície de ataque, há também o fato de que você precisará testar duas vezes seus scripts - uma vez com zsh, uma vez com bash. Isso leva tempo e dinheiro.
   

3. Eu não chamaria isso de restrição para bash: há alguma coisa que você pode fazer com o zsh que você não pode fazer com o bash?
   

Nota final: bash é praticamente o padrão da indústria . É o shell padrão para a maioria das distribuições de nível empresarial (RHEL, SUSE, ...), bem como para muitas distribuições muito populares, como Debia, Ubuntun ...
Eu tentei "novos" shells ao longo dos anos: zsh e fish são dois que eu realmente gostei. Para uso doméstico, talvez, no entanto, no trabalho ele seja todo o caminho (e o ksh quando estiver trabalhando com o AIX, etc.). Eu acabo usando o bash em casa também, velhos hábitos são difíceis de morrer.

    

Answer 4

O mesmo que os outros, esta é a minha opinião:

1. Is installing zsh on production server harmless to the system?

Defina 'inofensivo'. Estritamente falando, não causa dano direto. No entanto, qualquer código que esteja em seu sistema de produção é um vetor de ataque em potencial. Nesse sentido, não é verdadeiramente "inofensivo", na medida em que poderia ser usado para um ataque ao sistema. Há também algumas outras maneiras indiretas de causar problemas. O ZSH é um pouco mais ávido por recursos do que o bash, por exemplo, o que poderia importar em um sistema com capacidade próxima.

2. Would you allow to install zsh in this case, and why so?

Dependendo das circunstâncias exatas, talvez já o tenha instalado.

Todos os meus sistemas pessoais têm o ZSH instalado e definido como o shell padrão para todos, incluindo o root. Isso é simplesmente porque estou trabalhando regularmente a partir de um shell local nesses sistemas, e uso ativamente o ZSH em muitos casos.

No entanto, todos os sistemas que administro no trabalho não o possuem. Aproximadamente 95% do trabalho administrativo que faço para eles não envolve me tocar realmente em um shell nesses sistemas (eu faço um lote através do Ansible no trabalho), então não faz sentido fazer de mim um ambiente familiar. Eu também seria muito improvável de instalá-lo em qualquer coisa, mas nossos sistemas de desenvolvimento real, e não há nenhuma chance no inferno que eu iria instalá-lo em qualquer coisa que seja diretamente acessível fora do local.

3. Does it make sense to restrict users with bash on production server?

Eu questionaria a praticidade de permitir que usuários comuns toquem sistemas de produção em todos os casos além de casos muito restritivos que não envolvem acesso real ao shell.

Por exemplo, onde eu trabalho, apenas o departamento de TI e as pessoas diretamente responsáveis pela manutenção de nosso site têm acesso HTTPS aos nossos servidores da Web. O pessoal de TI (inclusive eu) deve fazer login com uma conta especial usada apenas para administração dos servidores da Web e, mesmo assim, eles têm acesso limitado aos sistemas, a menos que estejam no console físico na sala do servidor. Os web designers só têm acesso via SFTP à raiz do site, e nada mais. Dado isso, não há necessidade de nenhum shell, exceto o bash (que é nosso padrão internamente para uso administrativo).

Da mesma forma, para nossos servidores de arquivos internos, somente o departamento de TI tem acesso real ao shell. Outros usuários têm acesso especialmente limitado a determinados diretórios, geralmente permitindo protocolos regulares de servidor de arquivos (SMB, NFS, etc), além de SFTP e, em alguns casos, rsync, mas nenhum deles tem acesso real ao shell, porque eles realmente não precisam isso.