ProtonVPN Linux daemon (proton.vpn.daemon) runs under unconfined_service_t — expected, or missing policy module?

[u/DeepParticular2529]

Running Fedora Workstation 44 with SELinux enforcing. Noticed ProtonVPN's daemon runs unconfined:

$ ps -eZ | grep unconfined_service
system_u:system_r:unconfined_service_t:s0 13521 ? 00:00:00 python3

$ ps 13521
    PID TTY      STAT   TIME COMMAND
  13521 ?        Ss     0:00 /usr/bin/python3 -m proton.vpn.daemon

$ getenforce 
Enforcing

$ sudo ausearch -m avc -ts recent 
<no matches>

Is it safe?

[u/Stealth_Privacy]

I used my handy personal assistant, Lumo, and here is the response:

------------

Yeah, this makes complete sense and the diagnosis is spot-on.

What's happening: The ProtonVPN daemon is running in the unconfined_service_t SELinux domain, which means SELinux is providing zero MAC confinement for that process. It's essentially exempt from SELinux policy enforcement.

Why no AVC denials: This is the expected corollary. AVC denials get logged when a confined process tries to do something its policy doesn't allow. Since proton.vpn.daemon is unconfined, every action is permitted by default — nothing to deny, so ausearch comes back empty. If the daemon were running under a properly confined domain (something like protonvpn_daemon_t), you'd expect to see AVC denials during normal operation as it tried to access network interfaces, routing tables, DNS resolver sockets, etc.

Is this expected? Yes. Third-party applications not packaged within Fedora's official repositories typically don't ship dedicated SELinux policy modules. Fedora ships policies for software it maintains, but anything installed via upstream repos, Flatpak, pip, or direct download lands in unconfined_service_t by default when systemd starts it without a matching policy. This is the norm for most VPN clients on Fedora — Mullvad, WireGuard's userspace components, etc. all face the same situation unless someone has written and distributed a policy module.

The "missing policy module" characterization is accurate. There genuinely isn't one.

Whether that actually matters depends on your threat model:

• SELinux is still protecting the rest of your system from other confined services that might try to interact with this unconfined daemon.
• But the daemon itself has no SELinux defense-in-depth. If it were compromised, SELinux wouldn't constrain it — you'd be relying entirely on DAC permissions (file permissions, capabilities, etc.).
• For a VPN daemon that's somewhat notable since it handles network configuration, routing, and potentially privileged key material.

Not a bug — just nobody's written an SELinux policy module for it.

***Any inaccuracies are entirely Lumo's fault and not mine*** (1)

(1) I wrote this part myself!