Manual review request for 'ivpn' package and auto-connect interfaces

Hello, I have uploaded the’ ivpn’ package. A manual review is required.

The package was automatically blocked for manual review because of system-files interface with read/write access for two files:

plugs:
  ivpn-dns-control:
    interface: system-files
    write:
      - /etc/resolv.conf
      - /etc/resolv.conf.ivpnsave
    read:
      - /etc/resolv.conf
      - /etc/resolv.conf.ivpnsave

The software I want to publish is an open-source VPN client
Sources: https://github.com/ivpn/desktop-app
Website: https://www.ivpn.net/apps
Security audit report: https://www.ivpn.net/blog/ivpn-apps-security-audit-2022-concluded/

Interfaces explanation (needed for the daemon part of the package):

  • system-files - (for /etc/resolv.conf and /etc/resolv.conf.ivpnsave) we have to control global DNS configuration when VPN is connected (and we have to keep and restore original DNS settings when VPN disconnected )
  • network-control - ability to establish VPN connections and monitor network settings/chnages
  • firewall-control - IVPN client needs to control firewall rules (iptables) to avoid any potential IP leaks

The interfaces above are critical for our software to work properly.

I kindly ask you to approve the package and allow auto-connect for the interfaces: system-files, network-control, firewall-control.

Thanks in advance.

Since this application is clearly a VPN firewall-control and network-control both seem appropriate - +1 from me for auto-connect of both of these.

Regarding the access to /etc/resolve.conf - looking at this file on my own machine I see it states:

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(
8).
# Do not edit.

Which makes me quite wary regarding the requested access to write to this file - instead of directly editing this file could your application use resolvconf dns to set these parameters? This should already be provided via both the network-control and firewall-control interfaces.

1 Like

@alexmurray

The application do not change /run/systemd/resolve/stub-resolv.conf at all. It just makes a backup copy of /etc/resolve.conf (in your case, it is a link to /run/systemd/resolve/stub-resolv.conf) and replaces it on the configuration required for the current VPN connection.
After the VPN disconnects - the daemon restores the previous configuration.
Additionally, the OS is overwriting this file with the original data on every reboot. I don’t see here the danger to harm user configuration.

I have doubts that using resolvconf approach will work on every user’s machine:

The systemd-resolved functionality does not work when /etc/resolv.conf linked to something else than /run/systemd/resolve/stub-resolv.conf.
On my machine, for example, it points to /run/resolvconf/resolv.conf. So, any manipulations with resolvconf/systemd-resolve/resolvectl do not have an effect. It means, again, the application needs access to /etc/resolv.conf to configure it properly (to create a symlink to a correct file).

Anyway, I was tried the resolvconf with properly configured systemd-resolved on the host machine:

Unfortunately, usage of resolvconf does not take effect on the host system (e.g. echo 9.9.9.9 | resolvconf -a wlp3s0). And sometimes it returns an error: run-parts: /etc/resolvconf/update.d/libc exited with return code 1.
The way which have effect is to use systemd-resolve (e.g. systemd-resolve dns --interface=wlp3s0 --set-dns=1.1.1.1). But, unfortunately, it is not accessible from strict confinement (no permissions). Probably, I miss some snap interface.

I see, the similar problem already discussed:


Looks like the topic is still open.

The main question is:
Is there any universal solution to changing DNS settings on the host machine?
(the solution which works on any distro where snapd installed but without direct access of /etc/resolv.conf)

If not - can the ivpn package be approved to publish on Snap Store with the system-files interface (with r/w access for /etc/resolv.conf)?

As mentioned in that other thread, modifying /etc/resolv.conf is not a portable solution and so should not be done IMO - so -1 from me for write access via system-files for that.

