Time Namespace

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Огляд

Простір імен часу віртуалізує вибрані годинники, особливо CLOCK_MONOTONIC та CLOCK_BOOTTIME. Це новіший і більш спеціалізований namespace, ніж mount, PID, network або user namespaces, і це рідко перше, про що думає оператор при обговоренні container hardening. Навіть так, він є частиною сучасного namespace family і вартий концептуального розуміння.

Головна мета — дозволити процесу спостерігати керовані зсуви для певних годинників без зміни глобального уявлення часу на хості. Це корисно для checkpoint/restore workflows, deterministic testing та деякої просунутої поведінки runtime. Зазвичай це не є основним засобом ізоляції так само, як mount або user namespaces, але він усе одно сприяє тому, щоб середовище процесу було більш автономним.

Лаб

Якщо ядро хоста та userspace підтримують це, ви можете інспектувати простір імен за допомогою:

sudo unshare --time --fork bash
ls -l /proc/self/ns/time /proc/self/ns/time_for_children
cat /proc/$$/timens_offsets 2>/dev/null

Підтримка залежить від версій ядра та інструментів, тому ця сторінка більше спрямована на розуміння механізму, ніж на очікування, що він буде доступний у кожному лабораторному середовищі.

Часові зсуви

Простори імен часу в Linux віртуалізують зсуви для CLOCK_MONOTONIC та CLOCK_BOOTTIME. Поточні зсуви для кожного простору імен доступні через /proc/<pid>/timens_offsets, які на ядрах з підтримкою також можуть бути змінені процесом, що має CAP_SYS_TIME всередині відповідного простору імен:

sudo unshare -Tr --mount-proc bash
cat /proc/$$/timens_offsets
echo "monotonic 172800000000000" > /proc/$$/timens_offsets
cat /proc/uptime

Файл містить зміни в наносекундах. Зміна monotonic на два дні змінює uptime-подібні спостереження всередині цього namespace, не змінюючи системного годинника хоста.

unshare Helper Flags

Останні версії util-linux надають зручні прапори, які автоматично записують зсуви:

sudo unshare -T --monotonic="+24h" --boottime="+7d" --mount-proc bash

Ці прапорці здебільшого покращують зручність використання, але вони також полегшують розпізнавання цієї функції в документації та тестуванні.

Використання під час виконання

Time namespaces є новішими і застосовуються рідше, ніж mount або PID namespaces. OCI Runtime Specification v1.1 додала явну підтримку для time простору імен та поля linux.timeOffsets, а новіші релізи runc реалізують цю частину моделі. Мінімальний фрагмент OCI виглядає так:

{
"linux": {
"namespaces": [
{ "type": "time" }
],
"timeOffsets": {
"monotonic": 86400,
"boottime": 600
}
}
}

Це важливо, тому що перетворює time namespacing з нішевого примітиву ядра на те, що runtimes можуть запитувати портably.

Вплив на безпеку

Існує менше класичних історій про breakout, зосереджених на time namespace, ніж на інших типах namespace. Ризик тут зазвичай не в тому, що time namespace безпосередньо дозволяє escape, а в тому, що читачі повністю ігнорують його й через це не помічають, як просунуті runtimes можуть формувати поведінку процесів. У спеціалізованих середовищах змінені уявлення про час можуть впливати на checkpoint/restore, observability або судово-експертні припущення.

Зловживання

Зазвичай тут немає прямого примітиву для breakout, але змінена поведінка годинника все ще може бути корисною для розуміння середовища виконання та виявлення просунутих функцій runtime:

readlink /proc/self/ns/time
readlink /proc/self/ns/time_for_children
date
cat /proc/uptime

Якщо ви порівнюєте два процеси, відмінності тут можуть допомогти пояснити незвичну часову поведінку, артефакти checkpoint/restore або невідповідності в логах, специфічні для середовища.

Вплив:

  • майже завжди reconnaissance або розуміння середовища
  • корисно для пояснення невідповідностей у логах, uptime або аномалій checkpoint/restore
  • зазвичай самі по собі не є прямим механізмом container-escape

Важлива деталь щодо зловживання: time namespaces не віртуалізують CLOCK_REALTIME, тож самі по собі вони не дозволяють атакуючому сфальсифікувати системний годинник хоста або безпосередньо порушити certificate-expiry перевірки на рівні всієї системи. Їхня цінність переважно у заплутуванні логіки на основі монотонного часу, відтворенні багів, специфічних для середовища, або у розумінні просунутої runtime поведінки.

Перевірки

Ці перевірки в основному стосуються підтвердження того, чи використовує runtime приватний time namespace взагалі.

readlink /proc/self/ns/time                 # Current time namespace identifier
readlink /proc/self/ns/time_for_children    # Time namespace inherited by children
cat /proc/$$/timens_offsets 2>/dev/null     # Monotonic and boottime offsets when supported

Що тут цікаво:

  • У багатьох середовищах ці значення не призведуть до негайного виявлення проблеми безпеки, але вони вказують, чи використовується спеціалізована runtime-функція.
  • Якщо ви порівнюєте два процеси, відмінності тут можуть пояснити збиваючу з пантелику поведінку, пов’язану з таймінгом або операціями checkpoint/restore.

Для більшості container breakouts, time namespace не є першою контрольною точкою, яку ви будете досліджувати. Проте повний розділ container-security має згадати його, оскільки він є частиною сучасної моделі ядра і час від часу має значення в просунутих runtime-сценаріях.

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks