mirror of
https://github.com/uutils/coreutils.git
synced 2026-06-10 15:48:22 -07:00
Sylvestre Ledru
103 lines
4.7 KiB
Markdown
103 lines
4.7 KiB
Markdown
# Security Policy
|
|
|
|
## Supported Versions
|
|
|
|
We provide security updates only for the latest released version of `uutils/coreutils`.
|
|
Older versions may not receive patches.
|
|
If you are using a version packaged by your Linux distribution, please check with your distribution maintainers for their update policy.
|
|
|
|
---
|
|
|
|
## Threat Model and Scope
|
|
|
|
`uutils/coreutils` is a set of **local** command-line utilities. There is no
|
|
network-facing service, so remote vulnerabilities do not apply. When assessing
|
|
whether a report is a security issue, we focus on whether it crosses a trust or
|
|
privilege boundary on the local system.
|
|
|
|
**In scope** (treated as security issues):
|
|
|
|
- **Privilege-boundary violations** - bypassing a documented safety guard
|
|
(e.g. `--preserve-root`), acting on files outside the intended scope, or
|
|
privilege escalation in setuid/sudo contexts.
|
|
- **Filesystem race conditions** - TOCTOU bugs, symlink following, and unsafe
|
|
directory traversal in utilities that recurse or operate on paths
|
|
(`cp`, `mv`, `rm`, `chown`, `chmod`, `install`, …). *TOCTOU*
|
|
(Time-Of-Check to Time-Of-Use) is when a utility checks a file's state
|
|
(existence, type, permissions) and then acts on it in a separate step, leaving
|
|
a window for an attacker to swap the path in between - e.g. replacing a regular
|
|
file with a symlink so the action lands on a different target. *Safe
|
|
traversal* is the defense: when walking a directory tree, descend with
|
|
symlink-aware primitives (`openat`/`O_NOFOLLOW`, file descriptors instead of
|
|
re-resolved paths) so a symlink swapped in mid-walk cannot redirect the
|
|
operation outside the intended tree.
|
|
- **Unintended destructive actions** - operations that delete, overwrite, or
|
|
signal something the user did not ask for, including security-relevant
|
|
divergences from GNU behavior that scripts rely on (a parsing bug that "fails
|
|
open" instead of erroring).
|
|
- Memory-safety issues, integer overflow, or unbounded allocation reachable
|
|
from untrusted input.
|
|
|
|
**Out of scope** (report as a normal bug, not a security issue):
|
|
|
|
- Crashes, panics, or incorrect output with no privilege or safety impact.
|
|
- Cosmetic differences from GNU (messages, exit-code-only mismatches) that do
|
|
not change which files or processes are affected.
|
|
- Issues requiring an already-privileged or already-malicious local actor who
|
|
could achieve the same effect directly.
|
|
|
|
### Local denial-of-service
|
|
|
|
Because these are local tools, resource exhaustion (hang, infinite loop,
|
|
unbounded memory/CPU, crash on crafted input) is only a security issue when the
|
|
triggering input **crosses a trust boundary**. A user who runs a utility on their
|
|
own data and exhausts their own resources is harming only their own invocation -
|
|
that is a normal bug. It is in scope when crafted, untrusted input reaches the
|
|
utility through a boundary the victim does not control, such as a privileged
|
|
script, a cron job, or an automated pipeline that processes attacker-influenced
|
|
filenames or file contents and is thereby wedged, blocked, or terminated.
|
|
|
|
Severity reflects impact, not just whether a bug exists: a guard bypass that can
|
|
hit the whole filesystem is critical, while a local availability issue bounded by
|
|
the caller's existing permissions is low.
|
|
|
|
---
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
**Do not open public GitHub issues for security vulnerabilities.**
|
|
This prevents accidental disclosure before a fix is available.
|
|
|
|
Please use one of the following methods:
|
|
|
|
- **GitHub (preferred):** open a private report at
|
|
<https://github.com/uutils/coreutils/security/advisories/new>
|
|
("Report a vulnerability").
|
|
- **Email:** [sylvestre@debian.org](mailto:Sylvestre@debian.org)
|
|
- **Encryption (optional):** You may encrypt your report using our PGP key:
|
|
Fingerprint: B60D B599 4D39 BEC4 D1A9 5CCF 7E65 28DA 752F 1BE1
|
|
---
|
|
|
|
### What to Include in Your Report
|
|
|
|
To help us investigate and resolve the issue quickly, please include as much detail as possible:
|
|
|
|
- **Type of issue:** e.g. privilege escalation, information disclosure.
|
|
- **Location in the source:** file path, commit hash, branch, or tag.
|
|
- **Steps to reproduce:** exact commands, test cases, or scripts.
|
|
- **Special configuration:** any flags, environment variables, or system setup required.
|
|
- **Affected systems:** OS/distribution and version(s) where the issue occurs.
|
|
- **Impact:** your assessment of the potential severity (DoS, RCE, data leak, etc.).
|
|
|
|
---
|
|
|
|
## Disclosure Policy
|
|
|
|
We follow a **Coordinated Vulnerability Disclosure (CVD)** process:
|
|
|
|
1. We will acknowledge receipt of your report within **10 days**.
|
|
2. We will investigate, reproduce, and assess the issue.
|
|
3. We will provide a timeline for developing and releasing a fix.
|
|
4. Once a fix is available, we will publish a GitHub Security Advisory.
|
|
5. You will be credited in the advisory unless you request anonymity.
|