Structured Hardening Project

Fedora Tier 1 — Threat Model

Formal adversary and boundary model for Fedora Tier 1 Baseline Hardening.

Fedora Tier 1 defines a bounded baseline hardening posture for Fedora Linux desktop and server deployments.

It reduces exposure to common and scalable attack classes while preserving normal operational usability.

It does not attempt to provide high-assurance, nation-state, or laboratory-resistance guarantees.

Certification meaning is limited to the boundaries defined below.


1. Adversary Model

Tier 1 is designed to reduce risk from:

  • Automated internet scanning
  • Commodity malware
  • Exploitation of publicly known vulnerabilities
  • Phishing and credential harvesting
  • Basic account takeover attempts

Tier 1 does not model:

  • Targeted exploit development
  • Custom exploit chains
  • Long-term campaign-based operations
  • Hardware-level attack development
  • Unlimited-resource adversaries

2. Adversary Objectives Considered

Tier 1 aims to reduce likelihood of:

  • Data exfiltration
  • Persistent surveillance using common techniques
  • Account compromise through known or automated methods

Tier 1 does not claim resistance to:

  • Strategic infrastructure disruption
  • Coordinated supply chain attacks
  • Long-term intelligence collection operations

3. Physical Access Assumptions

Tier 1 assumes:

  • No physical access by an adversary, or
  • Brief unattended access measured in minutes

Tier 1 does not attempt to resist:

  • Extended unattended physical access
  • Temporary device seizure
  • Laboratory analysis
  • Hardware tampering

4. Supply Chain Assumptions

Tier 1 assumes:

  • Official Fedora distribution channels
  • Intact upstream signing infrastructure

Tier 1 does not model:

  • Repository compromise
  • Mirror poisoning
  • Firmware tampering
  • Hardware interdiction

5. Coercion Assumptions

Tier 1 assumes no active legal or coercive authority targeting the device owner.

Tier 1 does not provide protection against:

  • Warranted device seizure
  • Compelled credential disclosure
  • Legal compulsion mechanisms

6. Trust Boundaries

Tier 1 trust model:

  • Hardware trusted as shipped
  • Firmware trusted
  • Fedora signing keys trusted
  • Update infrastructure trusted
  • Administrative user trusted
  • Hostile internet assumed
  • DNS and public certificate authorities trusted

Tier 1 does not attempt to reduce trust in upstream infrastructure.


7. Side-Channel Domain

Tier 1 does not model or mitigate:

  • Speculative execution attacks
  • Memory disturbance attacks
  • Direct memory access attacks
  • Cold boot attacks
  • Cache timing analysis
  • Power analysis

Mitigation of hardware-level side channels is outside Tier 1 scope.


8. Post-Compromise Model

Tier 1 does not assume compromise is impossible.

Its objective is to:

  • Reduce likelihood of trivial or automated compromise
  • Reduce exposure to common persistence techniques
  • Provide a structured, verifiable configuration baseline

Tier 1 does not guarantee:

  • Structured containment after compromise
  • Kernel-level survivability
  • Resistance to advanced persistence engineering

9. Explicit Non-Goals

Fedora Tier 1 does not provide:

  • Anonymity guarantees
  • Anti-forensic guarantees
  • Zero-click exploit resistance
  • Advanced persistent adversary resistance
  • Hardware-level tamper resistance
  • Supply chain interdiction resistance
  • Protection against state-level coercion

Certification reflects configuration state within the defined bounds only.


10. Explicit Security Ceiling

Fedora Tier 1 is not designed to resist:

  • Targeted exploit development or campaign-based operations
  • Extended physical access or device seizure
  • Repository or distribution infrastructure compromise
  • Firmware or hardware manipulation
  • Legal compulsion or credential disclosure demands

Where adversary capability exceeds these bounds, Tier 1 certification does not represent an aligned security posture.


11. Purpose of Tier 1

Tier 1 establishes a structured, machine-verifiable security baseline for Fedora Linux systems.

It exists to:

  • Reduce exposure to scalable compromise
  • Provide deterministic hardening
  • Define clear threat boundaries
  • Enable transparent, bounded certification

Tier 1 is a defined baseline within explicit limits.


12. Threat Boundary Summary

Domain Tier 1 Position Outside Scope
Adversary Capability Opportunistic and skilled criminal activity using known techniques Targeted exploit development, campaign-based operations
Physical Access No access or brief unattended exposure Extended access, seizure, laboratory control
Supply Chain Official Fedora distribution assumed intact Repository compromise, mirror poisoning, firmware tampering
Coercion No active legal compulsion Warranted seizure, compelled credential disclosure
Side-Channel Not modeled Hardware-level attack classes

Tier 1 certification is valid only within these defined boundaries.


13. Boundary Interpretation

The inner boundary represents adversary activity Tier 1 is designed to reduce exposure against.

Threat classes outside that boundary — including targeted exploit development, extended physical access, supply chain compromise, and hardware-level manipulation — fall beyond Tier 1’s defined security posture.

Certification applies only within the defined boundary.

Fedora Tier 1 Threat Boundary Diagram

14. Who Tier 1 Is For

Tier 1 is appropriate for individuals and organisations operating in normal hostile internet conditions who wish to reduce exposure to common and scalable compromise without adopting high-friction operational models. It is suited to professional, business, and personal computing environments where usability must be preserved and the anticipated adversary is not conducting targeted exploit development or physical seizure operations.


15. Governance Reference

This threat model is defined under:

  • Structured Hardening Project (SHP) Charter v1.1
  • Fedora Hardening — Tier 1 Technical Specification v2.2

Certification meaning is bound to the specification version in force at issuance. Subsequent specification revisions do not retroactively alter previously issued certificates unless explicitly security-critical.