However there are other VPN snaps in the snap store (e.g. https://snapcraft.io/easy-openvpn-server) which uses firewall-control and network-control so I suspect it is possible to snap a VPN - perhaps @galgalesh may be kind enough to offer some suggestions in your case.

easy-openvpn-server is a vpn server, not a client, so it doesn’t need to change DNS settings on the host machine. However, I do have some experience with vpn clients so I can offer some info on this.

@stenya

Is there any universal solution to changing DNS settings on the host machine?

The truth is that there is none. Even changing /etc/resolv.conf is not a universal solution, as it will not work on Fedora anymore, for example. See Understanding systemd-resolved, Split DNS, and VPN Configuration for more information on how modern DNS resolution works.

Importantly, when nss-resolve is used, glibc does not read /etc/resolv.conf when performing name resolution, so any configuration that you put there is totally ignored. That means any script or program that writes to /etc/resolv.conf is probably broken.

Apart from the fact that it won’t work, it’s also a user-hostile solution. It’s akin to throwing a brick through a window in order to get some fresh air. It completely bypasses the “regular” DNS infrastructure of the host machine and will make a lot of users and OS developers annoyed. It will cause a bunch of weird to debug issues.

  • For example, all GUI and CLI interfaces to change DNS settings will silently fail. To the user, it will seem as if they can still modify their DNS settings, but none of the modifications will actually change anything.
  • Another example: if the user is working with a local Kubernetes cluster, DNS integration with their desktop will stop working.
  • As a final example, some third party applications on fedora still use /etc/resolv.conf, so depending on the application, it will have different behavior.

As a user, I think @alexmurray made the right decision here. VPN clients should not be able to change /etc/resolv.conf. It doesn’t always achieve what you want and when it does, it creates a broken system.

What should you do then?

You should be able to use the tool resolvectl. This configures resolved, which is the DNS daemon on almost all Linux distributions. 99% of your userbase will be covered by this. Since snap requires systemd and resolved is part of it, this should work on 100% of distributions supporting snap.

For your (non-snap) app, you can still fallback to changing /etc/resolv.conf when resolved is not found on the system.

2 Likes

I continue playing with resolvconf. This approach does not work, because of resolvconf script needs /lib/resolvconf/list-records which is not accessible out from snap. Do I miss something?

The mentioned snap is a vpn server. It do nothing with DNS settings.
I did check some vpn-kind snaps in store - no one of them not changing DNS. But it is critically important for our package to avoid any DNS leaks from users machine.

I understand your concern about not giving direct access to the file “/etc/resolv.conf”. I am trying to find another workable solution. But, unfortunately, without luck.
I will appreciate any suggestions.

I think alex meant resolvectl instead of resolvconf.

@galgalesh Thank you!
This can work. I am going to play with it.

One more question: can you, please, suggest which interfaces are required to access resolvectl or systemd-resolve ?

/usr/bin/resolvectl: Permission denied
/usr/bin/systemd-resolve: Permission denied

It is not accessible with such interfaces:

network              
network-bind         
network-control      
network-manager      
network-observe      
network-setup-control

You need to include the binaries of resolvectl in your snap, and run those inside your snap. That binary will use the resolved socket, which is accessible using the network-* interface (I think network-control). Let us know if you run into any issues doing this.

(this also makes sure your snap is not affected when the host system has a broken installation of resolvectl, since you ship a working installation in your snap itself).

This is a general rule for snaps: ship the binaries, which communicate with the host system using sockets.

Once you get resolvectl working inside of the snap, you can check this documentation for how to use it for your vpn client software: https://github.com/systemd/systemd/blob/main/docs/RESOLVED-VPNS.md

Edit: you shouldn’t need systemd-resolve in your snap. resolvectl is the client app running inside your snap. systemd-resolve (resolved) is the server running on the user’s OS

1 Like

Indeed - thanks for all your help on this thread @galgalesh :pray:

@stenya - It looks like resolvctl is shipped in systemd - so you could add that via stage-packages in your snap yaml and then the resolvctl binary should be available in your snap - and then since it has network-control and firewall-control in its plugs then once these interfaces are connected the snap should then have the permission to execute and use resolvectl.

1 Like

@galgalesh @alexmurray Many thanks for your help! Your comments were really helpful. I have managed it with resolvectl.

So I successfully published: https://snapcraft.io/ivpn
But I still need auto-connect for interfaces: network-control and firewall-control.
Please, let me know if anything is required from my side for that.

Excellent - that is great news @stenya.

Can other @reviewers please vote too?

I agree, +1 for auto-connect for both firewall-control and network-control.

1 Like

+2 votes for, 0 votes against, granting auto-connect of firewall-control and network-control for ivpn. This is now live.

1 Like