Quais devem ser as permissões para arquivos de sites?

Question

Eu bloqueei meu servidor web CentOS para que o root não possua SSH. Meus diretórios de sites e arquivos são de propriedade de root. Então, quando eu carrego arquivos, é um processo de duas etapas. Eu os carrego com o WinSCP para o meu diretório / home. Então eu SSH e movo os arquivos para onde eles precisam estar.

Existe uma maneira melhor de fazer isso? Os arquivos de website devem pertencer a um usuário não-root?

Ao analisar outras questões, este parece indicar que eu deveria tornar meu usuário parte de um webusers grupo, e esse grupo possui todos os arquivos do site. Essa é a situação típica? Há algum problema com este procedimento de segurança?

    

Answer 1

tl; dr: root:root rwxr-xr-x , a menos que você precise gravar acesso ao diretório, em cujo caso root:www-data rwxrwxr-x , a menos que você precise proteger segredos (por exemplo, senhas de banco de dados) no diretório da web, Nesse caso, root:www-data rwxr-x--- , a menos que você precise de acesso de gravação e , é necessário proteger os segredos. Nesse caso, root:www-data rwxrwx--- .

Sim, idealmente, os arquivos do seu website devem ser de propriedade do root. Isto é por causa do princípio do menor privilégio: com relação às permissões, o root pode fazer qualquer coisa de qualquer maneira, então ter algo pertencente ao root realmente não confere nenhum privilégio adicional no root - ele meramente tira privilégios de outras contas. Isso é uma coisa boa.

Caso você não saiba qual é o principal privilégio, é basicamente: dar aos processos as permissões mínimas necessárias, e não mais, porque você quer limitar os danos se e quando o processo receber o pwd e o O atacante começa a jogar com as novas permissões que ele acabou de herdar do processo pwd. Esta é a motivação para o SELinux , daemons tendo a habilidade de privilégios de descarte , recursos do Linux , chroot jails ¹ - todas essas coisas são projetadas para limitar os danos que um processo pode causar tomado por um invasor.

No cenário típico, você deseja que todos tenham privilégios de leitura e forneçam somente privilégios de gravação de raiz. Nesse cenário, se você definiu ou não que seu diretório da Web pertence ao grupo www-data ² não importa, porque ele obterá r-x permissões de qualquer forma.

No entanto, existem cenários mais complicados que exigem que você diferencie o que o Apache obtém acesso e o que os meros humanos cutucando na árvore de diretórios têm acesso. É aqui que entra a coisa www-data -como grupo. Permite, por exemplo conceder permissão de gravação para o Apache, mas não para usuários regulares. Ou se você, por exemplo precisa proteger as senhas do banco de dados, então você pode negar todas as permissões de leitura, mas ainda permitir que o Apache veja o conteúdo.

¹ : esta é uma ligeira deturpação. A chamada de sistema chroot() na verdade nunca foi projetada como um recurso de segurança, e as jaulas chroot foram inventadas depois que chroot() apareceu originalmente. Por causa disso, eles têm algumas limitações - por exemplo, se você for root, você pode sair de uma jaula de chroot . O mesmo se aplica aos contêineres do Linux (Docker, systemd-nspawn , estou olhando para você). Coisas como Cadeias BSD e Solaris Zonas basicamente pegaram o conceito de jail chroot e as fizeram realmente funcionar com segurança - então, a não ser que, por exemplo, vulnerabilidades de segurança do kernel, você não pode sair de uma cadeia BSD, mesmo se você estiver dentro dela .

² : o nome do grupo do servidor da web pode variar de distribuição para distribuição. É www-data no Debian e derivados, mas eu não sei sobre o que a família RHEL faz.

    

Answer 2

Posso pensar rapidamente em pelo menos dois motivos para não ter o conteúdo do seu site de propriedade do root:

• Algumas ferramentas, como o suexec , são projetadas para executar scripts e semelhantes sob o usuário que possui o arquivo . Se você não está usando isso, então você não deve ativá-lo, e além disso eu acredito que o suexec se recusa a executar coisas sob privilégios de usuários especiais como root, mas como uma defesa em profundidade, você não deve ter os arquivos possuídos pelo root em primeiro lugar.
• Você precisa de acesso root para manter o site. Não há necessidade de fazer com que a manutenção do site exija mais privilégios do que o necessário. Tornar-se root toda vez que você mantiver o site aumenta a exposição da conta root e aumenta o potencial de danos acidentais que você pode causar ao cometer um erro enquanto mantém o site.

Answer 3

Negar login root é uma boa decisão, root é um alvo popular em ataques ssh de força bruta.

Root parece uma escolha usual para o proprietário do conteúdo da web, eu uso uma conta de usuário comum. Onde o trabalho de desenvolvimento é compartilhado, um grupo webdeveloper faz sentido, onde existe apenas um único desenvolvedor ou a conta do desenvolvedor é compartilhada entre vários desenvolvedores, não há necessidade de um grupo especial. .