Sentinel Linux keeps third-party software available because Debian's software ecosystem is one of its strengths. The policy model distinguishes Sentinel-managed components from user-installed applications, records conflicts where possible and avoids pretending that every external application is automatically private, sandboxed or telemetry-free.
The release baseline locks the coordinated Sentinel package cohort, trusted repository configuration, release identity and managed desktop and security layers. Debian base updates remain allowed. Third-party applications are treated as user-installed software unless they replace, remove or conflict with a managed Sentinel component.
The current drift system reports Sentinel package and repository drift. It does not automatically delete unrelated applications, run APT autoremove, clean home folders or erase application data.
“Installed on Sentinel Linux” does not automatically mean “running in a container.” The isolation level depends on the delivery method.
A normal
.deb
application runs as a native Linux process under the user's account unless its own service requires additional privileges. It can normally access files the user can access and can make network connections.
Sentinel status: package-managed, but not automatically containerised.
Formats such as Flatpak can use an application sandbox and permission portals. The actual permissions depend on the application's manifest and any user overrides.
Sentinel status: isolated by that runtime when the user installs and uses it; not forced by the base conversion.
Applications deliberately launched in a container or virtual machine receive the isolation provided by that environment. File, device and network access depend on the container configuration.
Sentinel status: explicit isolation selected by the user or a future policy profile.
A manually downloaded executable usually runs natively with the current user's permissions. It may not have Debian package ownership, automatic security updates or a reliable removal record.
Sentinel status: highest need for source verification and deliberate isolation.
A sandbox can reduce access to files, devices or the network, but the protection depends on its configuration, kernel support, runtime quality and granted permissions. Sentinel Linux should show whether an application is native, sandboxed or isolated rather than using “secure” as an unexplained label.
Sentinel Linux applications are intended to be local-first and should not require telemetry or a cloud account for ordinary use. Their network features should be documented and user-authorised.
Third-party applications retain their own code and privacy practices. Sentinel Linux does not currently strip telemetry code from them, falsify their servers, or block every outbound connection by default. Doing so generically could break updates, authentication, licence checks, multiplayer services, synchronisation and ordinary web access.
Locale settings such as language, date format and region are stored locally, but a native application running as the user may be able to read relevant environment and desktop settings. Timezone can also reveal a broad region.
Internet services can estimate location from the public IP address even when precise device location is denied. Precise geolocation may additionally come from browser permission, Wi-Fi data, GPS hardware or an external service. Sentinel Linux cannot hide the public IP address without a user-selected network privacy service.
Prefer Debian or a recognised signed publisher repository. Verify checksums for manual downloads.
Look for analytics, crash reporting, account requirements, cloud synchronisation and advertising identifiers.
Use a sandbox, container or virtual machine when the application does not need broad access to the home folder or devices.
Do not give administrator rights, full home-folder access, microphone, camera, location or network access unless the feature genuinely needs it.
Watch for unexpected account prompts, background services, autostart entries and network activity.
Unsupported software becomes a security risk even when it was trustworthy when first installed.
No. Current drift control verifies the Sentinel cohort and trusted release state. Automatic remediation is disabled, APT autoremove is disabled, and user application data is outside cleanup scope.
No. Signing helps prove package origin and integrity. It does not describe telemetry, cloud use, data collection or runtime permissions.
Not in the current v1.0 baseline. That would require a tested per-application egress and permission system. Until then, users should choose trusted software, use available sandbox controls and deny unnecessary permissions.
No general policy does so. Modifying an external binary can invalidate its signature, break updates and create maintenance or licensing problems. Isolation and network policy are cleaner controls than silently patching vendor code.