mirror of
https://github.com/PX4/PX4-Autopilot.git
synced 2026-09-24 19:08:21 +08:00
f5586139e4
* docs(mavlink): present link encryption alongside message signing The hardening guide told integrators that production deployments must enable message signing, presenting it as the only way to secure a MAVLink link. Encrypting the link below MAVLink, with an encrypted radio, a VPN or IPsec, is at least as strong: it uses standard, reviewed cryptography, it gives confidentiality as well as authentication, and it covers every interface on the link rather than only MAVLink. Present both options, and reword the passages that assumed signing was the only one. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> * docs(security): develop security fixes in public pull requests Record that fixes are developed as ordinary public pull requests, with no private forks and no embargoed branches. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> * docs(security): add security scope document Describe the boundary the code implements today: what PX4 protects, what it assumes about the layers beneath it, what the shipped default does and does not do, and two lists for what is always in scope and what is out. It describes the boundary rather than pre-deciding reports. A finding that fits neither list stays a judgement call that maintainers make on the report. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> * docs(security): list a security maintainer for report triage Security report triage had no named owner, so an unacknowledged report had nowhere to go except the release managers. Add a Security block to the maintainers list, and point the follow-up path in SECURITY.md at it. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> * docs(mavlink): note that the first signing key is unauthenticated The guide already says to provision over a trusted link, and the info box says that changing or disabling a key requires a signed message. It does not say that setting the first one cannot, since there is no key to sign with yet, so a reader can come away believing provisioning itself is protected. Say plainly that the window exists, what an attacker gets from it, and how to recover. Assisted-by: Claude:claude-opus-5[1m] Signed-off-by: Julian Oes <julian@oes.ch> * Apply batched suggestions from code review Co-authored-by: Sheren N <sherenyn@ad.uni-paderborn.de> Co-authored-by: Hamish Willee <hamishwillee@gmail.com> Co-authored-by: Julian Oes <julian@oes.ch> * feat(security): more review fixup * fix(security): only 1.18 gets security bugfixes * fix(security): link to SECURITY_SCOPE * fix(securiy): small wording fixups * docs(security): scope by attacker position, not bug class The "Always in scope" list made any memory corruption, race or hang a vulnerability regardless of who can reach it. That is not how reports have been handled: sanitizer runs in SITL have found and fixed many such bugs as ordinary PRs, and a peer on an unsecured link already has a shell. Replace it with one test: a finding is a vulnerability when it gives capability to an attacker who has neither the operator's access nor physical access. Keep the in-tree board configuration rule, point to the sanitizer docs, and fix two typos. Assisted-by: Claude:claude-opus-5[1m] Signed-off-by: Julian Oes <julian@oes.ch> * fix(docs): formatting * fix(maintainers): add Ramon to security as well * docs(security): draw the boundary as a mermaid diagram GitHub renders mermaid natively, so the boundary diagram no longer has to be maintained as hand-aligned ASCII. Label the two zones with the wording of the sentences below it, so the picture and the prose say the same thing. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> * fix(docs): review fixups * docs(security): say how to isolate the offboard transports A direct cable between flight controller and companion is not enough on its own: the agent or router republishes into the DDS or Zenoh network on the companion, so that network is inside the boundary too. Keep the scope document to what is inside the boundary and put the isolation advice next to the uXRCE-DDS and Zenoh setup instructions. Assisted-by: Claude:claude-opus-5 Signed-off-by: Julian Oes <julian@oes.ch> --------- Signed-off-by: Julian Oes <julian@oes.ch> Co-authored-by: Sheren N <sherenyn@ad.uni-paderborn.de> Co-authored-by: Hamish Willee <hamishwillee@gmail.com>
1.6 KiB
1.6 KiB
Security
Securing PX4 for a production vehicle is the integrator's responsibility.
::: tip PX4 is open by default: every PX4 control interface is unauthenticated, unsigned and unencrypted, and any peer that can reach a link can command the vehicle. This is intended! :::
This section provides links to security documentation for integrators and security researchers.
Integrators
- MAVLink Security Hardening — what an unauthenticated link exposes, and the checklist for a production deployment.
- MAVLink Message Signing — authenticating MAVLink frames, and what signing does not cover.
- Bootloader Secure Boot — verifying firmware at boot, and replacing the committed test key.
- Log Encryption — encrypting flight logs at rest.
- Read-Only Parameters — locking down settings that end users should not change.
Securing the link itself sits below PX4. An encrypted radio, a VPN or IPsec uses standard cryptography and protects every interface at once, including the ones MAVLink signing does not cover.
Security Researchers
- Security Policy — supported versions, how to report a vulnerability, and the rules for AI-assisted findings.
- Security Scope — where PX4's security boundary sits, and what is in scope for a report.