Entendendo os recursos na programação de sistemas Linux

Os recursos permitem a avaliação de alguns privilégios importantes do sistema em um thread separado diferente do processo atual. Dessa forma, você não precisa executar um programa como root para acessar certas partes do sistema.

Como solução decorrente de necessidades, a seção 25 do POSIX.1e trata dessa questão. O desenvolvimento dos privilégios definidos nessa seção e mais foi concluído com o lançamento do kernel Linux versão 2.6.26. Aqui está tudo o que você precisa saber sobre recursos no kernel do Linux.

Entendendo a lógica da API de recursos

O controle de autorização em sistemas baseados em Unix consiste em duas etapas:

• Se o proprietário atual (ID de usuário efetivo, EUID) do aplicativo em execução for zero, o sistema não verificará a autorização
• Se o valor EUID for diferente de zero, o sistema realiza o processo de controle de acordo com as autorizações do usuário efetivo e grupo do aplicativo relevante

Alguns aplicativos precisam ter privilégios mais amplos (SUID, bits SGIT) durante a execução. Como o exemplo mais típico, você pode pensar em

o aplicativo passwd. Com isso, os usuários de um sistema podem alterar suas senhas. No entanto, para escrever para o /etc/shadow arquivo, onde as senhas criptografadas são mantidas, é necessário trabalhar com direitos de usuário root (ou seja, ID do usuário = 0).

Para resolver esse problema, o aplicativo passwd possui um bit SUID. Qualquer que seja o usuário que executa este aplicativo, o proprietário ativo (EUID) sempre será o root:

ls -l /usr/bin/passwd
# Saída
-rwsr-xr-x. 1 root root 32552 23 de julho de 2021 /usr/bin/passwd

A capacidade de executar aplicativos SUID no modelo tradicional de autenticação Unix parece ter resolvido o problema. No entanto, erros críticos em aplicativos com bits SUID abrem a porta para a execução de códigos indesejados para usuários com autoridade total no sistema. Um aplicativo ideal deve ser capaz de ser executado sem precisar de direitos de usuário root, se possível.

O problema não termina apenas com o bit SUID. Você também deve ter direitos de usuário root quando quiser ouvir em um porta TCP ou UDP privilegiada menos de 1024 em sistemas baseados em Unix. Por exemplo, para poder escutar a porta TCP 80 de um servidor web, você deve executar o aplicativo como usuário root.

Ao longo dos anos, compreendeu-se o quão devastador é executar software que fornece serviço ao ambiente de rede com uma conta de usuário totalmente autorizada. Como solução provisória, adotou-se que apenas uma certa e menor parte do programa escuta na porta privilegiada como root, e, em seguida, altera o ID do usuário ativo para outro usuário para processos subsequentes (por exemplo, o usuário none com direitos restritos).

Este sistema, que tem sido usado há anos, funcionou bem com sua simplicidade e ainda é usado com eficiência. No entanto, hoje em dia, é possível obter alguns recursos adicionais, específicos para a aplicação, através da API de recursos do Linux, sem a necessidade de direitos de root, além dos mencionados acima sistema.

O modelo de capacidade do Linux, explicado!

Você pode encontrar a implementação mais abrangente da API de recursos no kernel do Linux. As distribuições Linux modernas também tentam usar esse novo modelo em todo o sistema o máximo possível.

Por exemplo, para que o aplicativo ping funcione, ele deve ser capaz de abrir soquetes RAW, que geralmente são reservados apenas para usuários root. Em distribuições antigas do Linux, o problema é dar o bit SUID ao aplicativo para que usuários normais possam usá-lo. Nessas versões, quando você remove o bit SUID do aplicativo e tenta executar o aplicativo como um usuário normal, obtém o seguinte erro:

ping 8.8.8.8
# Saída
ping: icmp open socket: operação não permitida

Considerando que nas distribuições Linux modernas, o aplicativo ping provavelmente não possui o bit SUID:

