Mito ou realidade: o SELinux pode limitar o usuário root?


20

Li ou ouvi em algum lugar (talvez no curso SELinux do LinuxCBT ; mas não tenho certeza) que existem servidores Linux online, para os quais também é fornecida a senha do usuário root. O servidor Linux é reforçado usando as regras do SELinux, de modo que todos possam fazer login com o usuário root, mas não causar danos ao sistema operacional.

Parece um mito para mim, mas eu queria ter certeza: É possível proteger uma caixa do Linux (possivelmente com o SELinux), de modo que nem o usuário root possa realizar atividades maliciosas específicas? (Exemplos: exclusão de arquivos do sistema, limpeza de arquivos de log, interrupção de serviços críticos etc.)

Uma caixa desse tipo Linux será um excelente ponto de partida para a construção de um honeypot .

Edit: Com base em uma resposta (agora excluída) e em um pouco de pesquisa no Google, obtive pelo menos dois links que apontavam para servidores Linux tão robustos. Infelizmente, os dois servidores estão inoperantes. Para o registro, copio e colo as descrições aqui:

1) Em http://www.coker.com.au/selinux/play.html :

Acesso root gratuito em uma máquina SE Linux!

Para acessar minha máquina de jogo Debian ssh para play.coker.com.au como root, a senha é ...

Observe que essas máquinas requerem muita habilidade para executá-las com sucesso. Se você precisar perguntar se deve executar um, a resposta é "não".

O objetivo disso é demonstrar que toda a segurança necessária pode ser fornecida pelo SE Linux sem nenhuma permissão Unix (no entanto, ainda é recomendável que você use permissões Unix também para servidores reais). Além disso, você tem a chance de fazer login em uma máquina SE e ver como é.

Ao fazer login em uma máquina de reprodução SE Linux, certifique-se de usar a opção -x para desativar o encaminhamento do X11 ou definir o ForwardX11 no no seu arquivo / etc / ssh / ssh_config antes de efetuar o login. Além disso, certifique-se de usar a opção -a para desativar o encaminhamento do agente ssh ou definir o ForwardAgent no no seu arquivo / etc / ssh / ssh_config antes de efetuar o login. Se você não desabilitar corretamente essas configurações, o login na máquina de jogo colocará o risco de ser atacado pelo seu cliente SSH.

Existe um canal de IRC para discutir isso, é #selinux em irc.freenode.net .

Aqui está uma rápida FAQ

2) Em http://www.osnews.com/comments/3731

O objetivo reforçado do Gentoo é tornar o Gentoo viável para ambientes de servidores de produção de alta segurança e alta estabilidade. Este projeto não é um projeto independente, separado do Gentoo; Ele pretende ser uma equipe de desenvolvedores do Gentoo, focada em fornecer soluções ao Gentoo que forneçam segurança e estabilidade fortes. Esta máquina é a máquina de demonstração SELinux do Hardened Gentoo . O principal uso é testar e auditar a integração e a política do SELinux.


2
Também foi reivindicado aqui . Embora isso seja teoricamente possível, parece-me difícil (a menos que você confine tanto o usuário root que ele não possa fazer nada útil). Escrever regras do SELinux que realmente fazem o que você se propõe é difícil no melhor dos casos.
Gilles 'SO- stop be evil'

4
Com os kernels recentes, os usuários não-root podem criar espaços de nomes com UID 0. Como não são UID 0 no espaço de nomes de nível superior, eles não podem prejudicar o sistema. Eles intrinsecamente não têm oportunidade de causar danos, ao contrário da abordagem do SELinux, onde todas essas oportunidades precisam ser tiradas. Veja o kernel: Suporte a namespaces e Duas contas totalmente separadas sem instalar sistemas operacionais separados?
Gilles 'SO- stop be evil'

Depende do seu driver gráfico, seja ele realmente seguro ou não.
Joshua

Respostas:


17

Realidade: sim, o SELinux pode limitar o usuário root.

Isso é possível porque o SELinux não se importa realmente com o usuário atual do Unix: tudo o que vê são metadados suplementares chamados de contexto (que inclui, entre outros campos, um campo de domínio ) e permite que o SELinux decida se a ação solicitada pode ser autorizada ou executada. não.

