Debian - como impedir o acesso global de leitura a todos os arquivos?

Question

No meu debian todos os arquivos, mesmo os do sistema têm permissões rw-r - r--, então isso significa que todos os usuários podem ver qualquer arquivo, mesmo alguns arquivos de banco de dados ou configuração do sistema e assim por diante.

Como evito que os usuários leiam todos os arquivos do sistema? Existe alguma maneira de definir permissões globais para que os usuários não possam ler todos os arquivos?

    

Answer 1

Eu não acho que negar o acesso a todos os arquivos do sistema para todos os usuários seja uma boa ideia. Alguns desses arquivos são necessários para trabalhar em um sistema. Mas existem várias maneiras de restringir usuários específicos. Por exemplo, se você quisesse negar ao usuário joe acesso a qualquer coisa em /etc , você poderia usar ACLs (manipulado com comandos setfacl / getfacl), assim:

setfacl -Rm u:joe:--- /etc

Outras ideias seriam usar a política do selinux ou manter os usuários no chroot. Acho que chmod 700 nos diretórios do sistema é uma má ideia, porque ele negará o acesso a vários usuários do sistema, como nobody , ftp ou mail , que são usados por alguns serviços do sistema.

    

Answer 2

In my debian all files, even the system ones have permissions rw-r--r--, so it means that all users can view ANY file even some system configuration or database files and so on.

A menos que você tenha violado as permissões, elas são absolutamente boas, pois estão fora da caixa. Por favor não os altere, especialmente não nessa circunferência.

Os arquivos do sistema (configuração) são destinados e salvos para serem lidos por todos. Em certos casos eles devem ser legíveis ( /etc/bash.bashrc ou /etc/default ) e em outros casos eles já estão protegidos ( /etc/shadow ).

Arquivos de banco de dados, que no Debian residem em /var/lib , também estão protegidos.

drwx------ 10 mysql   mysql   4.0K Feb 26 12:49 /var/lib/mysql

Você pode assumir que para a maioria dos softwares dos repositórios da Debian as permissões estão seguras como estão. Há exceções, claro. Hospedagem na web é uma delas, onde você geralmente precisa fazer ajustes de permissão maiores para a raiz do documento e arquivos de soquete do PHP-FPM.

Se você não sabe com certeza quais as implicações que uma alteração das permissões das pastas 'padrão' tem, você deve decidir contra isso.

O único local onde as permissões padrão são realmente liberais está dentro do diretório /home , pelo menos na minha opinião.

    

Answer 3

Um aspecto interessante das permissões do Linux é que a permissão padrão é normalmente 777 (-rwxrwxrwx) e, em seguida, umask é usada para remover permissões automaticamente, para que novos diretórios ou arquivos sejam criados, o diretório ou arquivo recém-criado não é 777 e, em vez disso, é algo como 644 (-rw-r - r--) ou 666 (-rw-rw-rw-). Se você deseja remover a permissão de leitura padrão para todos os arquivos / diretórios, você pode ajustar o umask. No entanto, alterar umask provavelmente não é a solução para a tarefa que você enfrenta.

Acho que a solução seria controlar o acesso usando chmod e chown ou setfacl e getfacl. Por exemplo, digamos que apenas root tenha acesso a / var / private. Você pode usar os seguintes comandos para que somente o root possa ler, gravar e acessar o diretório e os arquivos no diretório.

Defina root como o proprietário e o proprietário do grupo / var / private:

chown -R root:root /var/private

Você também pode definir a permissão no diretório para que somente o root possa acessar o diretório (-rwx ------):

chmod 0700 /var/private

Você poderia, então, definir recursivamente a permissão em todos os arquivos no diretório, para que apenas o root possa ler, gravar e executar arquivos no diretório (-rwx -----):

chmod 0700 -R /var/private/* 

Nota: Eu não sei como você está usando seu banco de dados. Se os arquivos de seu banco de dados estiverem acessíveis em um navegador da Web, como por meio de PHP ou ASP.Net, essa alteração de permissão poderá impedir que o PHP ou o ASP.Net interajam com os registros do banco de dados.