ls -l /bin/ping 
# Saída
-rwxr-xr-x. 1 root root 95232 25 de julho de 2021 /bin/ping

No entanto, você pode executar o aplicativo com sucesso como um usuário normal. O mecanismo que torna isso possível é que o aplicativo ping tem a habilidade especial CAP_NET_RAW.

Você pode aprender os recursos adicionais do aplicativo com o getcap comando da seguinte forma:

sudo getcap /bin/ping
# Saída
/bin/ping cap_net_raw=ep

Se o comando getcap retornar uma resposta vazia, você poderá definir manualmente esse valor com:

sudo limite cap_net_raw+ep /bin/ping

O Modelo de Capacidade do Processo

Na implementação do Linux, os recursos de cada processo são agrupados em três títulos:

A lista de recursos permitidos, efetivos e herdáveis ​​para a execução de processos a qualquer momento é exibida como máscara de bits nas linhas CapPrm, CapEff, e CapInh no arquivo /proc//status. Além disso, o CapBnd A linha contém a máscara de bits usada na operação de controle de limite de capacidade.

Por exemplo, tente ler os valores do seu aplicativo shell em execução no /proc/self/status Arquivo:

gato /proc/auto/status | grep Cap
# Saída
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

O modelo de capacidade de arquivo no Linux

A operação do sistema de recursos para arquivos depende do pré-requisito de que essas propriedades possam ser armazenadas na camada do sistema de arquivos virtual (VFS). Semelhante ao modelo de processo, os recursos para arquivos se enquadram em três títulos:

1. Permitido

O sistema determina os recursos permitidos do processo quando o executável correspondente é executado neste cluster.

2. Eficaz

Ao contrário do modelo de capacidade do processo, este cabeçalho armazena apenas um bit: ativo ou inativo. Se o bit estiver ativo, as capacidades definidas na lista permitida do arquivo são automaticamente transferido para a lista de capacidade efetiva do processo relevante quando este arquivo é executado e um processo é criado. Se o bit não estiver ativo, a transferência automática das capacidades permitidas no arquivo para o processo em execução não é executada.

No entanto, se o código do aplicativo relevante estiver integrado ao sistema de recursos, ele poderá ativar as permissões no conjunto permitido do arquivo com chamadas do sistema. O principal objetivo desse comportamento é garantir que aplicativos antigos que não incluem recursos específicos do sistema código, o desenvolvimento no nível de código de software pode funcionar com o sistema de capacidade sem a necessidade de qualquer código-fonte mudanças.

Você pode pensar que aplicativos mais bem escritos só usarão recursos quando necessário. Se o bit estiver ativo, todos os recursos na lista de permissões se tornarão ativos quando o aplicativo for iniciado.

3. Herdável

Como no modelo de processo, o arquivo relevante é executado e ocorre um processo. Se outro aplicativo for executado dentro do processo depois disso, ele será incluído na lista de permissões do novo processo. Para resumir, indica uma lista de capacidades a serem herdadas.

O papel das capacidades em um sistema Linux

Quando você executa um determinado processo como um usuário normal, você não tem privilégios. Como resultado, você só pode acessar as partições que o sistema permite para usuários normais. A principal razão por trás disso é reforçar a segurança do sistema e implementar tais medidas.

Permitir que todos os usuários acessem todos os recursos pode criar uma séria vulnerabilidade de segurança. Será muito fácil para as pessoas que usam o sistema para fins maliciosos explorar as vulnerabilidades do sistema. Os recursos do Linux são úteis nessas questões. Você pode facilmente fortalecer a segurança de seus aplicativos com recursos de API desenvolvidos pelo kernel.

Os recursos do Linux são apenas uma das questões que precisam ser pensadas para fazer métodos muito poderosos, como dividir o usuário root permissões, atribuindo várias permissões a usuários não privilegiados e tomando várias precauções sobre portas abertas em serviços de Internet com servidores Linux.

Melhore a segurança do seu servidor Linux com estas 7 etapas de proteção

Leia a seguir