Quais permissões os arquivos/pastas do meu site devem ter em um servidor Linux?

Ao decidir quais permissões usar, você precisa saber exatamente quem são seus usuários e o que eles precisam. Um servidor web interage com dois tipos de usuário.

Os usuários autenticados têm uma conta de usuário no servidor e podem receber privilégios específicos. Isso geralmente inclui administradores de sistema, desenvolvedores e contas de serviço. Eles geralmente fazem alterações no sistema usando SSH ou SFTP.

Os usuários anônimos são os visitantes do seu site. Embora eles não tenham permissões para acessar os arquivos diretamente, eles podem solicitar uma página da Web e o servidor da Web age em seu nome. Você pode limitar o acesso de usuários anônimos tomando cuidado com as permissões do processo do servidor web. Em muitas distribuições Linux, o Apache é executado como www-datausuário, mas pode ser diferente. Use ps aux | grep httpdou ps aux | grep apachepara ver qual usuário o Apache está usando em seu sistema.

Notas sobre permissões do Linux

Linux e outros sistemas compatíveis com POSIX usam permissões unix tradicionais. Há um excelente artigo na Wikipedia sobre permissões do sistema de arquivos, então não vou repetir tudo aqui. Mas há algumas coisas que você deve estar ciente.

Os scripts interpretados de bit de execução
(por exemplo, Ruby, PHP) funcionam bem sem a permissão de execução. Apenas binários e scripts de shell precisam do bit de execução. Para percorrer (entrar) em um diretório, você precisa ter permissão de execução nesse diretório. O servidor da web precisa dessa permissão para listar um diretório ou servir qualquer arquivo dentro dele.

Permissões de novo arquivo padrão
Quando um arquivo é criado, ele normalmente herda o ID do grupo de quem o criou. Mas às vezes você quer que novos arquivos herdem o ID do grupo da pasta onde eles foram criados, então você habilitaria o bit SGID na pasta pai.

Os valores de permissão padrão dependem de sua umask. O umask subtrai permissões de arquivos recém-criados, então o valor comum de 022 resulta em arquivos sendo criados com 755. Ao colaborar com um grupo, é útil alterar seu umask para 002 para que os arquivos que você cria possam ser modificados pelos membros do grupo. E se você quiser personalizar as permissões dos arquivos carregados, você precisa alterar o umask para apache ou executar chmod após o upload do arquivo.

O problema com 777

Quando você chmod 777acessa seu site, você não tem segurança alguma. Qualquer usuário do sistema pode alterar ou excluir qualquer arquivo do seu site. Mas, falando mais sério, lembre-se de que o servidor da web age em nome dos visitantes do seu site, e agora o servidor da web pode alterar os mesmos arquivos que está executando. Se houver vulnerabilidades de programação em seu site, elas podem ser exploradas para desfigurar seu site, inserir ataques de phishing ou roubar informações de seu servidor sem que você saiba.

Além disso, se o seu servidor for executado em uma porta bem conhecida (o que deve impedir que usuários não root gerem serviços de escuta acessíveis por todo o mundo), isso significa que seu servidor deve ser iniciado pelo root (embora qualquer servidor sensato seja descartado imediatamente para uma conta menos privilegiada assim que a porta estiver vinculada). Em outras palavras, se você estiver executando um servidor web onde o executável principal faz parte do controle de versão (por exemplo, um aplicativo CGI), deixando suas permissões (ou, nesse caso, as permissões do diretório que o contém, pois o usuário pode renomear o executável) em 777 permite que qualquer usuário execute qualquer executável como root.

Defina os requisitos

• Os desenvolvedores precisam de acesso de leitura/gravação aos arquivos para que possam atualizar o site
• Os desenvolvedores precisam ler/escrever/executar em diretórios para que possam navegar
• Apache precisa de acesso de leitura a arquivos e scripts interpretados
• Apache precisa de acesso de leitura/execução a diretórios que podem ser servidos
• Apache precisa de acesso de leitura/gravação/execução a diretórios para conteúdo carregado

Mantido por um único usuário

Se apenas um usuário for responsável pela manutenção do site, defina-o como o proprietário do usuário no diretório do site e conceda ao usuário permissões rwx completas. O Apache ainda precisa de acesso para que possa servir os arquivos, então defina www-data como o proprietário do grupo e dê ao grupo permissões rx.

