Dev background, seguro ter arquivos PHP de propriedade do usuário root mas diferente do Apache?

Question

Eu sou de um background de programação e fui colocado no gerenciamento de um servidor Linux no trabalho por causa de uma emergência com o nosso administrador do reg sys. É confiável ou seguro ter nossos arquivos PHP de propriedade do root, mas o Apache obviamente rodando no Fedora 8 como apache?

O Apache recebe direitos de leitura e, em casos menores, como o diretório de uploads, grava privilégios pelo chmod 777 para essa pasta de uploads.

Estamos executando o mod_security, mas imaginamos se havia alguma prática melhor. Estou sozinho nisso pelas próximas 2-3 semanas, enquanto o administrador do sistema está se recuperando.

    

Answer 1

Qual grupo possui os arquivos PHP? Sua menção ao 777 sugere que é a 'roda' ou 'adm' ou algum outro grupo privilegiado, de modo que a única maneira de o Apache ver qualquer arquivo é quando esse arquivo é legível por todos. Ou mundialmente gravável, no caso da pasta de uploads.

Isso certamente não é uma coisa boa - embora a gravidade dependa de tudo o que você está executando no servidor (tanto na Web quanto de outra forma), se algum dos scripts PHP contém credenciais de texto simples, etc.

Se, por outro lado, os arquivos são de propriedade do gid sob o qual o Apache é executado, então você está em uma forma um pouco melhor. Você poderia, em teoria, fazer um chmod -R o-rwx no DocumentRoot para remover todos os privilégios "mundiais", e tudo provavelmente seria legal e seguro e suas páginas da Web ainda funcionariam.

Mas há a questão dos bits setuid. Não tenho certeza se o script PHP de propriedade da raiz com o setuid ativado pode, na prática, ser explorado para propósitos maliciosos, mas eu não gostaria de um no meu servidor web.

E mesmo que o setuid não seja uma preocupação, a propriedade-raiz ainda não tem o cheiro certo para mim.

    

Answer 2

Se você estiver executando o PHP de forma que ele seja executado como usuário do Apache (ou seja, "www-data" em sistemas debian, "nobody" em hosts compartilhados CentOS + cPanel, ...) então o dono do arquivo não realmente importa a partir do PoV de ser chamado via Apache - PHP e, portanto, o script sempre será executado como o usuário do Apache não o usuário que possui o arquivo.

Se você executar o PHP como um módulo, este é quase certamente o caso.

Se você tem o PHP configurado para executar scripts como o usuário específico (via suphp, suexec ou similar - você pode estar fazendo isso se você executar o PHP através dos métodos CGI ou FastCGI) então ter arquivos de script pertencentes a um usuário privilegiado é uma ideia muito má.

Quanto às permissões "777", isso também deve ser evitado, especialmente se você não for o único usuário no servidor. Eu, ao invés disso, me certificaria de que o diretório é de propriedade do usuário. O Apache estará executando o PHP as e usará "700" (ou em um grupo em que este usuário também esteja e use o 770). Para maior paranóia, se os seus scripts sempre souberem o nome do arquivo que desejam e não precisarem ler a listagem de diretórios, não permitirão a permissão de execução no diretório também.

Além disso, nunca tem scripts de escrita mundial. As configurações padrão do suPHP, na verdade, protegem você contra isso, recusando-se a executar scripts com permissões que sejam graváveis em todo o mundo (ou em diretórios).

Como regra geral, evito usar permissões menos restritivas no desenvolvimento do que seria necessário em um ambiente ao vivo disponível publicamente. Isso evita que o perms seja acidentalmente permissivo ao promover o código, e evita a introdução de bugs onde seu código assume um acesso mais permissivo do que o permitido no ambiente ao vivo.

    

Answer 3

777 permissões são geralmente consideradas uma Idéia Ruim para scripts PHP. Se os arquivos forem de propriedade do usuário root, você provavelmente desejará que eles sejam, pelo menos, de propriedade do grupo apache, para que eles não precisem ser legíveis se não for o que você deseja. Dessa forma, você pode dimensionar de volta para 770 permissões. (Parece um pouco estranho para os scripts pertencerem ao root, também.)

Para o futuro, talvez você também queira definir o bit no diretório para garantir que novos arquivos adicionados a esse diretório sejam chgrp'd automaticamente para qualquer grupo que possua o diretório com o seguinte comando:

chmod 2775 / caminho / para / diretório

Dessa forma, você pode (por exemplo) definir o proprietário do grupo dos diretórios que está sendo veiculado para o apache, e o novo conteúdo adicionado será automaticamente incluído no grupo do Apache e, portanto, legível sem a necessidade de conceder permissões legíveis ao mundo. (assumindo umask apropriada).