|
| 1 | +# Security Policy |
| 2 | + |
| 3 | +## Overview |
| 4 | +Axiom OS is a research prototype focused on proportional-cost per-read provenance and file integrity. While security is a first-class citizen in the design of the provenance layer, the kernel is currently in an **alpha/research state**. |
| 5 | + |
| 6 | +We welcome security research, vulnerability reports, and feedback that help strengthen the architecture. |
| 7 | + |
| 8 | +## Supported Versions |
| 9 | + |
| 10 | +Currently, security updates and patches are only provided for the latest development branch. |
| 11 | + |
| 12 | +| Version | Supported | |
| 13 | +| ------- | ------------------ | |
| 14 | +| v0.3.0 | :white_check_mark: | |
| 15 | +| < v0.3.0| :x: | |
| 16 | + |
| 17 | +## Reporting a Vulnerability |
| 18 | + |
| 19 | +**Please do not report security vulnerabilities through public GitHub issues.** |
| 20 | + |
| 21 | +If you discover a security vulnerability, please report it through one of the following methods: |
| 22 | + |
| 23 | +1. **Email:** 8292aniarc@gmail.com |
| 24 | +2. **GitHub Private Vulnerability Reporting:** Please use the "Report a vulnerability" button under the **Security and Quality** tab. |
| 25 | + |
| 26 | +### What to Include |
| 27 | +To help us triage the report quickly, please include: |
| 28 | +- A description of the vulnerability and its potential impact. |
| 29 | +- Steps to reproduce the issue (ideally within the QEMU environment). |
| 30 | +- Any proof-of-concept (PoC) code or shell commands (e.g., using the `tamper` command to show a bypass). |
| 31 | + |
| 32 | +## Our Disclosure Process |
| 33 | +Once a report is received: |
| 34 | +1. We will acknowledge receipt of your report within 48-72 hours. |
| 35 | +2. We will investigate the issue and confirm the vulnerability. |
| 36 | +3. If confirmed, we will work on a fix in a private branch. |
| 37 | +4. We will coordinate a disclosure date with you before making the fix public. |
| 38 | + |
| 39 | +## Threat Model & Scope |
| 40 | +Please refer to the **Threat Model** section in the `README.md` for the current security assumptions. |
| 41 | + |
| 42 | +### In-Scope for Research: |
| 43 | +- Bypassing the BLAKE3 block-level integrity verification. |
| 44 | +- Escalating privileges from the Shell/User mode to Kernel mode. |
| 45 | +- Breaking the CR3-based process isolation. |
| 46 | +- Vulnerabilities in the Mitra DSL execution path. |
| 47 | + |
| 48 | +### Out-of-Scope: |
| 49 | +- Hardware-level attacks (e.g., Rowhammer) that are explicitly excluded from the current threat model. |
| 50 | +- Denial of Service (DoS) attacks that simply crash the kernel (since it is a single-core research prototype). |
| 51 | +- Issues requiring physical access or DMA-capable peripherals. |
| 52 | + |
| 53 | +## Acknowledgments |
| 54 | +We value the work of independent security researchers. If you report a valid vulnerability that leads to a fix, we are happy to credit you. |
0 commit comments