O que geralmente se concebe como usuário raiz seria mapeado no SELinux como um usuário Unix raiz executando o domínio unconfined_tou o sysadm_tSELinux. É o usuário root onipotente clássico com potência total.

No entanto, pode-se configurar perfeitamente seu sistema para gerar um shell raiz (refiro-me ao shell do usuário root do Unix) executando o user_tdomínio SELinux do usuário restrito . De acordo com as políticas do SELinux, esse shell não seria diferente de quaisquer outros shells de usuário restrito e não teria privilégios especiais no sistema, confinando efetivamente o usuário root.

Além de um ponto de vista experimental, fazer algo literalmente é inútil, por mais práticas similares que sejam encontradas no mundo real. Um exemplo clássico seria um administrador de banco de dados que deveria ser capaz de parar / iniciar os daemons do banco de dados, editar arquivos de configuração etc. Sem o SELinux, todas essas ações exigiriam que o usuário escalasse em direção a privilégios de root (mesmo que seja normalmente para um único linha de comando através da sudoferramenta, por exemplo, no entanto, mesmo que isso possa estar sujeito a vazamentos).

Graças ao SELinux, podemos fornecer a esse usuário um shell raiz genuíno, mas em vez de executar unconfined_tou sysadm_tdomínios, ele executará o dbadm_tdomínio. Isso significa que ele terá mais privilégios do que um usuário restrito, mas esses novos privilégios serão limitados ao necessário para administrar o servidor de banco de dados: esse usuário não poderá violar outros serviços, arquivos ou executar outros comandos administrativos além daqueles estritamente necessário para fazer o seu trabalho.

Da mesma forma, o servidor da web e outros administradores de serviços também podem ter outros shells raiz rodando em paralelo no mesmo sistema, todos verão o usuário atual do Unix sendo root , mas, graças ao SELinux, cada um terá privilégios efetivamente diferentes, limitados ao que é necessário para seus próprios propósitos .


1

Sim é possivel. Mas não é muito útil.

Teoricamente, você poderia impedir o usuário root de executar binários que poderiam ser usados ​​para fins maliciosos, impondo políticas por meio de algo como o SELinux. No entanto, isso apresenta um problema, que é o fato de, mesmo que o usuário root tenha sido inicialmente impedido de fazer algo, ele ou ela poderia usar outros métodos para alterar ou remover as políticas do SELinux. Devido a esse problema, você precisaria efetivamente impedir o usuário root de executar qualquer ação, tornando-a pouco útil.


Primeiro, eu era tão pessimista quanto você. Mas, ganhando mais conhecimento, parece que não há necessidade de "impedir o usuário root de executar qualquer ação". Verifique minha resposta editada, que inclui links e informações para a prova de conceitos. Infelizmente, eles não estão mais disponíveis; mas parece que as implementações não foram severamente restritivas.
MS Dousti

-5

É possível proteger uma caixa do Linux (possivelmente com o SELinux), para que nem o usuário root possa realizar atividades maliciosas específicas?

Isso pode parecer barato, mas é fácil: altere o uid da raiz do usuário para diferente de zero. Simplesmente entre em / etc / passwd e / etc / shadow, modifique as entradas uid = 0 existentes de "root" para outra coisa e adicione uma conta chamada "root" cujo uid não é zero e não é usado.

Atinge o objetivo sem. É também uma maneira de afirmar que qualquer pessoa pode ter "acesso root" sem realmente fornecer privilégios escalados.


3
Bem, sim, mas o rootusuário simplesmente não é realmente o usuário root. A questão é perguntar se o superusuário real pode ser limitado dessa maneira.
terdon

Parece perigoso - exceto que você cria outra conta com o uid 0, é claro. Mas isso seria o mesmo que renomear raiz e reutilizar o nome "raiz".
Volker Siegel

A questão refere-se apenas a "root", que não é necessariamente equivalente ao superusuário, ou seja, uid = 0. Em raras ocasiões, essa é uma distinção útil.
Otheus15 de

2
No entanto, o contexto deixa claro que o OP está perguntando se o superusuário, e não algum usuário aleatório cujo nome de usuário é, rootpode ser limitado de tal maneira.
terdon

11
ESTÁ BEM. Pelo menos, edite sua resposta e mostre como o que você sugere pode ser alcançado. Ele fica sinalizado como de baixa qualidade por causa de seu comprimento. É por isso que está ficando com votos negativos.
terdon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.