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

Question

Eu li ou ouvi em algum lugar (talvez no curso SELinux da LinuxCBT ; mas não tenho certeza) que existem Servidores Linux, para os quais a senha do usuário root também é fornecida. O servidor Linux é endurecido usando as regras do SELinux, de modo que todos possam efetuar login com o usuário root, mas não podem causar danos ao sistema operacional.

Parece um mito para mim, mas eu queria ter certeza: é possível endurecer uma caixa Linux (possivelmente com o SELinux), de tal forma que até mesmo o usuário root não possa executar atividades maliciosas específicas nele? (Exemplos: excluir arquivos do sistema, limpar arquivos de log, parar serviços críticos, etc.)

Essa caixa do Linux será um excelente ponto de partida para criar um honeypot .

Editar: Com base em uma resposta (agora excluída), e um pouco no Googling, eu consegui pelo menos dois links que apontavam para esses servidores Linux endurecidos. Infelizmente, os dois servidores estão inativos. Para o registro, vou copiar e colar as descrições aqui:

1) A partir do link :

Free root access on a SE Linux machine!

To access my Debian play machine ssh to play.coker.com.au as root, the password is ...

Note that such machines require a lot of skill if you are to run them successfully. If you have to ask whether you should run one then the answer is "no".

The aim of this is to demonstrate that all necessary security can be provided by SE Linux without any Unix permissions (however it is still recommended that you use Unix permissions as well for real servers). Also it gives you a chance to login to a SE machine and see what it's like.

When you login to a SE Linux play machine make sure that you use the -x option to disable X11 forwarding or set ForwardX11 no in your /etc/ssh/ssh_config file before you login. Also make sure that you use the -a option to disable ssh agent forwarding or set ForwardAgent no in your /etc/ssh/ssh_config file before you login. If you don't correctly disable these settings then logging in to the play machine will put you at risk of being attacked through your SSH client.

There is an IRC channel for discussing this, it is #selinux on irc.freenode.net.

Here is a quick FAQ

2) A partir do link

Hardened Gentoo's purpose is to make Gentoo viable for high security, high stability production server environments. This project is not a standalone project disjoined from Gentoo proper; it is intended to be a team of Gentoo developers which are focused on delivering solutions to Gentoo that provide strong security and stability. This machine is Hardened Gentoo's SELinux demo machine. The primary use of it is to test and audit SELinux integration, and policy.

    

Answer 1

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

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

O que normalmente se concebe como usuário root seria mapeado no SELinux como um usuário root Unix executando os domínios unconfined_t ou sysadm_t SELinux. É o usuário root omnipotente clássico e completo.

No entanto, pode-se configurar perfeitamente seu sistema para gerar um shell de root (quero dizer, shell de usuário Unix raiz) executando o domínio user user_t SELinux restrito. De acordo com as políticas do SELinux, esse shell não seria diferente de qualquer outro shells de usuários restritos e não teria nenhum privilégio especial no sistema, limitando assim efetivamente o usuário root.

Appart de um ponto de vista experimental, fazendo isso literalmente é inútil, no entanto prática semelhante encontrar o seu caminho no mundo real. Um exemplo clássico seria um administrador de banco de dados precisando 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 privilégios de root (mesmo que seja normalmente por um único linha de comando através da ferramenta sudo , por exemplo, no entanto, mesmo que possa estar propenso a vazamentos).

Graças ao SELinux, podemos dar a esse usuário um shell de raiz genuíno, mas, em vez de executar unconfined_t ou sysadm_t domains, ele executará o domínio dbadm_t . Isso significa que ele terá mais privilégios do que um usuário restrito, mas esses novos privilégios serão limitados ao que é necessário para administrar o servidor de banco de dados: esse usuário não poderá adulterar outros serviços, arquivos ou executar outros comandos administrativos estritamente necessário para fazer o seu trabalho.

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

    

Answer 2

Sim, é possível. Mas não é muito útil.

Você poderia, teoricamente, impedir que o usuário root execute binários que possam ser usados para fins maliciosos, aplicando políticas por meio de algo como o SELinux. No entanto, isso apresenta um problema, que é que, mesmo que o usuário root tenha sido inicialmente proibido de fazer algo, ele poderia usar apenas outros métodos para alterar ou remover as políticas do SELinux. Devido a esse problema, você teria que efetivamente impedir que o usuário root execute qualquer ação, tornando-o pouco útil.

    

Answer 3

Is it possible to harden a Linux box (possibly with SELinux), such that even the root user cannot do specific malicious activities on it?

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

Alcança o objetivo sem. É também uma forma de reivindicar que qualquer pessoa pode ter "acesso root" sem realmente fornecer privilégios escalados.