Quais são as permissões unix perfeitas para diretórios comuns de projetos da web?

Quais são as permissões mínimas perfeitas no formato octal para os seguintes em um aplicativo da Web escrito?

1. Um diretório no qual os arquivos estáticos carregados pelo usuário (images / swf / js files) residirão
2. Um diretório em que os arquivos estáticos carregados pelo administrador (arquivos images / swf / js) residirão
3. Um diretório em que residem as bibliotecas usadas no aplicativo
4. Um diretório em que residem os scripts executáveis ​​/ navegáveis ​​do servidor
5. Um diretório em que os arquivos já existentes (txt ou xml) serão editados por código no lado do servidor

Aqui estão as minhas sugestões e justificativas

1. 555, todos podem ler e escrever, ninguém pode executar
2. 544, o proprietário sozinho pode escrever, todo mundo só pode ler, ninguém pode executar
3. 000, ninguém precisa ler, escrever nem executar, será usado apenas pelo servidor web?
4. 661, o proprietário pode ler, escrever, todos os outros só podem executar
5. 600, o proprietário pode ler, escrever (pode não ser necessário), ninguém mais pode fazer nada

Agora estou interessado em duas coisas:

1. Existe algo comumente usado em aplicativos baseados na Web que eu perdi na primeira lista?
2. Há algo de que você não concorda na segunda lista, qual é a sua alternativa e por que é melhor?

Presumindo que um 'aplicativo da Web' seja executado em um servidor (como apache, nginx, etc) e esteja escrito em alguma linguagem de script dinâmica (como PHP, Ruby, etc), você tem um mal-entendido sobre quem é o 'usuário'.

O usuário não é a pessoa que está logada no seu aplicativo - isso e sua função no aplicativo (administrador, etc) são completamente irrelevantes para o cenário. O usuário é o usuário do sistema linux no qual o processo é executado. O código do seu site é executado como apenas um usuário - pode ser o usuário do seu servidor da web (o que não é realmente uma coisa boa) ou pode ser um usuário específico do seu site (o que é muito melhor).

No linux, os usuários pertencem a grupos - podemos adicionar um usuário a outro grupo e atribuir privilégios a esse grupo.

Uma boa configuração fará com que seu servidor seja executado como um usuário (vamos chamar esse usuário de 'servidor da web') e sua linguagem de script dinâmica (por exemplo, via FastCGI) como seu próprio usuário (um usuário por site - vamos chamar nosso primeiro usuário de 'site1') .

Para servir seus arquivos, o servidor da web precisa de acesso a eles e a linguagem de script precisa de acesso a eles. Isso significa que 'site1' e 'webserver' precisam poder ler seus arquivos. Apenas um deles, no entanto, pode 'possuir' os arquivos. O proprietário é o 'usuário' (em usuário, grupo, outro). Também precisamos da nossa linguagem de script para poder gravar no diretório (e ler os arquivos que ele escreveu). O usuário 'site1', portanto, precisa de permissões de leitura e gravação. Como queremos que as permissões de grupo e outras sejam o mais restritivas possível, nosso 'proprietário' será 'site1' e as permissões de usuário correspondentes serão de leitura e gravação.

Como não podemos especificar as permissões para o nosso servidor da web como outro 'usuário', adicionaremos 'servidor da web' ao grupo 'site1' (você pode, é claro, criar um grupo diferente com 'site1' e 'servidor da web'). os membros desse grupo receberão as mesmas permissões.As permissões mais relaxadas (do usuário, grupo e outro conjunto) serão aplicadas a qualquer usuário para determinar suas permissões.

Vale ressaltar que uma boa configuração não deve exigir que os arquivos tenham permissões de execução para um idioma dinâmico. Os arquivos não são executados diretamente, mas são lidos em um intérprete - somente permissões de leitura são necessárias para executar um script típico (que não escreve nada).

A permissão 'execute' nos diretórios tem um significado diferente - permite a travessia sem poder ler o conteúdo. Para poder ler um arquivo em um diretório, um usuário deve ter permissões de 'execução' em TODOS os diretórios acima dele.

Para um aplicativo Web, todo arquivo deve ter permissões de leitura por seu proprietário - caso contrário, é um arquivo sem sentido. Se um usuário ou administrador carrega arquivos (por meio de seu aplicativo da web), o 'proprietário' (ou seja, o idioma dinâmico) precisa de permissões de gravação. Uma configuração eficiente tentará veicular arquivos estáticos diretamente através do servidor da Web, pois os idiomas dinâmicos tendem a ser lentos na leitura de arquivos grandes e no eco do conteúdo. O servidor web, portanto, precisa de acesso de leitura aos seus arquivos estáticos.

Portanto, as permissões mínimas de arquivo podem ser:

• Um arquivo em um diretório em que o usuário enviou arquivos estáticos (arquivos images / swf / js) residirá: 640
• Um arquivo em um diretório em que o administrador fez o upload de arquivos estáticos (arquivos images / swf / js) residirá: 640
• Um arquivo em um diretório em que as bibliotecas usadas no aplicativo residem: 400 (ou 440)
• Um arquivo em um diretório em que residem os scripts executáveis ​​/ navegáveis ​​do servidor: 400 (ou 440)
• Um arquivo em um diretório em que os arquivos já existentes (txt ou xml) serão editados por código no lado do servidor: 640 ou 600
  • (depende se o servidor da web exibirá esses dados, não modificados às vezes)

