Um namespace de usuário é um recurso do kernel Linux que fornece isolamento de mapeamentos de ID de usuário e grupo, permitindo que cada namespace de usuário tenha seu próprio conjunto de IDs de usuário e grupo. Esse isolamento permite que processos em diferentes namespaces de usuário tenham privilégios e propriedade diferentes, mesmo que compartilhem os mesmos IDs de usuário e grupo numericamente.
Namespaces de usuário são particularmente úteis na containerização, onde cada contêiner deve ter seu próprio conjunto independente de IDs de usuário e grupo, permitindo melhor segurança e isolamento entre contêineres e o sistema host.
How it works:
Quando um novo namespace de usuário é criado, ele começa com um conjunto vazio de mapeamentos de ID de usuário e grupo. Isso significa que qualquer processo executando no novo namespace de usuário inicialmente não terá privilégios fora do namespace.
Mapeamentos de ID podem ser estabelecidos entre os IDs de usuário e grupo no novo namespace e aqueles no namespace pai (ou host). Isso permite que processos no novo namespace tenham privilégios e propriedade correspondentes aos IDs de usuário e grupo no namespace pai. No entanto, os mapeamentos de ID podem ser restritos a intervalos e subconjuntos específicos de IDs, permitindo um controle detalhado sobre os privilégios concedidos aos processos no novo namespace.
Dentro de um namespace de usuário, processos podem ter privilégios de root completos (UID 0) para operações dentro do namespace, enquanto ainda têm privilégios limitados fora do namespace. Isso permite que contêineres sejam executados com capacidades semelhantes a root dentro de seu próprio namespace sem ter privilégios de root completos no sistema host.
Processos podem se mover entre namespaces usando a chamada de sistema setns() ou criar novos namespaces usando as chamadas de sistema unshare() ou clone() com a flag CLONE_NEWUSER. Quando um processo se move para um novo namespace ou cria um, ele começará a usar os mapeamentos de ID de usuário e grupo associados a esse namespace.
Lab:
Create different Namespaces
CLI
sudounshare-U [--mount-proc] /bin/bash
Ao montar uma nova instância do sistema de arquivos /proc se você usar o parâmetro --mount-proc, você garante que o novo namespace de montagem tenha uma visão precisa e isolada das informações do processo específicas para aquele namespace.
Erro: bash: fork: Não é possível alocar memória
Quando unshare é executado sem a opção -f, um erro é encontrado devido à forma como o Linux lida com novos namespaces de PID (ID do Processo). Os detalhes principais e a solução estão descritos abaixo:
Explicação do Problema:
O kernel do Linux permite que um processo crie novos namespaces usando a chamada de sistema unshare. No entanto, o processo que inicia a criação de um novo namespace de PID (referido como o processo "unshare") não entra no novo namespace; apenas seus processos filhos entram.
Executar %unshare -p /bin/bash% inicia /bin/bash no mesmo processo que unshare. Consequentemente, /bin/bash e seus processos filhos estão no namespace de PID original.
O primeiro processo filho de /bin/bash no novo namespace se torna PID 1. Quando esse processo sai, ele aciona a limpeza do namespace se não houver outros processos, já que PID 1 tem o papel especial de adotar processos órfãos. O kernel do Linux então desabilitará a alocação de PID nesse namespace.
Consequência:
A saída de PID 1 em um novo namespace leva à limpeza da flag PIDNS_HASH_ADDING. Isso resulta na falha da função alloc_pid em alocar um novo PID ao criar um novo processo, produzindo o erro "Não é possível alocar memória".
Solução:
O problema pode ser resolvido usando a opção -f com unshare. Esta opção faz com que unshare fork um novo processo após criar o novo namespace de PID.
Executar %unshare -fp /bin/bash% garante que o comando unshare se torne PID 1 no novo namespace. /bin/bash e seus processos filhos são então contidos com segurança dentro deste novo namespace, prevenindo a saída prematura de PID 1 e permitindo a alocação normal de PID.
Ao garantir que unshare seja executado com a flag -f, o novo namespace de PID é mantido corretamente, permitindo que /bin/bash e seus subprocessos operem sem encontrar o erro de alocação de memória.
Para usar o namespace de usuário, o daemon do Docker precisa ser iniciado com --userns-remap=default (No ubuntu 14.04, isso pode ser feito modificando /etc/default/docker e depois executando sudo service docker restart)
sudofind/proc-maxdepth3-typel-nameuser-execreadlink{} \; 2>/dev/null|sort-u# Find the processes with an specific namespacesudofind/proc-maxdepth3-typel-nameuser-execls-l{} \; 2>/dev/null|grep<ns-number>
Entrar dentro de um namespace de usuário
nsenter-UTARGET_PID--pid/bin/bash
Além disso, você só pode entrar em outro namespace de processo se você for root. E você não podeentrar em outro namespace sem um descritor apontando para ele (como /proc/self/ns/user).
# Containersudounshare-U/bin/bashnobody@ip-172-31-28-169:/home/ubuntu$#Check how the user is nobody# From the hostps-ef|grepbash# The user inside the host is still root, not nobodyroot2775627755021:11pts/1000:00:00/bin/bash
Recuperando Capacidades
No caso de namespaces de usuário, quando um novo namespace de usuário é criado, o processo que entra no namespace recebe um conjunto completo de capacidades dentro desse namespace. Essas capacidades permitem que o processo execute operações privilegiadas, como montarsistemas de arquivos, criar dispositivos ou alterar a propriedade de arquivos, mas apenas dentro do contexto do seu namespace de usuário.
Por exemplo, quando você tem a capacidade CAP_SYS_ADMIN dentro de um namespace de usuário, pode realizar operações que normalmente exigem essa capacidade, como montar sistemas de arquivos, mas apenas dentro do contexto do seu namespace de usuário. Quaisquer operações que você realizar com essa capacidade não afetarão o sistema host ou outros namespaces.
Portanto, mesmo que obter um novo processo dentro de um novo namespace de usuário te dará todas as capacidades de volta (CapEff: 000001ffffffffff), você na verdade só pode usar as relacionadas ao namespace (montar, por exemplo), mas não todas. Assim, isso por si só não é suficiente para escapar de um contêiner Docker.
# There are the syscalls that are filtered after changing User namespace with:unshare-UmCpfbashProbando:0x067...ErrorProbando:0x070...ErrorProbando:0x074...ErrorProbando:0x09b...ErrorProbando:0x0a3...ErrorProbando:0x0a4...ErrorProbando:0x0a7...ErrorProbando:0x0a8...ErrorProbando:0x0aa...ErrorProbando:0x0ab...ErrorProbando:0x0af...ErrorProbando:0x0b0...ErrorProbando:0x0f6...ErrorProbando:0x12c...ErrorProbando:0x130...ErrorProbando:0x139...ErrorProbando:0x140...ErrorProbando:0x141...Error<div data-gb-custom-block data-tag="hint" data-style='success'>Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details><summary>Support HackTricks</summary>* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details></div>hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</div></details></div></details></div></details></div></details></div></details></div>
