Eu administro vários sistemas RHEL 6.9. Em cada sistema, um diretório específico, chame-o de /app_dir , é o nível superior onde os scripts, executáveis, arquivos de configuração e logs do nosso projeto são armazenados. A árvore sob esse diretório de nível superior é ampla e profunda. Todos os arquivos e subdiretórios em /app_dir pertencem ao usuário user1 e têm participação no grupo group1 . Os usuários humanos sempre executam como user1 e o grupo primário de user1 é group1 .
Alguns sistemas são para os membros da equipe de fabricação testarem os widgets de hardware que produzimos antes da entrega a um cliente, e alguns sistemas são para o desenvolvimento do software usado para testar os widgets de hardware.
Todos os usuários humanos efetuam login em um desktop GNOME como user1 . Nosso aplicativo principal (GUI) é executado abrindo um terminal e iniciando o aplicativo a partir da linha de comando.
Os sistemas de fabricação precisam permanecer em um estado primitivo. No entanto, por vários motivos, os desenvolvedores alteram um script ou arquivo de configuração para testar algo em um sistema de fabricação e esquecem de reverter a alteração. Um problema clássico.
Então, quando um membro da equipe de produção usar o sistema, ele não funcionará, dará um passe falso (este é o pior caso porque nos faz entregar um widget de hardware com defeito) ou dará um falso falhar (causando perda de receita por não entregar um widget de hardware que era, de fato, adequado para entrega).
Portanto, preciso encontrar uma maneira de bloquear (ou seja, tornar legíveis, mas não graváveis) os scripts e arquivos de configuração em nossa estrutura de diretórios para que, com algumas exceções bem definidas, eles não possam ser alterados, exceto por um lead que tenha privilégios especiais. As permissões padrão do Linux são inadequadas, pois, dado o que está descrito no primeiro parágrafo deste post, elas permitem que qualquer usuário humano (que sempre roda como user1 ) altere qualquer arquivo à vontade.
Neste ponto do nosso ciclo de vida, infelizmente não temos flexibilidade para mudar muito em termos de estrutura de diretórios, usuários, grupos, etc.
Estou pensando que o SELinux fornecerá uma solução.
A situação real é muito mais complexa, mas como exemplo, considere esta estrutura de diretórios:
/app_dir/bin/
/app_dir/bin/widget_tester
/app/dir/bin/<other executables>
/app_dir/config/
/app_dir/config/widget_info.txt
/app_dir/config/test_tolerances.txt
/app_dir/config/<other configuration files>
/app_dir/scripts/
/app_dir/scripts/script_1.py
/app_dir/scripts/script_2.sh
/app_dir/scripts/<other scripts>
/app_dir/logs/
/app_dir/logs/<log files>
/app_dir/bin/ , e tudo abaixo dele, deve ser bloqueado sem exceções.
/app_dir/config/ , e tudo abaixo dele, deve ser bloqueado com exceção de widget_info.txt . Um membro da equipe de fabricação precisa ser capaz de fornecer informações sobre o widget de hardware que está prestes a ser testado.
/app_dir/scripts/ , e tudo abaixo dele, deve ser bloqueado com exceção de script_1.py .
/app_dir/logs/ , e tudo abaixo dele, deve ser gravável por nossos executáveis e scripts, mas para humanos (ou seja , user1 ), deve ser apenas legível.
O SELinux é a ferramenta certa para este trabalho? Em caso afirmativo, os tipos/imposição de tipo são o mecanismo a ser usado? se não para nenhum dos dois, onde mais eu focaria melhor meus esforços de aprendizado?
ATUALIZAÇÃO 1
Observe que a configuração que descrevi para que todos os humanos sejam executados como usuário1 é anterior à minha chegada ao projeto em, literalmente, anos. Eu entendo que ele tem suas deficiências (mas na verdade existem razões válidas para isso que não preciso entrar aqui). Esta é uma operação de fabricação do mundo real. Uma reestruturação do nosso setup é totalmente inviável do ponto de vista do negócio. Não seria permitido pela administração.
Aponto isso para enfatizar que não estou solicitando uma crítica de nossa configuração atual. Estou tentando descobrir com especialistas da comunidade que sabem mais sobre o SELinux do que eu se estou latindo na árvore certa ou errada gastando meus esforços aprendendo sobre o SELinux. Também estou solicitando ponteiros para outros mecanismos do Linux que talvez não conheça e que possam resolver esse problema. (ou seja, embora meu foco atual seja o SELinux, não quero necessariamente limitar a discussão ao SELinux.)
Estes são problemas de permissões simples, o SeLinux não ajudará neste caso:
ACL: é um mecanismo de permissão adicional e mais flexível para sistemas de arquivos.
O que você precisa fazer aqui é simplesmente dar a cada usuário/grupo as permissões necessárias nos arquivos:
1- Primeiro, verifique se seus sistemas de arquivos suportam ACLs (por exemplo, xfs, ext2, ext3, ext4):
2- Defina a propriedade de /app_dir/* para leaduser , para que o lead seja o único a ter controle total sobre ele:
OU
Se você quiser continuar usando user1 & group1 porque é assim que o aplicativo deve ser iniciado, adicione leaduser a group1 como um grupo secundário:
3- Defina as exceções configurando ACLS em diretórios/arquivos.
Ex: /app_dir/bin/
PS: R é para recursivo.
3- Verifique se as ACLs foram aplicadas corretamente:
Aqui está um ótimo artigo que ajudará a definir as ACLs corretas para os caminhos restantes
Use o comando "chattr" para atribuir aos arquivos/pastas selecionados o atributo "imutável". Ninguém poderá modificar esses arquivos, nem mesmo o proprietário do arquivo ou o usuário root até que o atributo seja removido pelo root.