(This page is still a rough draft.)

The security policy is based on the name of the overlay, with the focus on eliminating performance slow downs that manifest as memory leaks, heavy I/O, large FPS drops. The overlay is also interested in a crashless experience.

• Denial of Service mitigations first
• Patched vulnerabilities are best effort
• Version bumps to eliminate EOL versions
• Prioritizing fixes over newer releases
• Triaging broken ebuilds and mitigating against vulnerability/update backlog

The policy is based on the implications of Godel's Incompleteness Theorem. See also hardware vulnerabilities.

For example, if the software has pointer security gaurantees but relies on hardware which was later to be discovered with a design flaw in the pointer security, then it cannot be easily fixed and maybe the hardware needs to be replaced.

For example, if the software requires a Rust component that uses GTK3 but the fix in the GTK4 release. The fix will be likely skipped until upstream updates both the Rust dependencies and the code that references those libraries. Most of the vulnerable cargo packages will be bumped to non-vulernable except for this breaking GTK4 change.

The current security posture of this overlay is neutral-defensive.

• Default well tested and secure upstream settings (neutral posture)
• Proactive vulnerability discovery and remediation (defensive posture)

• Zero Click Attack (ZCA) - a network based attack that doesn't require UI interaction and no changes in privileges are necessary (AV:N UI:N PR:N)
• Social Engineering Attack (SEA) - a type of attack that manipulates the user by deceptive Hollywood acting to change or gain sensitive information
• Spoof Attack (SA) - a type of attack that uses look-alike deception to trick users into using the attacker's asset or website
• C:H - high confidentiality loss possible, serious impact possible, all sensitive information can be disclosed
• C:L - low confidentiality loss possible, miniscule impact possible, some information can be disclosed
• I:H - high data integrity loss possible, serious impact possible, full data integrity loss or full modification of data files or security metadata or user privileges
• I:L - low data integrity loss possible, miniscule impact possible, possiblity of integrity loss or partial modification that may lead to serious loss
• A:H - high availablity loss possible, serious impact possible, completely unavailable resources
• A:L - low availability loss possible, miniscule impact possible, partial or full available resources with possibly degraded performance
• E:E - Exploiting the vulnerability could be easy
• E:D - Exploiting the vulnerability could be difficult
• VS - the impact vectors in the center of the blast radius in CVSS 4
• SS - the impact vectors beyond the center of the blast radius in CVSS 4
• EBR - Extended blast radius but not full blast radius in CVSS 3.1

• Higher severities means more attacker capabilities or root-like.
• Lower severities means less attacker capabilities or jail-like.
• The score is an approximation and weight of the attacker capabilities may disagree.
• Don't let the partial impact vector fool you. It can be part of an attack chain leading to a more dangerous attack, social engineering attack (SEA), or spoof attack (SA).

The remediation response times apply to this overlay only and may actually be longer.

The proper total remediation time is ebuild developer time + administrator time.

Total remediation time for customers should be 12 days before billing time ends. This is the overlay's primary demographic.

Let's take web browsers for example with two proper remediation periods.

The first remediation period should start immediately after the billing deadline (16th of the month) for early spender personalities. The browser should be secure ready at the beginning of the month.

The second remediation period should start at 1st of the month for last minute spenders personalities. The browser should be secure ready to use a few days before the deadline.

The initial start time is not always constant in reality due to backlogs, package triage fairness, or understaffing.

Remediation start time happens when there is a version bump and the period is relative to that release date. Usually the point release and the security advisory date are relatively close.

Total remediation time for organizations and businesses should be 4 hours or less before elevated worry time from service disruptions, user performance stress, or aligned with the system maintenance period. This case is not supported due to the lack of developers.

This case applies to web services, web servers, game servers, or kiosk applications assuming continuous uninterrupted availability with performance problems resolved quickly.

This overlay uses an EPSS score of 5% or above as the threshold for remediation or triage which the package will be seriously evaluated for security fixes or being dropped. 5% because it is over 2/3 coverage of observed vulnerabilities (aka exploited in the wild) in the model or about Grade C (70%) coverage. The overlay tries to aim or converge towards an EPSS score less than 1% for remediation which typically the vulnerabilities are difficult to fix or may have high complexity to exploit which translates to Grade B (80%) coverage in the model. Vulnerabilities less than 1% may be ignored for long periods of time and considered low risk of being exploited. Rust, Node, Electron based packages with scanned lock files will be evaluated for EPSS score first. As a fallback, CVEs will be EPSS randomly evaluated. The highest EPSS scores get triaged first when the objective is to reduce the EPSS set to less than 5% score. Scores closest to 100% indicate that the vulnerability may be actively or likely exploited in the next 30 days.

In short for this overlay,

• EPSS scores of [5%, 100%] must be triaged.
• EPSS scores of [1%, 5%) may be optionally or conveniently triaged, but provided as a carrot on a stick motivator to achieve 80%-90% coverage of the in the wild set or the observed vulnerabilities in the model/example.
• EPSS scores of [0%, 1%) are ignored.

(Previously, it was 10% which was suggested by an AI. 10% is a nice number because it is easy to remember. After research, the threshold is changed based on a grade school perspective or a gamer perspective.)

0. Ebuilds that block (security) updates
1. Fixing untested ebuilds
2. Critical severity vulernabilities
3. High severity vulernabilities
4. Bumping versions for high value assets with weekly or biweekly vulnerability recurrence intervals
5. Zero click attack
6. Uncaught Information Disclosure (ID)
7. Uncaught Data Tampering (DT)
8. Uncaught Denial of Service (DoS)
9. Uncaught security vulnerability advisories
10. Memory leaks (CWE-401)
11. Heavy I/O (CWE-400, CWE-770)
12. Modifying or speeding up ebuilds to mitigate against vulnerability backlog
13. Bumping EOL software (CWE-1104)
14. Pruning or substituting EOL software (CWE-1329)
15. Testing untested software (CWE-1357)

Mitigation is limited or disallowed due to legal reasons. You can try to report it upstream, but many times it is ignored.

It is recommended to use open source packages whenever possible.

Report it as an issue request but only if it has a patch or fixed in a particular version.

The issue report should have the following:

• Summary (recommended)
• Packages affected (required)
• CVE ID (optional)
• Either a CVSS 3.1 vector string, vulnerability classes, or universally recognized bug name (required)
  • Vulernability classes (multiple allowed):
    • DoS - Denial of Service - e.g. crash, memory leak - same as availability in CVSS 3.1
    • DT - Data Tampering - e.g. corrupted data, compromised data integrity - same as integrity in CVSS 3.1
    • ID - Information Disclosure - e.g. sensitive data leak - same as confidentiality in CVSS 3.1
  • Universally recognized bug names:
    • Null Pointer Dereference
    • Free After Use
    • Double Free
    • Race Condition
    • Sandbox Escape
    • Improper Permissions
    • Privilege Escalation
    • Arbitrary Code Execution
    • Supply Chain Attack
    • Malware
    • See the CWE website or https://github.com/orsonteodoro/oiledmachine-overlay/blob/master/eclass/vf.eclass
• CWE ID (optional)
• A patch or version(s) that fixes it (required)

These generally should not be reported. They may be reported on these cases:

• Proprietary software packages to encorage switching to open source packages or to encourage that vendor to fix the package.
• It was reported upstream but upstream does not want to fix it after 2 or 4 year(s) it was reported, or if those versions are EOL. If it was EOL, note it so we can bump the package.
• If the vulnerability is Information Disclosure (ID), Data Tampering (DT), Privilege Escalation (PE), Arbitary Code Execution (CE), or two or more classes of vulnerabilities please report it to upstream first privately, especially if upstream has a bug bounty program. DO NOT SEND AN ISSUE REQUEST YET.
• If the vulnerability is strictly a Denial of Service (DoS) vulnerability, you may report it here as an issue request here and on the upstream repo.
• If you suspect that this DoS is linked to ID or DT, report it privately to upstream. DO NOT SEND AN ISSUE REQUEST YET.
• If the vulnerability has a critical to high severity and in the wild and being actively exploited but the vendor is unwilling to fix it, it is recommended to discuss in private first. DO NOT SEND AN ISSUE REQUEST YET.

If you make a report, there is a chance it will be ignored or closed so don't be offended.

The report may be done via issue request but only if it contains no sensitive information, no personal attacks, and nothing that violates the website rules.

This overlay accepts AI based security fixes. If the compiler or a runtime error is reported or encountered that is a common memory corruption or undefined behavior, it could be fixed.

AI qualifications:

• The AI must be able to recognize open source licenses.

• The AI must be able to submit contributions under approved open source licenses.

• The AI must be able to understand CVEs.

• The AI must be able to fix ASan, UBSan type of errors.

• The AI must have code generation capabilities.

• AI have been observed to fix the following memory corruption or undefined behavior classes of vulnerabilities. Patch fixes are accepted for the following:

  • Dangling Pointer (-Wdangling-pointer=; CE, PE, DoS, DT, ID; medium-high severity)
  • Double Free (-fsanitize=address as a runtime error; ZC, CE, PE, DoS, DT, ID; high-critical severity)
  • Null Pointer Dereference (-Wnull-dereference; ZC, DoS; low-medium severity)
  • Out of Bounds Access/Read/Write (-Warray-bounds; ZC, CE, PE, DoS, DT, ID; high-critical severity)
  • Stack Overflow (-Wstringop-overflow, -fstack-protect or -fstack-protector-strong as a runtime error; ZC, CE, PE, DoS, DT, ID; high-critical severity)
  • String format vulnerabilities (-Wformat-security; CE, PE, DoS, DT, ID; high-critical serverity)
  • Uninitalized memory/variables (-Wuninitialized, -Wmaybe-uninitialized; CE, PE, DT, ID; medium-high severity)
  • Use After Free (-Wuse-after-free or -fsanitize=address as a runtime error; ZC, CE, PE, DoS, DT, ID; high-critical severity)

• AI are observed to fix alone or help fix with human assistance/feedback the following:

  • Deadlocks (Runtime observation; ZC, DoS; low-medium severity)
  • Infinite loops/recursion (-Winfinite-recursion, -Wanalyzer-infinite-loop, -Wanalyzer-infinite-recursion, runtime error; ZC, DoS; low-medium severity)
  • LD_PRELOAD hijack vulnerability (It still requires human criticism; By code audit or experimentation; CE, PE, DT, ID; high-critical severity)
  • Path traversal vulnerability (By code audit; ZC, PE, ID, DT; medium-high severity)
  • Major version API updates [implying from insecure major version to secure major version]
  • Code migration from insecure library to secure library

• AI has not yet been observed but may be able to fix alone or help fix with human assistance/feedback the following:

  • Insecure password storage (By code audit or inspecting the password store; PE, ID, DT; medium-high severity)
  • Integer Overflow (-Wstrict-overflow or runtime detection with -fsanitize=undefined; ZC, CE, PE, DoS, DT, ID, medium-high severity)
  • Race Condition (Runtime error; ZC, CE, PE, DoS, DT, ID; medium-high severity)

Sometimes the AI will automatically detect and fix it on its own. Other times, the AI has to be reminded or criticised that there is a vulnerability.

Contributing AI fixes:

• Locate the code. Show the code, function, or file to the AI and present the compiler warning or runtime error.
• You can submit a pull request.
• The submission must be a patch file or an ebuild version bump. For version bumps, the fixed commit must be in that tagged release. Simply bumping the version without a fix or still having the affected code that wasn't removed won't help.

This list is incomplete.

Not all PII is sensitive data in certain data security guides.

The following are considered sensitive data or PII:

