Add SUID support

[jamesmcm]

Allow user to set SUID on vopono binary, and then don't prompt for sudo, etc.

Most existing code should already work, this is more of a packaging problem. May need minor changes for getting original user ID - see https://github.com/Intika-Linux-Namespace/Netns-Exec/blob/master/netns-exec.c

Also consider using capabilities: https://linux.die.net/man/7/capabilities - if any applicable, e.g. CAP_NET_ADMIN

[dani-corie]

I feel like this would be pretty important... sudo is a major risk because the sudo password timeout counts across child processes. So on most Linux systems, by invoking a browser through vopono, we're handing the browser unchecked sudo privileges for 15 minutes.

Demonstration of the issue:

dani@gorillo:~$ vopono exec --provider mullvad --server sweden "bash"
 2021-03-09T13:46:47.416Z INFO  vopono::util > Calling sudo for elevated privileges, current user will be used as default user
[sudo] password for dani: 
 2021-03-09T13:46:50.587Z INFO  vopono::util > Chosen config: /home/dani/.config/vopono/mv/wireguard/sweden-se2.conf
 2021-03-09T13:46:50.590Z INFO  vopono::netns > Created new network namespace: vopono_mv_sweden
 2021-03-09T13:46:50.630Z INFO  vopono::netns > IP address of namespace as seen from host: 10.200.1.2
 2021-03-09T13:46:50.630Z INFO  vopono::netns > IP address of host as seen from namespace: 10.200.1.1
 2021-03-09T13:46:50.932Z INFO  vopono::exec  > Application bash launched in network namespace vopono_mv_sweden with pid 51229
dani@gorillo:~$ ls /root
ls: cannot open directory '/root': Permission denied
dani@gorillo:~$ sudo ls /root
dani@gorillo:~$ sudo touch /root/a
dani@gorillo:~$ sudo rm /root/a
dani@gorillo:~$ 

It ain't looking good, doc. :( This issue is not really an "enhancement".

[jamesmcm]

I wonder if we can fix that specific issue by explicitly dropping privileges prior to launching the application, I really want to avoid extra forking and explicit system calls if I can though as it gets complicated to keep track of.

But maybe we could do it in the pre_exec method of the std::process::Command so it runs on the new fork but before spawning the actual process.

The SUID bit itself is really a packaging issue as I can't do it for cargo installs for example, but at least could do it on the AUR, and possibly the deb packages if it it's supported there too.

[dani-corie]

User-level cargo installs are broken anyway, as ~/.cargo/bin is dropped from path by sudo... I guess this should be its own issue, shouldn't it...? :D I think the prudent choice might be to just provide an error message that the vopono binary should be owned by root and have setuid bit.

After some experimentation, it seems that sudo can be made a lot safer by adding this to /etc/sudoers:
Defaults timestamp_type=ppid

[jamesmcm]

I think we run with the -E equivalent though, so as long as it's on the user's path it should work? But it's an edge case anyway really, I agree that the SUID option is better overall.

This actually simplifies the code too really, it's just a case of testing it and re-packaging the binaries (and updating the docs).

[dani-corie]

On Ubuntu 20.04 at least, with the default sudo settings it's broken unless you manually copy the binary to /usr/local/bin or some similar location. With the binary in ~/.cargo/bin, the process returns with sudo: vopono: command not found...

I guess for people installing from source, one can always put the chown/chmod stuff in the install.sh script, and debian packages can configure suid apps correctly.