Linux Time Namespace Operations

A skill for working with Linux time namespaces in security analysis, container hardening, and privilege escalation research.

What Time Namespaces Do

Time namespaces allow per-namespace offsets to the system monotonic and boot-time clocks. They're used to:

• Change date/time within containers
• Adjust clocks after checkpoint/snapshot restoration
• Isolate time-based operations between processes

Important:

CLOCK_REALTIME

(wall clock) is not namespaced. Only

CLOCK_MONOTONIC

and

CLOCK_BOOTTIME

can be virtualized per namespace.

Creating Time Namespaces

Using unshare (CLI)

# Basic time namespace creation
sudo unshare -T --mount-proc /bin/bash

# With fork to avoid PID allocation issues
sudo unshare -Tf --mount-proc /bin/bash

# With time offset helpers (util-linux >= 2.38)
sudo unshare -T \
            --monotonic="+24h" \
            --boottime="+7d" \
            --mount-proc \
            bash

Why

--mount-proc

matters: Mounting a new

/proc

instance ensures the namespace has an accurate, isolated view of process information specific to that namespace.

Why

-f

matters: Without

-f

, the unshare process doesn't enter the new namespace—only its children do. This can cause "Cannot allocate memory" errors when PID 1 exits prematurely. The

-f

flag forks a new process, making unshare itself PID 1 in the new namespace.

Using Docker

docker run -ti --name ubuntu1 -v /usr:/ubuntu1 ubuntu bash

Using runc (OCI Runtime)

For runc >= 1.2.0, create a

config.json

with time namespace support:

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

Then run:

runc run <container-id>

Security note: runc 1.2.6 (Feb 2025) fixed an "exec into container with private timens" bug that could cause hangs and DoS. Use >= 1.2.6 in production.

Inspecting Time Namespaces

Check your current namespace

ls -l /proc/self/ns/time
# Output: time:[4026531834]

Find all time namespaces on the system

sudo find /proc -maxdepth 3 -type l -name time -exec readlink {} \; 2>/dev/null | sort -u

Find processes in a specific namespace

# Replace <ns-number> with the namespace ID from above
sudo find /proc -maxdepth 3 -type l -name time -exec ls -l {} \; 2>/dev/null | grep <ns-number>

Enter an existing time namespace

nsenter -T TARGET_PID --pid /bin/bash

Manipulating Time Offsets

Starting with Linux 5.6, time namespace offsets are exposed via

/proc/<PID>/timens_offsets

.

View current offsets

sudo unshare -Tr --mount-proc bash
cat /proc/$$/timens_offsets
# Output:
# monotonic 0
# boottime  0

Modify offsets (requires CAP_SYS_TIME in the namespace)

# Advance CLOCK_MONOTONIC by two days (172,800 seconds = 172,800,000,000,000 nanoseconds)
echo "monotonic 172800000000000" > /proc/$$/timens_offsets

# Verify the change
cat /proc/$$/uptime
# First column uses CLOCK_MONOTONIC

Format: The file contains two lines with offsets in nanoseconds:

• Line 1:

  monotonic <nanoseconds>

• Line 2:

  boottime <nanoseconds>

Using unshare helpers (util-linux >= 2.38)

Instead of manually editing

timens_offsets

, use the long options:

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

This automatically writes the deltas after namespace creation.

Security Considerations

Required Capabilities

A process needs CAP_SYS_TIME inside its user/time namespace to change offsets. Dropping this capability in containers (default in Docker & Kubernetes) prevents tampering.

What Cannot Be Spoofed

Because

CLOCK_REALTIME

is shared with the host, attackers cannot spoof:

• Certificate lifetimes
• JWT expiry times
• Wall-clock-based authentication tokens

Attack Vectors to Watch

1. Log/detection evasion: Software relying on

   CLOCK_MONOTONIC

   (e.g., rate limiters based on uptime) can be confused by namespace offset adjustments.

2. Kernel attack surface: Even with

   CAP_SYS_TIME

   removed, kernel code remains accessible. Linux 5.6 → 5.12 received multiple timens bug-fixes (NULL-deref, signedness issues).

3. runc vulnerabilities: Versions before 1.2.6 had an exec-into-container bug causing hangs and potential DoS.

Hardening Checklist

Apply these measures when securing containerized environments:

• Drop

  CAP_SYS_TIME

  in container runtime default profiles
• Keep runtimes updated (runc >= 1.2.6, crun >= 1.12)
• Pin util-linux >= 2.38 if using

  --monotonic/--boottime

  helpers
• Audit in-container software that reads uptime or CLOCK_MONOTONIC for security-critical logic
• Prefer

  CLOCK_REALTIME

  for security-relevant timestamps
• Keep the host kernel patched

Common Use Cases

Container Time Isolation

Use time namespaces to:

• Run containers with independent clock views
• Test time-sensitive applications without affecting the host
• Restore containers from checkpoints with adjusted clocks

Security Research

Time namespaces are useful for:

• Understanding container isolation boundaries
• Testing time-based security controls
• Researching privilege escalation paths involving time manipulation

Debugging Time-Related Issues

When applications behave unexpectedly due to time:

• Check which namespace the process is in
• Inspect

  timens_offsets

  for unexpected values
• Verify if the application uses

  CLOCK_MONOTONIC

  vs

  CLOCK_REALTIME

References

• man7.org – Time namespaces manual page
• OCI blog – "OCI v1.1: new time and RDT namespaces" (Nov 15 2023)
• Linux kernel documentation – Time namespaces