No seu caso, Eve, cujo nome de usuário pode ser eve, é o único usuário que mantém contoso.com:

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/

ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Se você tiver pastas que precisam ser graváveis ​​pelo Apache, basta modificar os valores de permissão para o proprietário do grupo para que www-data tenha acesso de gravação.

chmod g+w uploads

ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

O benefício dessa configuração é que fica mais difícil (mas não impossível*) para outros usuários no sistema bisbilhotar, já que apenas os proprietários do usuário e do grupo podem navegar no diretório do seu site. Isso é útil se você tiver dados secretos em seus arquivos de configuração. Tenha cuidado com o seu umask! Se você criar um novo arquivo aqui, os valores de permissão provavelmente serão padronizados para 755. Você pode executar umask 027para que os novos arquivos sejam padronizados para 640 ( rw- r-- ---).

Mantido por um grupo de usuários

Se mais de um usuário for responsável pela manutenção do site, você precisará criar um grupo para usar na atribuição de permissões. É uma boa prática criar um grupo separado para cada site e nomear o grupo com o nome desse site.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

No exemplo anterior, usamos o proprietário do grupo para dar privilégios ao Apache, mas agora isso é usado para o grupo de desenvolvedores. Como o proprietário do usuário não é mais útil para nós, configurá-lo como root é uma maneira simples de garantir que nenhum privilégio seja vazado. O Apache ainda precisa de acesso, então damos acesso de leitura ao resto do mundo.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com

ls -l
drwxrwsr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Se você tiver pastas que precisam ser graváveis ​​pelo Apache, você pode tornar o Apache o proprietário do usuário ou o proprietário do grupo. De qualquer forma, ele terá todo o acesso de que precisa. Pessoalmente, prefiro torná-lo o proprietário do usuário para que os desenvolvedores ainda possam navegar e modificar o conteúdo das pastas de upload.

chown -R www-data uploads

ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Embora esta seja uma abordagem comum, há uma desvantagem. Como todos os outros usuários do sistema têm os mesmos privilégios no seu site que o Apache, é fácil para outros usuários navegarem em seu site e lerem arquivos que possam conter dados secretos, como seus arquivos de configuração.

Você pode ter seu bolo e comê-lo também

Isso pode ser melhorado ainda mais. É perfeitamente legal para o proprietário ter menos privilégios do que o grupo, então, em vez de desperdiçar o proprietário do usuário atribuindo-o ao root, podemos tornar o Apache o proprietário do usuário nos diretórios e arquivos do seu site. Esta é uma reversão do cenário de mantenedor único, mas funciona igualmente bem.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com

ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Se você tiver pastas que precisam ser graváveis ​​pelo Apache, basta modificar os valores de permissão para o proprietário do usuário para que www-data tenha acesso de gravação.

chmod u+w uploads

ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

Uma coisa a ter cuidado com esta solução é que o proprietário do usuário de novos arquivos corresponderá ao criador em vez de ser definido como www-data. Portanto, quaisquer novos arquivos que você criar não poderão ser lidos pelo Apache até que você os execute.

* Separação de privilégios do Apache

Mencionei anteriormente que é realmente possível para outros usuários bisbilhotar seu site, não importa que tipo de privilégios você esteja usando. Por padrão, todos os processos do Apache são executados com o mesmo usuário www-data, portanto, qualquer processo do Apache pode ler arquivos de todos os outros sites configurados no mesmo servidor e, às vezes, até fazer alterações. Qualquer usuário que consiga que o Apache execute um script pode obter o mesmo acesso que o próprio Apache tem.

Para combater esse problema, existem várias abordagens para a separação de privilégios no Apache. No entanto, cada abordagem vem com várias desvantagens de desempenho e segurança. Na minha opinião, qualquer site com requisitos de segurança mais altos deve ser executado em um servidor dedicado em vez de usar VirtualHosts em um servidor compartilhado.

Considerações adicionais

