From aac96b8394d19e1187be1a57566f2cc5970f4f29 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 5 Aug 2025 04:34:29 +0000 Subject: [PATCH] Translated ['src/linux-hardening/privilege-escalation/docker-security/na --- .../namespaces/time-namespace.md | 82 ++++++++++++++++++- 1 file changed, 80 insertions(+), 2 deletions(-) diff --git a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md index df965bb8a..38e4583ff 100644 --- a/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md +++ b/src/linux-hardening/privilege-escalation/docker-security/namespaces/time-namespace.md @@ -24,7 +24,7 @@ Quando `unshare` é executado sem a opção `-f`, um erro é encontrado devido 1. **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 o fazem. +- 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. @@ -55,8 +55,86 @@ sudo find /proc -maxdepth 3 -type l -name time -exec readlink {} \; 2>/dev/null # Find the processes with an specific namespace sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | grep ``` -### Entrar em um namespace de Tempo +### Entrar dentro de um namespace de tempo ```bash nsenter -T TARGET_PID --pid /bin/bash ``` +## Manipulando Deslocamentos de Tempo + +A partir do Linux 5.6, dois relógios podem ser virtualizados por namespace de tempo: + +* `CLOCK_MONOTONIC` +* `CLOCK_BOOTTIME` + +Seus deltas por namespace são expostos (e podem ser modificados) através do arquivo `/proc//timens_offsets`: +``` +$ sudo unshare -Tr --mount-proc bash # -T creates a new timens, -r drops capabilities +$ cat /proc/$$/timens_offsets +monotonic 0 +boottime 0 +``` +O arquivo contém duas linhas - uma por relógio - com o deslocamento em **nanosegundos**. Processos que possuem **CAP_SYS_TIME** _no namespace de tempo_ podem alterar o valor: +``` +# advance CLOCK_MONOTONIC by two days (172 800 s) +echo "monotonic 172800000000000" > /proc/$$/timens_offsets +# verify +$ cat /proc/$$/uptime # first column uses CLOCK_MONOTONIC +172801.37 13.57 +``` +Se você precisar que o relógio de parede (`CLOCK_REALTIME`) também mude, você ainda terá que depender de mecanismos clássicos (`date`, `hwclock`, `chronyd`, …); ele **não** é namespace. + +### `unshare(1)` flags auxiliares (util-linux ≥ 2.38) +``` +sudo unshare -T \ +--monotonic="+24h" \ +--boottime="+7d" \ +--mount-proc \ +bash +``` +As opções longas escrevem automaticamente os deltas escolhidos em `timens_offsets` logo após o namespace ser criado, salvando um `echo` manual. + +--- + +## Suporte OCI & Runtime + +* A **Especificação de Runtime OCI v1.1** (Nov 2023) adicionou um tipo de namespace `time` dedicado e o campo `linux.timeOffsets` para que os motores de contêiner possam solicitar virtualização de tempo de maneira portátil. +* **runc >= 1.2.0** implementa essa parte da especificação. Um fragmento mínimo de `config.json` se parece com: +```json +{ +"linux": { +"namespaces": [ +{"type": "time"} +], +"timeOffsets": { +"monotonic": 86400, +"boottime": 600 +} +} +} +``` +Então execute o contêiner com `runc run `. + +> NOTA: runc **1.2.6** (Fev 2025) corrigiu um bug de "execução em contêiner com timens privado" que poderia levar a um travamento e potencial DoS. Certifique-se de que você está na versão ≥ 1.2.6 em produção. + +--- + +## Considerações de segurança + +1. **Capacidade necessária** – Um processo precisa de **CAP_SYS_TIME** dentro de seu namespace de usuário/tempo para alterar os offsets. Remover essa capacidade no contêiner (padrão no Docker & Kubernetes) impede manipulações. +2. **Sem alterações no relógio** – Como `CLOCK_REALTIME` é compartilhado com o host, atacantes não podem falsificar a duração dos certificados, expiração de JWT, etc. apenas via timens. +3. **Evasão de log/detecção** – Software que depende de `CLOCK_MONOTONIC` (por exemplo, limitadores de taxa baseados em tempo de atividade) pode ser confundido se o usuário do namespace ajustar o offset. Prefira `CLOCK_REALTIME` para timestamps relevantes à segurança. +4. **Superfície de ataque do kernel** – Mesmo com `CAP_SYS_TIME` removido, o código do kernel permanece acessível; mantenha o host atualizado. Linux 5.6 → 5.12 recebeu várias correções de bugs timens (NULL-deref, problemas de sinalização). + +### Lista de verificação de hardening + +* Remova `CAP_SYS_TIME` no perfil padrão do seu runtime de contêiner. +* Mantenha os runtimes atualizados (runc ≥ 1.2.6, crun ≥ 1.12). +* Fixe util-linux ≥ 2.38 se você depender dos auxiliares `--monotonic/--boottime`. +* Audite o software dentro do contêiner que lê **uptime** ou **CLOCK_MONOTONIC** para lógica crítica de segurança. + +## Referências + +* man7.org – Página do manual de namespaces de tempo: +* Blog OCI – "OCI v1.1: novos namespaces de tempo e RDT" (15 de Nov 2023): + {{#include ../../../../banners/hacktricks-training.md}}