Request for classic confinement for snap 'nodevpn'

Hi everyone,

I would like to request for classic confinement for snap ‘nodevpn’. NodeVPN is a flutter based GUI application which depends on openconnect C library (shipped in Ubuntu repository).

During the development in strict confinement (with network-setup-control, firewall-control and hardware-observe connected manually), it fails to setup tun with the following error output:

progress_vfn: Failed to bind local tun device (TUNSETIFF): Operation not permitted

progress_vfn: To configure local networking, openconnect must be running as root See https://www.infradead.org/openconnect/nonroot.html for more information

https://gitlab.com/openconnect/openconnect/-/blame/master/tun.c#L244

Thanks in advance , looking forward to it.

Kind Regards,

Arun

NodeVPN LTD

This is interesting given we have a bunch of other VPN clients in the store already and all can use strict confinement just fine.

If the tun module does not get automatically loaded when the device is accessed this sounds rather like a serious kernel bug, all modern kernels should normally auto-load it on request so that you do not need to be root or to even run modprobe …

I am using the Linux Kernel 6.2.12 , and also tested on the default kernel in jammy.

I tried debugging with snappy-debug; can’t find any interface that is missing.

Also, most of the VPN clients I found in snapcraft with ‘strict’ confinement do not seem to create tun, but proxies.

Let me know.

well, according to the kernel documentation it should work:

https://www.kernel.org/doc/Documentation/networking/tuntap.txt

(in: 2. Configuration/Driver module autoloading)

you might also need the network-control interface connected …

Yes, I have network-control interface connected too.

I also tried with the following interfaces connected (auto and manual), but same error when trying to bind the tun.

- firewall-control
- hardware-observe
- network-control
- network-manager
- network-observe
- network-setup-control
- network-setup-observe
- network-status
- network-bind

On further digging, I find that the ip route add command returns "RTNETLINK answers: Operation not permitted" .

Full executed command : ip route add X.X.X.X via X.X.X.X dev wlo1 src X.X.X.X

Is this a normal behavior with snap ? Any alternatives that works in snap?

The base is core22 .

this is not snap related, routes can not be changed by non-admin users, you need to be root for this or use some proxying mechanism (i.e. a frontend/backend and dbus communication between them like network-manager does)

I see. For now, the software does not have such a frontend/backend mechanism in place.

Right now, the software is a single binary depending on openconnect shared library. We’ll be planning to work on the proxying mechanism in future releases. Would be great if we could ship the snap in classic mode and later switch to strict mode when we are done.

Thank you for your help!

Well, you will have to wait for an actual reviewer to chime in, but i think the chances are low given all other software of the same functionality that exists in the store gets along with strict confinement … also, for classic your app needs to fit into the supported category on:

Hi @nodevpn Did you try the methods mentioned here: https://www.infradead.org/openconnect/nonroot.html which allows OpenConnect to run without admin privileges? especially the SOCKS proxy one which doesn’t require creating a virtual network interface.

Regarding the classic confinement, I know this VPN service may differ from other already strict confined vpn snaps, but it doesn’t fit into any available categories

Hi @0xnishit ,

The SOCK5 proxy method will require additional proxy configuration and setup in the application for the VPN connection. The motive of NodeVPN is to provide hassle-free system wide connection without much additional configuration for the user end. So, a tun is required for our use-case, hence request for classic confinement for now.

I see that there is no specific category mentioned but might go for an exception…?

Thanks for your response!

sadly the review team usually does not make any exceptions, the categories for classic are rather strict …

perhaps you could contact other vpn client devs to get some hints … here is one that uses the tun interface:

and here is a strictly confined openconnect client:

Hi @ogra, both of them are CLI based agent (need users to execute the snap with sudo) , our software is GUI (flutter), so can’t implement sudo/pkexec in snap through .desktop either.

Hi @nodevpn,

Since granting classic confinement allows device ownership to the snap, unfortunately we cannot just give exceptions.

I would say nodevpn end users would value the possibility of running the application in a stable and secure runtime environment rather than complaining for having to perform extra configuration steps.

Since it’s been almost one month since you created this request, how far are you from working on the proxying mechanism that iiuc will allow nodevpn to properly run under strict confinement?

Hey @nodevpn - ping, it’s been a while since the last activity on this post and just wanted to ask how far has the snap progressed to be run with a strict confinement? Thanks

hey @nodevpn, ping again

kindly let us know if you’re facing any issue, thanks

Hey @sahnaseredini @0xnishit ,

As of now, there is not much of a progress on the support of NodeVPN for non-classic confinement.

We’ll update the thread as we move forward to a working progress.

Thanks :slight_smile:

1 Like

Hey @nodevpn , since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks.