Request manual review for KyalVPN (kyalvpn) – system-files and D-Bus declarations

nnl-kyal · August 24, 2026, 2:05pm

I am the publisher of the registered snap kyalvpn. The first upload of revision 1.0.1+2 requires manual review with:

human review required due to 'allow-installation' constraint (bool)
human review required due to 'deny-connection' constraint (interface attributes) (two occurrences)

KyalVPN is a strict-confined desktop VPN client for Linux. It consists of a Flutter GUI and a privileged daemon within the same snap.

system-files request

The daemon needs read-only access to:

/sys/devices/virtual/net/kyaltun0/statistics

This is used only to read the kernel rx_bytes and tx_bytes counters for KyalVPN’s fixed TUN interface kyaltun0, so the GUI can display VPN upload/download traffic metrics.

The declaration is:

kyalvpn-tun-stats:
  interface: system-files
  read:
    - /sys/devices/virtual/net/kyaltun0/statistics

No write access is requested. The plug has a descriptive name and is attached only to the VPN daemon.

I am requesting allow-installation for this system-files plug. Manual connection is acceptable; I am not requesting auto-connect for it at this time.

D-Bus declarations

KyalVPN uses these well-known D-Bus names:

session bus: com.kyal.vpnapp
system bus: com.kyal.vpnapp.Daemon

com.kyal.vpnapp is used by the Flutter/GTK application for desktop single-instance behavior.

com.kyal.vpnapp.Daemon is the IPC service between the unprivileged GUI and KyalVPN’s daemon under strict confinement. The GUI and daemon are both applications in the same snap. The daemon authorizes GUI requests using the caller’s D-Bus-resolved Unix UID.

I am requesting approval for these D-Bus declarations so the snap can be distributed through the Snap Store.

Snap name: kyalvpn

Thank you.

store-requests-bot · August 24, 2026, 3:05pm

This request has been added to the queue for review by the @reviewers team.

elisehdy · August 26, 2026, 11:17pm

Hello @nnl-kyal,

This is a +1 for the requested well-known D-Bus names from me.

As for system-files, if I am not mistaken, read access to /sys/devices/**/net/** should be accessible through the use of the network-observe, which is a preferable, less-privileged interface in comparison to system-files. It allows for manual connection by default. If the network-observe interface does not work for your use case, please describe the issues you encounter here in detail and we will consider system-files further. Thank you!

nnl-kyal · August 27, 2026, 2:31am

Thank you for the +1 on the requested D-Bus names.

Regarding system-files: I tested network-observe first, but unfortunately it does not provide the access needed for this use case.

KyalVPN reads the kernel traffic counters for its fixed TUN interface kyaltun0:

/sys/devices/virtual/net/kyaltun0/statistics/rx_bytes

/sys/devices/virtual/net/kyaltun0/statistics/tx_bytes

With network-observe connected, the daemon could use the normal network-observation/netlink functionality, but AppArmor still denied direct reads of these sysfs statistics files. The /sys/class/net/kyaltun0/... symlink resolves to /sys/devices/virtual/net/kyaltun0/..., and the denial occurred on that resolved path.

In live testing, GetMetrics returned no traffic byte counters while relying on network-observe alone. After connecting the following narrowly-scoped system-files plug:

kyalvpn-tun-stats:
  interface: system-files
  read:
    - /sys/devices/virtual/net/kyaltun0/statistics

the daemon could read the numeric rx_bytes and tx_bytes values, and GetMetrics returned the expected non-null upload/download counters.

This access is read-only, limited to the statistics directory of KyalVPN’s own fixed TUN interface, and is used only to display VPN traffic metrics in the GUI. No write access to sysfs is requested.

I am happy for this plug to remain manually connected; I am only requesting allow-installation for the snap so that it can be distributed through the Store.

Please let me know if any additional AppArmor denial logs or test details would be useful. Thank you.

elisehdy · September 2, 2026, 9:32pm

Hello @nnl-kyal,

Thank you for the detailed response, to be transparent we generally do not grant system-files access for directories such as /sys, as by design we aim to provide this access through other available interfaces. It is interesting to me that network-observe does not work here and worth investigation into why. Can you please provide the AppArmor denial logs without either network-observe or system-files connected, as well as the denial logs with network-observe connected?

Thank you!

nnl-kyal · September 5, 2026, 10:21am

Thanks. I ran the requested A/B test with the system-files plug disconnected in both cases.

Case A — network-observe disconnected

AppArmor denied access to the TUN statistics path:

Sep 05 20:14:53 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/sys/devices/virtual/net/kyaltun0/statistics/tx_bytes" ... requested_mask="r" denied_mask="r"
Sep 05 20:14:53 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/sys/devices/virtual/net/kyaltun0/statistics/tx_bytes" ... requested_mask="r" denied_mask="r"
Sep 05 20:15:04 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/sys/devices/virtual/net/kyaltun0/statistics/tx_bytes" ... requested_mask="r" denied_mask="r"
Sep 05 20:15:04 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/sys/devices/virtual/net/kyaltun0/statistics/tx_bytes" ... requested_mask="r" denied_mask="r"

I also saw /proc/<pid>/comm denials in this case.

Case B — network-observe connected

I repeated the same VPN flow while keeping system-files disconnected. The /sys/devices/virtual/net/kyaltun0/statistics/tx_bytes denials disappeared completely.

The only remaining AppArmor denials were for /proc/<pid>/comm, for example:

Sep 05 20:16:27 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/proc/1090/comm" ... requested_mask="r" denied_mask="r"
Sep 05 20:16:27 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/proc/1093/comm" ... requested_mask="r" denied_mask="r"
Sep 05 20:16:27 ... apparmor="DENIED" operation="open" class="file" profile="snap.kyalvpn.kyal-vpnd" name="/proc/1641/comm" ... requested_mask="r" denied_mask="r"

With network-observe and network-control connected, and system-files still disconnected, the VPN connects successfully. The TUN interface is created and policy routing is installed.

This appears to confirm that network-observe provides the /sys/.../statistics/tx_bytes access required by the VPN runtime, so the system-files plug is not required for that path.

If useful, I can also provide the complete unfiltered kernel logs from both test cases.

elisehdy · September 8, 2026, 11:51pm

Great to hear! Thank you for investigating further.

Would you like to convert this into an auto-connection request for the needed network interfaces?

nnl-kyal · September 9, 2026, 12:30am

Yes, please. I would like to convert this into an auto-connection request for the network interfaces required by KyalVPN: network-control network-observe I confirmed through testing that network-observe provides the required access to the TUN statistics path, so the previously requested system-files plug is no longer necessary. KyalVPN connects and routes traffic successfully with these network interfaces connected. Please let me know if you need any additional test results or changes to the snap declaration.