• [1] CPA (US-CO), CTDPA (US-CT), CCPA/CPRA (US-CA), PIPL (CN), VCDPA (US-VA)
• [2] CPA (US-CO), CTDPA (US-CT), PIPL (CN), VCDPA (US-VA)
• [3] CCPA/CPRA (US-CA), CTDPA (US-CT), PIPL (CN), VCDPA (US-VA)
• [4] Children's Online Privacy Protection Act (COPPA, US), Data Protection Act 2018 (UK), CPA (US-CO), CTDPA (US-CT), GDPR-K (EU), Online Safety Amendment (Social Media Minimum Age) Act 2024 (AU), PIPL (CN), UK General Data Protection Regulation (UK GDPR), VCDPA (US-VA)
• [5] CTDPA (US-CT), VCDPA (US-VA)
• [6] CCPA/CPRA (US-CA), LGPD (BR)
• [7] CAN-SPAM (US), CCPA/CPRA (US-CA), COPPA (US), CPA (US-CO), HIPAA (US), PIPEDA (CA), VCDPA (US-VA)
• [8] CCPA/CPRA (US-CA)
• [9] CCPA/CPRA (US-CA), CPA (US-CO), ISO 27001, VCDPA (US-VA)
• [10] CCPA/CPRA (US-CA), CCPA/CPRA (US-CA), CryptoCurrency Security Standard (CCSS), ISO 27001 (Worldwide), LGPD (BR), PCI DSS (Worldwide), VCDPA (US-VA)
• [11] CryptoCurrency Security Standard (CCSS)
• [12] ePrivacy Directive (EU)
• [14] CCPA/CPRA (US-CA), ePrivacy Directive (EU), PECR (UK), Technical Security Standards (OWASP, Worldwide)
• [15] CCPA/CPRA (US-CA), CPA (US-CO), CTDPA (US-CT), HIPAA (US), PIPEDA (CA)
• [16] CCPA/CPRA (US-CA), LGPD (BR), PIPEDA/CPPA (CA)
• [17] CCPA/CPRA (US-CA), CPA (US-CO), CTDPA (US-CT), PIPEDA (CA), UCPA (US-UT), VCDPA (US-VA)
• [18] CCPA (US-CA), Drivers Privacy Protection Act (DPPA, US), Utah Code 41-6a-1701 to 41-6a-1709
• [19] CCPA/CPRA (US-CA), CCPA/CPRA (US-CA), Nevada SB 370 (US-NV), Washington My Health, My Data Act (MHMD, US-WA), over 18 states in the US
• [20] APPI (JP), Children's Online Privacy Protection Act (COPPA, US), California's Date of Birth Redaction Law (2021), California Age-Appropriate Design Code (CA AADC, US-CA), California Age Verification Law (AB 1043 - Effective 2027), FADP (CH), LGPD (BR), PIPEDA (CA), PIPL (CN)
• [21] PIPL (CN)

The law should be respected to prevent possible indefinite detainment of developer(s) or contributor(s) while traveling.

This is provided for ebuild developers to improve compiler hardened tagging, isolation, or license references in ebuilds.

These are not easily removed due to the fork nature of git.

It may be removed directly from this repo but not inactive forked ones that have non-responding users.

(WIP) Reports should be done over encrypted messaging. Coordinate over e-mail first.

DO NOT SEND AN ISSUE REQUEST.

See also https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

The current threat model is a 4 category threat model. This threat model is unique to this overlay, default on, and automatic opt-in. Users can opt-out by setting CFLAGS_HARDENED_DISABLED=1 and RUSTFLAGS_HARDENED_DISABLED=1 in /etc/portage/make.conf. Users or organizations can also disable and design their own threat model and apply their own hardening.

• [1] Sandboxing with minimal chroot image and seccomp is strongly recommended. Sandboxing is assumed the model.
• [2] When an ebuild has multiple hardening listed, it means it is additive but security-critical means to apply all of them based on the tolerance level.
• [3] Users can control the tolerance level per package or the systemwide default. The systemwide default can be changed by adding and controlling the CFLAGS_HARDENED_TOLERANCE or RUSTFLAGS_HARDENED_TOLERANCE in /etc/portage/make.conf. The per-package override can be controlled by CFLAGS_HARDENED_TOLERANCE_USER or RUSTFLAGS_HARDENED_TOLERANCE_USER and adding the line to /etc/portage/package.env.
• [4] In a realtime-safe configuration, it is recommended to use CFLAGS_HARDENED_TOLERANCE="1.05" or less as the system default and remove the crashy hardening flags to maximize availability, and also to disable exceptions and disable the compiler default ON hardening which may compromise userland to the worst case performance expectations above the 5%.
• [5] Consider using a Docker container to reduce the blast radius or the extent of the compromise. The distro does provide Docker images but these are considered balanced security and not security-critical quality.

# Example of per-package hardening
# Contents of /etc/portage/env/nano.conf
# Setting to 15.00, one could enable -ftrapv which is a poor man's UBSan.
# Setting to 15.00 means that task completion will take about 15 times longer in the worst case.
RUSTFLAGS_HARDENED_TOLERANCE_USER="15.00"
CFLAGS_HARDENED_TOLERANCE_USER="15.00"

# Contents of /etc/portage/package.env:
app-editors/nano nano.conf

Potential threats

• [1] The main threats are zero click attacks, ransomware, compromised firmware, code hijack (ROP) gives practically some or theoretically all attack vectors capabilities to attacker
• [2] The main threats are malicious untrusted data
• [3] The main threats are data thieves
• [4] High uptime (Availability = Y) versus max runtime performance (Availability = N) is a sysadmin choice.

