At the moment there is no easy way to use an openvpn connection. Once configured using this guide it can’t be disabled with 1-click button. I can’t even write a python script to automate this since it envolves asking for a root password. What’s the right way to make a 1-click solution? How to bypass a root password request without a security compromise?
I like the way tor-control-panel is implemented. I think it can be easy modified to OpenVPN gui app.
The usual way I guess is running the whole script under sudo (for command line [CLI] applications) or under lxsudo (for graphical user interface [GUI] applications). Then whenever you need to run something as non-root, you’ll use
sudo --non-interactive -u user /path/to/command parameters
You can use environment variable SUDO_USER (bash $SUDO_USER) so you don’t have to hardcode user user.
See also folder /etc/sudoers.d (needs root rights to view) how to add sudo exceptions (passwordless sudo).
If it is going to be a Freedom Software script contribution, don’t worry much about sudo/root. These are details I can help sort out later.
Yes, it is. For the moment I have made a script (link) that has to be run under sudo, but it does all the dirty work.
Usage: put openvpn config files in ~/.openvpn/ (hardcoded to user) and run sudo bash vpn.sh enable
to set up everything. Then sudo bash vpn.sh run=/etc/openvpn/client/your_config.conf to start vpn.
It probably will not work under Qubes but it works under Non-Qubes. The only problem I see is /etc/environment and TOR_TRANSPROXY=1 since it requires session restart. And a little refactoring, as usual.
Can you transfer the thread to Development section?
I don’t know what one liner do you use, but there is currently no onliner configuration available in public.
exec is the last thing happening. Script will not continue from there.
Sometimes using /usr/sbin/openvpn, sometimes using openvpn. PATH should be safe thanks to sudo. Using just only cmd-name without /path/to should be safe.
50_user.conf - better 40_auto_vpn.conf or something? Then the file could say it is auto generated and the whole file could be easily disabled to deactivate it.
Sorry, I didn’t explain this at all. By package whonix-ws-vpn-config I meant: not making modifications with a script but shipping configuration files that do the same thing instead.
vpn.sh /usr/lib/whonix-vpn-config/vpn.sh file which has to be added to /etc/sudoers.d openvpn-gui.py /usr/lib/whonix-vpn-config/openvpn-gui.py or any other location. To be run under the user account. python3-pyqt5 is required. Openvpn files must be placed to ~/.openvpn/ and must have .ovpn extension, auth-user-pass must have .txt extension and placed in the same folder.
@Patrick Can you please make a package and add it to the repository?
I thought you were talking about openvpn itself. There are a couple of steps like the firewall and environment variable setting which you thankfully automated for us.
Too many packages already. Split Whonix back then into too much packages. (too much) separate packages didn’t reach the goal to make Whonix more easy to review. A few fewer packages would have been better.
Create config files by script isn’t well maintainable long term. The
Whonix approach has been to ship config files whenever possible. As
little script/autogenerted content as possible.
Some files might be unavoidable to be auto generated but most not.
Use Replaces: in debian/control when required (a file already
handles through config-package-dev). And use config-package-dev when
needed. (I can help with the package conflict thing.)
Wouldn’t be 1 click but “sudo apt install pkg-name”. Maybe be possible
to ship/cache the package by default so no prior “sudo apt update” and
apt download is required. Will think about this more if this gets more
specific.