Enquanto, as permissões mínimas de diretório podem ser:

• Um diretório no qual os arquivos estáticos carregados pelo usuário (arquivos images / swf / js) residirão: 750
• Um diretório no qual os arquivos estáticos enviados pelo administrador (arquivos images / swf / js) residirão: 750
• Um diretório em que residem as bibliotecas usadas no aplicativo: 500 (ou 550) [deve ser 510, pelo menos]
• Um diretório em que residem os scripts executáveis ​​/ navegáveis ​​no servidor: 500 (ou 550) [deve ser 510, pelo menos]
• Um diretório em que os arquivos já existentes (txt ou xml) serão editados por código no lado do servidor: 750 ou 700
  • (depende se o servidor da web fornecerá arquivos daqui, sem modificação às vezes)

Mais uma vez - seu servidor da web deve ter permissões de 'execução' em todos os diretórios acima daquele que ele precisa acessar - portanto, mesmo que o servidor da web não atenda arquivos de um determinado diretório, devemos conceder permissões de execução.

É bastante comum dar ao servidor da Web acesso de leitura à maioria dos arquivos (altere esses de 500 para 550). As permissões 'um pouco seguras' padrão são geralmente 755 para diretórios e 644 para arquivos - sem permissões de execução, todos podem ler e apenas o usuário pode escrever - você notará que a grande maioria dos arquivos em um sistema Linux tem essas permissões.

Lembre-se de que as outras permissões se referem a qualquer usuário do sistema que não seja o proprietário ou no grupo (ou seja, todos os demais usuários do sistema). Manter suas 'outras' permissões restritivas é bom, porque esses usuários são desconhecidos - você não lhes deu permissão explicitamente. As outras permissões geralmente são as mais fáceis de tirar proveito em um sistema comprometido (por exemplo, um dos motivos pelos quais / tmp é um alvo comum).

No contexto acima, não acho que suas duas últimas perguntas sejam relevantes. Defina suas permissões de diretório para 550 (e permissões de arquivo para 440) e conceda ao usuário permissões de gravação para os diretórios em que seu aplicativo estiver gravando (ou seja, diretório: 750; arquivo: 640).

(Você obviamente precisará de permissões de gravação para fazer upload dos arquivos - mas, se desejar, poderá removê-los posteriormente - sem dúvida, se alguém estiver gravando em um diretório no qual apenas o proprietário possa escrever - sua conta foi comprometida - qual é uma dos motivos para manter permissões restritivas).

É normal ter o conjunto mínimo de permissões para realizar o trabalho. Se seu servidor da web e usuários compartilham um grupo comum, você pode remover a necessidade de conceder qualquer acesso o. Permissões também estão relacionadas aos usuários. Você parece ter entendido mal as permissões octais.

1. 555 r-xr-xr-xnão é rw-rw-rw. Como é um diretório, para criar / excluir arquivos que você precisa xdefinir, o 750 rwxr-x---seria um bom lugar para começar. Isso permite que o usuário proprietário do diretório adicione / remova arquivos e que todos no grupo comum os acessem.
2. O mesmo que 1. acima.
3. Se eles são arquivos realmente estáticos, o número 050 daria ao servidor da Web acesso, no entanto, para criar os arquivos em primeiro lugar, o mínimo seria 750.
4. O mesmo que 3 acima.
5. 070 seria o mínimo para permitir que o servidor da web leia e altere os arquivos, mas os arquivos precisam ser criados para que o 770 seja provavelmente mais realista.

Em geral, usaria-se o modo 0755, 0775 ou 2775 nos diretórios (o bit SGID nos diretórios, para BSD e Linux, se o sistema de arquivos estiver montado com a semântica BSD, fará com que a associação de grupo de novos arquivos corresponda às configurações do diretório pai e não ao diretório GID padrão do criador do arquivo). Isso permite a todos os usuários percorrer (chdir para dentro e através) e ler (executar o comando ls ou executar as chamadas do sistema readdir / read) nos diretórios em questão. As alternativas adicionam opções de grupo / gravação e, como observado, o bit SGID, nos diretórios, podem ajudar a manter todos os arquivos e subdiretórios associados a um grupo adequado.

Para arquivos, usaria-se normalmente 0644 ou possivelmente 0664 (legível pelo mundo e gravável em grupo ou não). Obviamente, para scripts CGI e binários, é necessário adicionar o x-bit; e para algumas situações especiais, com binários extremamente bem testados, pode-se adicionar bits SUID ou SGID. Normalmente, o UNIX e o Linux ignoram o bit SUID / SGID nos scripts e apenas respeitam sua semântica para binários executáveis ​​compilados nativos. No entanto, você pode estar executando o site em algo como o Apache com algum módulo como o "setuidhack", que pode ser usado para fazer o servidor da Web honrar os bits do SUID / SGID, mesmo em scripts interpretados. (Isso é feito pelo daemon HTTP stat () em cada arquivo e usando seu próprio código fork () / execve () personalizado, interpolando a string do interpretador corretamente no vetor execve () em vez de simplesmente passar o executável '

Essas são apenas as diretrizes mais gerais. Eles não são "perfeitos" para todas as situações e você deve definitivamente consultar os documentos do seu servidor da Web e qualquer aplicativo ou estrutura da Web que esteja instalando e configurando ... e você provavelmente deseja consultar um especialista em segurança do UNIX antes de expor qualquer um dos seus arquivos, códigos ou servidores à Internet pública.