Skip to content

thread-security-review.adoc

Latest commit

 

History

History
145 lines (105 loc) · 7.66 KB

thread-security-review.adoc

File metadata and controls

145 lines (105 loc) · 7.66 KB
Raw

Chronicle Threads Security Review

Table of Contents

This document summarises security considerations for Chronicle Threads. It is aligned with the shared standards in Chronicle-Quality-Rules/src/main/docs/security-review.adoc and Chronicle-Quality-Rules/src/main/docs/architectural-standards.adoc.

1. Trust Zone and Responsibilities

Chronicle Threads is a Foundation (Zone C) module in the Chronicle stack, as defined in Chronicle-Quality-Rules/src/main/docs/architectural-standards.adoc. It provides scheduling, pauser and monitoring infrastructure that higher-level modules such as Chronicle Queue, Chronicle Network and Chronicle Services depend on. Within this trust zone Chronicle Threads focuses on:

  • predictable execution and resource usage for event loops and pausers;

  • clear boundaries around what it does not do (for example networking, cryptography and business-level access control);

  • avoiding behaviours that would undermine the security guarantees of modules built on top of it.

The remainder of this document expands on these responsibilities and their interaction with ISO 27001 themes.

2. Security Model Overview

Chronicle Threads is a foundational library that orchestrates threads, event loops, pausers and monitoring. It does not accept network connections, parse untrusted payloads directly, or perform cryptographic operations; instead it hosts application-provided EventHandler code and integrates with other Chronicle modules.

Threat boundaries therefore sit at:

  • Handler admission and configuration (which handlers are installed, with what privileges).

  • System properties and configuration files that influence pausers, monitoring and affinity.

  • Dependencies such as Chronicle Core and the Affinity library that perform low-level operations on behalf of Threads.

The following sections describe risks and mitigations at these boundaries.

3. Handler Admission and Privilege Escalation

Why

Handlers execute with the full privileges of the hosting JVM; untrusted code can compromise sensitive data paths.

Core risks

  • Malicious handler registration at runtime via exposed management endpoints (THR-FN-004).

  • Unsandboxed handlers accessing shared mutable state or credentials.

  • Reflection-based injection of handlers that bypass intended builder configuration (THR-FN-001).

Mitigations

  • Restrict handler installation to trusted bootstrap code paths; gate dynamic registration behind authentication and authorisation.

  • Use code reviews and static analysis to enforce least-privilege principles within handlers.

  • Log handler class names and source artefacts during registration for audit trails.

Review hot-spots

  • Deployment scripts that allow arbitrary classpath extensions.

  • OSGi or plugin frameworks injecting handlers dynamically.

4. Affinity and Resource Isolation

Why

Incorrect core binding can leak workload information across tenants or undermine performance isolation.

Core risks

  • Shared core usage permits timing side channels between sensitive workloads.

  • NUMA misalignment causes cross-node memory access patterns exposing high-resolution timing data (THR-FN-017).

  • System properties overridden by untrusted inputs altering affinity strings (THR-OPS-023).

Mitigations

  • Validate affinity strings against an approved list before instantiating EventGroup builders (THR-FN-015).

  • Store affinity selections in configuration repositories with change control.

  • Monitor actual thread-to-core bindings via OS tooling (e.g., taskset, ps -Lo pid,psr) and alert on drift.

Review hot-spots

  • Container orchestrators with relaxed CPU quotas.

  • Multi-tenant hosts lacking hardware partitioning.

5. Monitoring and Telemetry Integrity

Why

Accurate telemetry is essential for detecting anomalous behaviour and limit breaches.

Core risks

  • Attackers disable loop-block monitoring through system properties (THR-OPS-020).

  • Log tampering obscures stack traces that evidence suspicious handler execution times (THR-NF-O-019).

  • Telemetry collectors overloaded by attacker-generated events, leading to blind spots (THR-NF-O-021).

Mitigations

  • Lock down JVM arguments in production; apply checksum or signature validation to launch scripts.

  • Forward critical monitor events to secure log aggregation platforms with tamper detection.

  • Rate-limit telemetry ingestion and validate payload sizes from handlers publishing metrics.

Review hot-spots

  • Support run-books that recommend disabling monitors during troubleshooting.

  • Nodes operating with reduced logging due to storage constraints.

6. Shutdown and Resource Hygiene

Why

Handlers often manage off-heap or file-backed resources via Chronicle Core abstractions; improper shutdown can leak descriptors or expose data.

Core risks

  • EventGroup instances left open, keeping sensitive files mapped (THR-FN-002).

  • Shutdown hooks overridden by untrusted code, preventing orderly release (THR-OPS-025).

  • Race conditions during shutdown causing inconsistent state for dependent services.

Mitigations

  • Apply Chronicle Core’s ReferenceCounted policies, ensuring handlers close dependent resources during loop shutdown.

  • Harden shutdown hook registration; disallow multiple components from mutating the same hook.

  • Capture and audit shutdown logs for every production cycle.

Review hot-spots

  • Handlers that interact with Chronicle Queue or Chronicle Map without corresponding close semantics.

  • Scripted restarts that do not wait for EventGroup.close() completion.

7. Supply Chain and Dependency Considerations

Why

Chronicle Threads relies on Chronicle Core and Affinity; vulnerabilities propagate through these dependencies.

Core risks

  • Outdated dependencies lacking recent security patches or mitigations.

  • Misaligned versions introducing behavioural regressions in pauser or affinity handling.

Mitigations

  • Track dependency versions in BOM files; enforce minimum patch levels aligned with security advisories.

  • Execute dependency-update dry runs in staging to validate core functionality and performance targets.

  • Subscribe to Chronicle Software security bulletins and integrate alerts into incident response procedures.

Review hot-spots

  • Custom forks of Chronicle libraries.

  • Environments that block outbound network access, delaying vulnerability scanning updates.

8. Summary Against ISO 27001 Themes

Secure coding and bounds checking (A.8.28)

  • Chronicle Threads itself does not parse external payloads; input validation and bounds checking for business data reside in callers such as Chronicle Queue or application handlers.

  • Within the module, system properties that influence behaviour are validated for type and constrained to documented ranges where applicable (for example thresholds and timeouts).

Access control and privileged operations (A.8.3)

  • Chronicle Threads does not implement authentication or authorisation; it runs with the privileges of the hosting JVM.

  • Operational controls should ensure only trusted code can register handlers or modify JVM arguments, and that handler classes are reviewed under least-privilege principles.

Cryptographic and network controls (A.8.22, A.8.24)

  • The module does not implement cryptography or manage keys directly, nor does it open network sockets.

  • When Chronicle Threads hosts handlers that use TLS or network stacks from other libraries, those components’ security guides and configuration must be followed.

Vulnerability management (A.8.8)

  • Dependency versions are controlled via Chronicle BOMs; vulnerability scanning and CVE tracking are handled at the organisation level across all modules.

  • Teams using Chronicle Threads should ensure their BOM is kept current and that central security advisories are applied.