From cf9372e7669214e521f1b2f63af80e9f4c4e5692 Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Wed, 30 Jul 2025 08:31:34 +0000 Subject: [PATCH] Add content from: Research Update: Enhanced src/linux-hardening/privilege-esca... --- .../namespaces/time-namespace.md | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) 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 fd28c52c66c..dc252b88941 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 @@ -69,6 +69,92 @@ sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | nsenter -T TARGET_PID --pid /bin/bash ``` + +## Manipulating Time Offsets + +Starting with Linux 5.6, two clocks can be virtualised per time namespace: + +* `CLOCK_MONOTONIC` +* `CLOCK_BOOTTIME` + +Their per-namespace deltas are exposed (and can be modified) through the file `/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 +``` + +The file contains two lines – one per clock – with the offset in **nanoseconds**. Processes that hold **CAP_SYS_TIME** _in the time namespace_ can change the value: + +``` +# 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 +``` + +If you need the wall clock (`CLOCK_REALTIME`) to change as well you still have to rely on classic mechanisms (`date`, `hwclock`, `chronyd`, …); it is **not** namespaced. + + +### `unshare(1)` helper flags (util-linux ≥ 2.38) + +``` +sudo unshare -T \ + --monotonic="+24h" \ + --boottime="+7d" \ + --mount-proc \ + bash +``` + +The long options automatically write the chosen deltas to `timens_offsets` right after the namespace is created, saving a manual `echo`. + +--- + +## OCI & Runtime support + +* The **OCI Runtime Specification v1.1** (Nov 2023) added a dedicated `time` namespace type and the `linux.timeOffsets` field so that container engines can request time virtualisation in a portable way. +* **runc >= 1.2.0** implements that part of the spec. A minimal `config.json` fragment looks like: + ```json + { + "linux": { + "namespaces": [ + {"type": "time"} + ], + "timeOffsets": { + "monotonic": 86400, + "boottime": 600 + } + } + } + ``` + Then run the container with `runc run `. + +> NOTE: runc **1.2.6** (Feb 2025) fixed an "exec into container with private timens" bug that could lead to a hang and potential DoS. Make sure you are on ≥ 1.2.6 in production. + +--- + +## Security considerations + +1. **Required capability** – A process needs **CAP_SYS_TIME** inside its user/time namespace to change the offsets. Dropping that capability in the container (default in Docker & Kubernetes) prevents tampering. +2. **No wall-clock changes** – Because `CLOCK_REALTIME` is shared with the host, attackers cannot spoof certificate lifetimes, JWT expiry, etc. via timens alone. +3. **Log / detection evasion** – Software that relies on `CLOCK_MONOTONIC` (e.g. rate-limiters based on uptime) can be confused if the namespace user adjusts the offset. Prefer `CLOCK_REALTIME` for security-relevant timestamps. +4. **Kernel attack surface** – Even with `CAP_SYS_TIME` removed, the kernel code remains accessible; keep the host patched. Linux 5.6 → 5.12 received multiple timens bug-fixes (NULL-deref, signedness issues). + +### Hardening checklist + +* Drop `CAP_SYS_TIME` in your container runtime default profile. +* Keep runtimes updated (runc ≥ 1.2.6, crun ≥ 1.12). +* Pin util-linux ≥ 2.38 if you rely on the `--monotonic/--boottime` helpers. +* Audit in-container software that reads **uptime** or **CLOCK_MONOTONIC** for security-critical logic. + +## References + +* man7.org – Time namespaces manual page: +* OCI blog – "OCI v1.1: new time and RDT namespaces" (Nov 15 2023): + {{#include ../../../../banners/hacktricks-training.md}}