Eu não mencionei isso antes, mas geralmente é uma prática ruim ter desenvolvedores editando o site diretamente. Para sites maiores, é muito melhor ter algum tipo de sistema de lançamento que atualize o servidor web a partir do conteúdo de um sistema de controle de versão. A abordagem de um único mantenedor provavelmente é ideal, mas em vez de uma pessoa, você automatizou o software.

Se seu site permite uploads que não precisam ser entregues, esses uploads devem ser armazenados em algum lugar fora da raiz da web. Caso contrário, você pode descobrir que as pessoas estão baixando arquivos que deveriam ser secretos. Por exemplo, se você permitir que os alunos enviem tarefas, elas deverão ser salvas em um diretório que não seja servido pelo Apache. Essa também é uma boa abordagem para arquivos de configuração que contêm segredos.

Para um site com requisitos mais complexos, convém examinar o uso de Listas de controle de acesso . Isso permite um controle de privilégios muito mais sofisticado.

Se o seu site tiver requisitos complexos, convém escrever um script que configure todas as permissões. Teste-o completamente e, em seguida, mantenha-o seguro. Pode valer seu peso em ouro se você precisar reconstruir seu site por algum motivo.

Estou me perguntando por que tantas pessoas usam (ou recomendam) a "outra" (o) parte dos direitos do Linux para controlar o que pode fazer o Apache (e/ou PHP). Ao definir essa parte certa para algo diferente de "0", você apenas permite que o mundo inteiro faça algo no arquivo/diretório.

Minha abordagem é a seguinte:

• Eu crio dois usuários separados. Um para o acesso SSH/SFTP (se necessário), que possuirá todos os arquivos, e outro para o usuário PHP FastCGI (o usuário com o qual o site será executado). Vamos chamar esses usuários respectivamente de bob e bob-www .
• bob terá todos os direitos ( rwx em pastas, rw- em arquivos), para que possa ler e editar todo o site.
• O processo PHP FastCGI precisa de direitos rx em pastas e r-- direitos em arquivos, exceto para pastas muito específicas como cache/ou uploads/, onde a permissão "write" também é necessária. Para dar ao PHP FastCGI essa habilidade, ele será executado como bob-www e bob-www será adicionado ao grupo bob criado automaticamente .
• Agora nos certificamos de que o proprietário e o grupo de todos os diretórios e arquivos sejam bob bob .
• Algo está faltando: mesmo nós usamos FastCGI, mas o Apache ainda precisa de acesso de leitura, para conteúdo estático, ou arquivos .htaccess que ele tentará ler se AllowOverrideestiver definido para algo diferente de None. Para evitar o uso da parte o dos direitos, adiciono o usuário www-data ao grupo bob .

Agora:

• Para controlar o que o desenvolvedor pode fazer, podemos brincar com a parte u dos direitos (mas esta a nota abaixo).
• Para controlar o que o Apache e o PHP podem fazer, podemos brincar com a parte g dos direitos.
• A parte o é sempre definida como 0, para que ninguém mais no servidor possa ler ou editar o site.
• Não há problema quando o usuário bob cria novos arquivos, pois ele pertencerá automaticamente ao seu grupo principal ( bob ).

Esta é uma recapitulação, mas nesta situação, bob tem permissão para SSH. Se não houver nenhum usuário com permissão para modificar o site (por exemplo, o cliente só modifica o site através de um painel de administração do CMS e não tem conhecimento de Linux), crie dois usuários de qualquer maneira, mas dê /bin/falsecomo shell para bob também, e desabilite seu login.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Nota: as pessoas tendem a esquecer que limitar os direitos de u (proprietário) é na maioria das vezes inútil e inseguro, já que o dono de um arquivo pode executar o chmodcomando, mesmo os direitos são 000.

Diga-me se minha abordagem tem alguns problemas de segurança, porque não tenho 100% de certeza, mas é o que estou usando.

Eu acho que esta configuração tem um problema: quando o PHP/Apache cria um novo arquivo (por exemplo, upload), ele pertencerá a bob-www:bob , e bob só poderá lê-lo. Talvez o setuid no diretório possa resolver o problema.

Dada a classificação do Google na excelente resposta acima, acho que há uma coisa que deve ser observada e não consigo deixar uma nota após a resposta.

