melhor prática para permissão de acesso aos usuários para o apache tomcat

Question

Eu tenho uma caixa de Linux sendo compartilhada por vários desenvolvedores. Eles querem implantar seus arquivos war no apache tomcat que em local compartilhado (/ opt / tomcat).

Como eles não têm acesso ao sudo, eu tenho que mudar a permissão da pasta para o diretório do tomcat.

estrutura de diretórios em /opt/tomcat is -

bin/

conf/

lib/

logs/

temp/

webapps/

work/

Quais são as melhores práticas na situação acima - A permissão de acesso mais adequada ao usuário? Por enquanto, mudei a permissão para o 777 para webapps e logs.

Obrigado

    

Answer 1

Eu faço assim:

Colocamos o usuário do tomcat como o proprietário da pasta do tomcat:

# chown -R tomcat:tomcat /opt/tomcat

Os usuários podem não modificar a configuração do tomcat:

# chmod -R g+r /opt/tomcat/conf

Os usuários podem modificar as outras pastas:

# chmod -R g+w /opt/tomcat/logs
# chmod -R g+w /opt/tomcat/temp
# chmod -R g+w /opt/tomcat/webapps
# chmod -R g+w /opt/tomcat/work

Ative o sticky-bit para novos arquivos mantenha as permissões definidas:

# chmod -R g+s /opt/tomcat/conf
# chmod -R g+s /opt/tomcat/logs
# chmod -R g+s /opt/tomcat/temp
# chmod -R g+s /opt/tomcat/webapps
# chmod -R g+s /opt/tomcat/work

Por fim, adicionamos o grupo do tomcat que queremos para os usuários que podem usar o tomcat:

# usermod -a -G tomcat MIUSER

    

Answer 2

A seção Non-Tomcat settings do tutorial de segurança do Tomcat fornece informações úteis sobre esse tópico. Veja aqui:

• Tomcat 7: link
• Tomcat 8: link
• Tomcat 9: link

Tomcat should not be run under the root user. Create a dedicated user for the Tomcat process and provide that user with the minimum necessary permissions for the operating system. For example, it should not be possible to log on remotely using the Tomcat user.

File permissions should also be suitably restricted. Taking the Tomcat instances at the ASF as an example (where auto-deployment is disabled and web applications are deployed as exploded directories), the standard configuration is to have all Tomcat files owned by root with group Tomcat and whilst owner has read/write privileges, group only has read and world has no permissions. The exceptions are the logs, temp and work directory that are owned by the Tomcat user rather than root. This means that even if an attacker compromises the Tomcat process, they can't change the Tomcat configuration, deploy new web applications or modify existing web applications. The Tomcat process runs with a umask of 007 to maintain these permissions.

    

Answer 3

Você precisa seguir o princípio do menor privilégio . O servidor (provavelmente www-data , mas você precisa verificar) precisa ser capaz de ler a maioria dos arquivos (digamos todos) e escrever apenas nos logs. Os desenvolvedores da web podem gravar onde precisam. Defina o bit adesivo nos diretórios para que apenas o proprietário de um arquivo possa excluí-lo.

Na prática, você precisa criar um grupo (por exemplo, webdev ) e adicionar todos os desenvolvedores e o servidor a ele ( usermod -aG webdev <user> ou usermod -A webdev <user> , dependendo do seu sabor no Linux). chown todos os arquivos e diretório para o usuário do servidor web, chmod todos os diretórios para 500 e todos os arquivos para 400 (exceto em bin onde os executáveis também precisam ser 500).

Conceda permissões de gravação em /opt/tomcat ao grupo (que seria 570) e defina o bit adesivo para que possam remover apenas os arquivos que possuem (chmod 1570). Conceda a permissão de gravação do servidor para os logs e leia as permissões para os desenvolvedores (0740 para a pasta, 0640 para os arquivos, o bit pegajoso provavelmente não é necessário e nunca conceda a ele para um arquivo, apenas as pastas, pois ele tem um significado diferente (execute com as permissões do proprietário quando o arquivo é executável)).

Em seguida, você precisará conceder permissões de gravação (1570) a webdev em alguns dos diretórios. Você precisará de algumas tentativas e erros aqui, e isso pode depender do aplicativo. Essas pastas devem ser 1570, enquanto outras podem ser 0500).

Os desenvolvedores precisarão conceder acesso de leitura em seus arquivos ao grupo para que o servidor possa lê-los (ou seja, 640) e também executar nos diretórios (750).

    

Answer 4

Eu acho que a resposta aceita pelo @ intropedro é boa. Vale ressaltar que usar um instalador de pacotes pode economizar muita dor de cabeça - pelo menos para o Tomcat 7 no Ubuntu apt-get install tomcat7 produz um conjunto mais "padrão" de diretórios de instalação:

• /etc/tomcat7 para arquivos de configuração,
• /var/lib/tomcat7 para bibliotecas principais e
• /usr/share/tomcat7 para recursos compartilhados.

Todas as permissões são configuradas corretamente com o princípio de menor privilégio, de forma que adicionar usuários ao grupo tomcat7 é suficiente para permitir a implantação. Além disso, o servidor tomcat é configurado como um serviço que pode ser iniciado e interrompido como outros (por exemplo, sudo service tomcat start ou alternativamente /etc/init.d/tomcat start ). O Tomcat inicia na reinicialização automaticamente e há um comando "restart". Tenho certeza de que há um pacote yum equivalente para os usuários do RHEL / CentOS. (E sim, há um instalador de homebrews para instalações OSX locais).

Se você estiver com problemas, há um bom utilitário em /usr/share/bin chamado configtest.sh que informa se há permissões ou outros erros. Note, há um bug que abre que sugere adicionar alguns links simbólicos .

Ainda estamos executando o Ubuntu trusty (14.04); para aqueles que executam versões mais recentes, acredito que há um repositório do Tomcat 8 apt-get.