Core threats

• [1] Partial mitigation -- CPU - Yes, GPU - No

• [2] Partial mitigation -- CPU - No, GPU - Yes

• [3] Default opt-out, best effort removal or disablement based on integration complexity

• [4] At the source code level

• [5] Recognized as an ID threat and should be removed or disabled if possible

• [6] SSP strong is 10% performance penalty worst case and default ON with the distro's default compiler.

• [7] Repoline is 10% performance penalty for typical use, but worst case estimated 35% in real world to maybe even 54% in synthetic benchmarks. The sysadmin can choose between Retpoline or CET (5% performance penalty), the latter having the more higher mitigation score while both are mutually exclusive mitigation techniques.

• [8] Operationally working required for @system set, web browser dependencies, lightweight high value assets. Optional for EOL software or heavy packages (+20 MLOC).

• [9] DoS mitigation is offloaded to sysadmin

• [10] Performance-critical and security-critical are mutually exclusive. An analogy, the military checkpoints are guarded and slow flowing and not free flowing unchecked. The memory corruption checks are not optimized out.

• [11] A comprehensive isolation solution should be provided as default ON to isolate the crown jewels and crown jewel keys from network facing packages. A presence of a Dockerfile may hint default ON necessity.

  • Isolation eras for mainstream: chroot (1979), DAC (1980-1990s), MAC (early 2000s), virtualization (2000s), syscall isolation (2005), app sandboxes (mid 2000s), containers (2010s)
  • Input isolation (aka X11 sandboxing or Wayland) - mitigation of keyboard snooping
  • File system isolation - Either balanced-security mitigation of sensitive file exfiltration by visibility or new virtual root filesystem with logical separation, or in other critical-security standards using both physical and logical separation.
  • DAC isolation (aka UNIX file permissions) - balanced-security mitigation against exfiltration, data tampering, privilege escalation, code execution for files and directories
  • MAC isolation (aka SELinux, AppArmor) - critical-security mitigation against sensitive data exfiltration, data tampering, privilege escalation, code execution for any type of system resource
  • Memory isolation - mitigation of sensitive memory exfiltration
  • Syscall isolation (aka seccomp) - mitigation of memory exfiltration, shell code execution, privilege escalation

• [12] Project maintainers or gatekeepers that prevent portability, security ignornant, possibly compromised, grifters of free software, ignoring community demands or narssistic, not following conventions, non LTS

• A - A grade

• B - B grade

• C - C grade

• D - D grade

• F - F grade

• P - Partially mitigated

• R - Recognized as a threat but not actively mitigating

• ZC - Zero Click vulnerability

• CE - Code Execution and Shell Command Injection (SCI)

• PE - Privilege Escalation

• DoS - Denial of Service

• DT - Data Tampering

• ID - Information Disclosure

• SE - Social Engineering

• UB - Undefined Behavior (e.g. Integer Overflow)

• MC - Memory Corruption

• AP - Attack Primitives (ROP Gadgets) and weaponization

• PT - Path Traversal

• HV - Hardware Vulnerabilities

• FV - Firmware Vulnerability

• IDEF - Incorrect Defaults

• IPERMS - Incorrect File Permissions or Incorrect File Ownership

• UMSI - Unfinished or Missing Security Implementation

• LCI - License and Copyright Issues

• RP - Default Runtime Performance grade

• DI - Developer Integrity (Supply Chain Attack)

• BCF - Bad Compiler Flags

• BTF/RF - Build Time Failure and Runtime Failure

• BI - Build Issues (e.g. hard/soft lockups, worst case trashing, excessive build or link times)

• SM - Software Mortality (Planned Obsolescence) that coerces non-free adoption

• T - Telemetry (Data Collection)

• DPH - Debug Phone Home

• ISBX - Improper Sanboxing

• IOOSP - Inappropriate Over-Optimization on the Security-critical Perimeter

• MI - Missing Isolation

• PLPM - Problematic Lead Project Maintainer

• MV - Multiple Vulnerabilities

• STRIDE covers CE, PE, DoS, DT, ID, PT.

• NVD/CVSS covers ZC, CE, PE, DoS, DT, ID, SE, UB, PT, HV, SCI, MC, MV.

• GLSA covers CE, PE, DoS, SCI, MC, MV.