Continuando com o exemplo, se você planeja usar www-data como proprietário e dev-fabrikam como grupo com 570 permissões no diretório (ou arquivo), é importante notar que o Linux ignora setuid , então todos os novos arquivos serão de propriedade do usuário que os criou. Isso significa que depois de criar novos diretórios e arquivos, você terá que usar algo semelhante a:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

No Ubuntu 12.04 para Rackspace OpenStack, tive um problema estranho em que não consegui permissões 570 para funcionar até reiniciar o servidor, o que magicamente corrigiu o problema. Estava perdendo cabelos a uma taxa crescente por causa desse problema aparentemente simples ....

Vou com esta configuração:

1. Todos os diretórios, exceto uploads, um conjunto para proprietário roote grupo root, permissões para 0755.
2. Todos os arquivos definidos como proprietário roote grupo root, permissões para 0644.
3. Carrega o diretório definido como proprietário root, grupo www-data, permissões para 1770. O sticky bit não permite que o proprietário do grupo remova ou renomeie o diretório e os arquivos dentro dele.
4. Dentro da pasta de uploads, um novo diretório com www-datausuário e grupo proprietário e 0700permissões para cada www-datausuário que faz upload de arquivos.
5. Configuração do Apache:

Negar AllowOverridee Indexno diretório de uploads, para que o Apache não leia .htaccessos arquivos e o usuário do Apache não possa indexar o conteúdo da pasta de uploads:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.iniconfiguração:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

Com esta configuração, o www-datausuário não poderá entrar em diretórios que não sejam siteDir/ /tmpe /usr/share/phpmyadmin. Além disso, você pode controlar o tamanho máximo do arquivo, o tamanho máximo da postagem e o máximo de arquivos para upload na mesma solicitação.

When you have a FTP user called "leo" need to upload files to example.com web directory and you also require your "apache" user to be able to create uploa-files/sessions/cache files in cache directory then do as follows:

This command assigns leo as owner and group as apache to example.com, apache user is a part of group apache so it will inherit the permissions of apache group

chown -R leo:apache example.com

Another command which insures right permission and fulfill security concerns as well.

chmod -R 2774 example.com

Here first number 2 is for directory and insures each new file created will be remain in same group and owner permissions. 77 is for owner and group means they have full access. 4 is for others mean they can only read trough.

following is helpful to understand permission numbers

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

IMO one has to take into account:

• do you trust a process which reads your files? eg. PHP?

Let's assume you have a server which various data under user 'test'.

The 'test' user has there:

• his data in $HOMEDIR
• his mail in $MAIL
• his data for web in /var/www/test

Now let's think about:

• a web app runs under test user (PHP-FPM) - it can delete any of his files!
• a web app runs under test group (PHP-FPM) - it can delete any of his files where directory has 'w' for the group and can modify any file which has 'r' for the group; and it could still read them - your ssh keys for example!

Let's assume PHP is buggy, and it is, do you trust its open_basedir? Do you chroot your PHP process? What is you don't, do you want it does crawls through all filesystem?

Your web app process, eg. PHP-FPM, then should:

• be restricted to specific path via chroot
• should not run under data owner's primary user or primary group permission

Thus you can do:

• test user is: test:test
• test user is in a secondary group eg. test-www
• a web app (PHP-FPM) runs under test-www:test-www
• test user if he wants that the web app can read his files will do: chmod u=rwX,g=rX,o= /var/www/test/public
• test user if he wants that the web app can write into his web data path: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (thus the app will create new files as: test-www:test-www - it will have test-www group because of setgid on the directory!)

Thus, if the web app process would be bogus it would just read specific files which would have group read, and it would be able to write to upload dir only. I would strongly recommend to have that upload dir on a filesystem with noexec,nodev,nosuid mount options and have constant monitoring for any new bizzare files in that directory, plus also monitor any new processes under test-www uid.

On Linux one could use ACL to better tune permissions. If more than one human should be to upload web data, it would be better to split human account from the account used to upload web data files, ie. to create new account eg. test-upload, and test user would manage ssh keys to restrict which human could ssh/sftp there. sshd_config knows ExposeAuthInfo options thus it can be configured to log which ssh key was used to upload the data.

I really doubt most webhosting services care about privileges separation, when they write 'secure' without any info what you get, I would say they lie.