Security centre
Package-governed security for a local-first system.
Sentinel Linux treats security improvements as upgradeable package material: hardening, repairs, validation commands, safe defaults, reports and rollback helpers.
Security model
Security via upgradeable packages.
The core model is simple: security state should be versioned, inspectable, upgradeable, and recoverable through packages. Manual hardening can still exist, but official posture belongs in package-owned policy, scripts, reports, and validation commands.
Controlled changes
Security changes should have package names, versions, changelogs, manifests and clear ownership.
Auditability
Reports, checksums, validation outputs and advisory records should be published where practical.
Recovery
Rollback notes, safe defaults and repair tools should be part of the release discipline.
Risk classes
Security pages should cover the real failure modes.
Package scripts
Maintainer scripts must avoid destructive surprise behaviour.
Restore/import
Archive extraction and database restore paths require explicit validation.
Local data
Databases, backups, exports, sidecars and handoff files should use private permissions where practical.
Network behaviour
Network features should be explicit and documented.
Browser/wallet
High-trust workflows require clear user approval boundaries.
AEGIS actions
Tool actions should be bounded, local-first, and user-authorised.
Current application-control boundary:
the v1.0 converter audits firewall and AppArmor state but does not silently enable a universal firewall, create application profiles or containerise external software. Per-application isolation and outbound approval require a separately implemented and tested policy layer.
Advisories
Future disclosures belong in a public ledger.
Use the advisory page format whenever a security issue needs public disclosure.
SENTINEL-SA-YYYY-NNN
Affected package:
Fixed version:
Upgrade command:
Verification:
Practical guidance
Operational pages