É seguro conceder a propriedade do usuário do Apache de diretórios e arquivos para o Wordpress

Question

Atualmente estou configurando o WordPress em um servidor Ubuntu 12 tudo roda bem, mas há um problema quando se trata de atualizar e carregar automaticamente a mídia via WP, já que o usuário "www-data" do Apache não tem permissão para gravar diretórios. "user1" tem permissão total

Todos os meus diretórios têm permissões de 0755 e arquivos 644

a configuração dos meus diretórios é a seguinte:

/home/user1/public_html

Todos os arquivos e diretórios do WP estão em "public_html"

Para contornar a atualização automática e o envio de mídia, concedi a propriedade do usuário do Apache aos seguintes diretórios

sudo chown www-data:www-data wp-content -R
sudo chown www-data:www-data wp-includes -R
sudo chown www-data:www-data wp-admin -R

Eu gostaria de saber como a segurança é segura e se não é seguro qual seria a melhor solução?

Isso me permitirá manter todos os arquivos e diretórios de propriedade do usuário1 e ainda permitir que o wp possa atualizar e carregar automaticamente a mídia

    

Answer 1

Na minha opinião, se você pode considerar isso seguro (não seguro), depende muito do seu caso de uso, seus usuários e seu ambiente. Deixe-me colocar desta forma: Se você está planejando fornecer hospedagem para clientes pagantes e não acontecer de estar em uma infra-estrutura fechada ou por trás de um sofisticado inacreditável WAF ou IPS , você provavelmente consideraria isso inseguro. Aqui eu não estou me referindo apenas aos diretórios graváveis, mas ao uso de mod_php, o que você parece fazer. Então, novamente, se você está apenas configurando um pequeno webhosting para seus amigos e familiares, espere cerca de dez acessos por semana e realmente não tenha tempo, você provavelmente estará bem (no entanto eu recomendaria usar algum hoster compartilhado disponível, neste caso ).

Alternativas mais seguras executam a execução do PHP de cada usuário sob seus próprios direitos de usuário. Os exemplos mais comuns seriam:

• suPHP , que é bastante seguro, mas lento como correio tradicional.
• Apache + MPM ITK , que é bastante simples de configurar, mas não tão amplamente testado (em contraste com MPM Worker ou MPM Prefork ). Pessoalmente, eu não usaria isso em um ambiente de produção.
• Um ambiente FastCGI + PHP, com mod_fastcgi ou mod_fcgid .

Dependendo de seus usuários / ambiente / ..., eu recomendaria a bloquear sua caixa. No cenário FastCGI, você deve usar o chroot e pode endurecer ainda mais o sistema usando aprimoramentos de segurança do Linux (por exemplo, 1 , 2 , 3 )

Mas mais uma vez: você pode realmente gastar bastante tempo com isso. Considere usar um ambiente hospedado compartilhado de um bom hospedeiro, que fará isso por você antes de colocar uma caixa insegura na natureza.

    

Answer 2

Tenho quase certeza de que respondi a isso antes, mas não consigo encontrar a pergunta para o link.

Você não deveria estar perguntando se é seguro se você fizer nnn. A segurança nunca é um valor binário e você quase sempre precisa aplicar uma análise mais detalhada. A pergunta que você deve fazer é fazer mais ou menos seguro do que a alternativa.

Sim, alterar a propriedade de arquivos para que o Apache possa gravar no site aumenta o potencial para problemas, mas isso simplesmente não é o único fator.

Uma preocupação muito maior se você não alterar a propriedade, você estará disposto a se esforçar para manter o aplicativo da web atualizado e corrigido. Se você não tiver as ferramentas ou a capacidade de mantê-lo atualizado e corrigido usando apenas a CLI, isso é um problema de segurança potencialmente muito maior, então os problemas que você pode ter como resultado das permissões do sistema de arquivos mais permissivas .

Eu não tenho um link / referência, mas acredito que li em algum lugar que muitas coisas estão comprometidas porque os patches para vulnerabilidades conhecidas não são aplicados em tempo hábil. OTOH, permissões de sistema de arquivos fracas geralmente só entram em jogo como resultado de um bug / problema em um aplicativo da web.

Idealmente, se você tem um requisito para segurança paranoica extremamente strong, você teria permissões extremamente bloqueadas e aplicativos muito atualizados, mas se eu tivesse que escolher um, geralmente tentaria ter todos os patches instalados .

Você, obviamente, precisa tomar sua decisão com base nos riscos potenciais e uma compreensão realista de como estará atualizando e mantendo o sistema.

    

Answer 3

EDIT: solução removida que todos dizem ser "ruim".

Deixando este no lugar, que todos escolheram ignorar porque não conseguiram ler além das cinco primeiras linhas:

Aqui está a alternativa que estou experimentando atualmente:

$ chown someuser:other-users somefolder
$ chmod 770 somefolder

Isso dá ao proprietário (algum usuário) e a todos os membros do grupo "outros usuários" (a quem "algum usuário" decide conceder permissões) permissões de leitura / gravação / execução. Faça o chmod 660 para arquivos.

    

Answer 4

Porque você config executando sob mod_php. Você tem que chown usuário pelo cron a cada 1 minuto.

No entanto, você deve configurar a execução sob suphp para o seu problema