Por que é recomendável criar um grupo e um usuário para alguns aplicativos?

Question

Na maioria das vezes, ao instalar um programa a partir do código-fonte, é recomendável criar um novo usuário e um novo grupo e fornecer /usr/local/<myapp> à propriedade de usuário e grupo criada recentemente.

• Por que essa prática é considerada uma boa prática?

• O que isso melhora?

Exemplo: grupo mysql user / mysql para o servidor de banco de dados MySQL.

    

Answer 1

A prática não é criar um usuário e grupo por aplicativo, mas por serviço. Ou seja, programas que são executados por um usuário local não precisam ser instalados como um usuário diferente de root. É daemons , programas sendo executados em segundo plano e que executam solicitações provenientes da rede ou de outros meios de comunicação, que deve ser executado como um usuário dedicado.

O daemon é executado como um usuário dedicado, de modo que se ele se comportar mal (devido a um bug, provavelmente desencadeado por um invasor) o dano que ele pode fazer é limitado: somente os arquivos de dados do daemon são afetados (a menos que o invasor tenha encontrado buraco raiz local, o que pode acontecer). Por exemplo, o daemon do banco de dados mysqld é executado como um usuário dedicado e o grupo mysql:mysql e os arquivos de dados do banco de dados ( /var/lib/mysql/* ) pertencem a mysql:mysql .

Observe que o executável do daemon e outros dados estáticos e arquivos de configuração que são usados, mas não devem ser modificados pelo daemon, não devem pertencer ao usuário dedicado; eles devem pertencer a root:root , como a maioria dos arquivos de programa e configuração. O processo mysqld não tem sobregravação de negócios /usr/sbin/mysqld ou /etc/mysql/my.cnf , portanto, esses arquivos não devem pertencer ao usuário mysql ou ser graváveis pelo usuário mysql ou pelo grupo mysql . Se alguns arquivos precisarem ser legíveis somente pelo daemon e pelo administrador, eles devem ser de propriedade do usuário root e do grupo dedicado, e ter o modo 0640 ( rw-r----- ).

Uma categoria especial de executáveis que não podem ser de propriedade de root:root são programas que são chamados por um usuário, mas precisam ser executados com privilégios extras. Esses executáveis devem ser setuid root se precisarem ser executados (pelo menos em parte) como root; então o executável deve ter o modo 4755 ( rwsr-xr-x ). Se o programa precisar com privilégios extras, mas não como root, o programa deve ser configurado como setgid, de modo que os privilégios extras passem por um grupo e não por um usuário. O executável tem então o modo 2755 ( rwxr-sr-x ). As razões são duplas:

• O executável não deve ter permissão para se modificar, de modo que, se um usuário conseguir explorar uma vulnerabilidade, poderá modificar os arquivos de dados usados pelo programa, mas não injetar um trojan horse no executável para atacar outros usuários executando o programa.
• O arquivo de dados do executável pertence ao grupo. Um programa setuid teria que alternar entre o usuário real (o usuário que invocou o programa) para interagir com o usuário e com o usuário efetivo (o usuário que o programa está executando) para acessar seus arquivos de dados privados (a razão para isso). ter privilégios extras). Um programa setgid pode, além disso, separar os dados por usuário que são acessíveis apenas ao grupo (por exemplo, armazenando arquivos pertencentes ao usuário em um diretório acessível apenas para o root e o grupo do programa).

Answer 2

Não são aplicativos em geral, mas daemons são para isso. O motivo é que o daemon pode ser executado como um usuário não privilegiado em vez de root, de modo que, se ele tiver uma vulnerabilidade de segurança e for comprometido, o dano que pode ser feito está contido apenas nas áreas a que o usuário tem acesso.

    

Answer 3

A razão pela qual é considerada uma boa prática é impedir que outros usuários do sistema substituam dados e arquivos de configuração para o aplicativo específico.

Como exemplo, mysql / mysql , sendo o proprietário do armazenamento para arquivos de banco de dados mysql, evita que qualquer pessoa que não utilize a API do aplicativo corrompa os bancos de dados. Além disso, o usuário mysql geralmente não tem um shell real, portanto, ninguém pode fazer login como esse usuário também.

    

Answer 4

Criar um novo grupo / usuário para um novo daemon instalado melhora a segurança. Quando o processo do servidor é executado sob esse usuário, ele é restrito aos direitos de acesso desse usuário. Em comparação: quando é executado como root, ele pode fazer tudo.

Essa diferença é importante caso seu daemon seja mal configurado e / ou contenha um bug relacionado à segurança.

Não sei ao certo o que você quer dizer com a segunda parte da sua pergunta, ou seja, a parte sobre /usr/local propriedade. Em geral, não faz sentido que o mesmo usuário X sob o qual um daemon é executado por motivos de segurança também possua o diretório com os binários (porque, nesse caso, ele poderia alterá-los no caso de uma exploração). Mas o diretório com arquivos de dados em que o daemon trabalha deve estar acessível por X - a maneira mais fácil de configurar isso é tornar X o proprietário dos diretórios / arquivos de dados.

A execução de um daemon com seu próprio usuário especial é apenas uma técnica de segurança, outros incluem algum tipo de 'chrooting' ou o uso de um sistema de controle de acesso (MAC) obrigatório (por exemplo, o SELinux).

    

Answer 5

Esta é uma consideração de segurança. Isso limita o dano que pode ser feito por alguém que invadir um aplicativo daemon. O aplicativo do usuário geralmente é de propriedade de um ID do usuário padrão, como root .

Se o seu servidor web, servidor de e-mail e banco de dados forem executados como o mesmo usuário, será mais fácil comprometê-los. Se qualquer um deles tiver um erro ou configuração incorreta que permita o acesso ao sistema, esse acesso poderá ser usado para acessar todos os três aplicativos.

Se todos eles tiverem contas separadas, conforme recomendado, somente o aplicativo comprometido provavelmente estará acessível. Embora detalhes de configuração pública do outro possam ser lidos, é improvável que mudanças possam ser feitas.

Muitos daemons permitem que os usuários façam upload e download de arquivos e façam coisas que você não gostaria que eles fizessem com as configurações de outros daemons. Se cada aplicativo tiver seu próprio ID de usuário e grupo, é mais simples proteger os daemons.

Ter um grupo específico do daemon torna mais simples conceder ao daemon acesso seguro somente leitura a arquivos e diretórios. Se o arquivo ou diretório pertencer a um usuário diferente, mas pertencer ao grupo de daemons, ele geralmente estará acessível somente para leitura. As permissões de acesso podem ser facilmente verificadas e corrigidas com ferramentas como encontrar.