Description of problem: Openconnect can write a PID-file when started in background. In case this PID-file is set to an existing file by accident, like /etc/shadow, /dev/sda etc., then openconnect destroys this file without asking. This is in contrast to how openconnect from other distros behave. Version-Release number of selected component (if applicable): 9.11 How reproducible: Always Steps to Reproduce: 1. install openconnect binary rpm 2. set the required parameters 3. set '-b --pid-file=/dev/sda' as part of the parameter list Additional info: I wrote some lines of additional code to first check if the given pid-file already exists. If so, the programm will not damage any file, but instead it will exit with error. You may have a look at the patch I created and inserted into the source rpm package which can be downloaded here: https://www.dipl-ing-kessler.de/developer/test/linux-src/mageia9/openconnect/
Thank you for your observation, and proposed patch. The error seems to be that the user can define: > set '-b --pid-file=/dev/sda' as part of the parameter list any filename he likes! Which is not checked by Openconnect when it creates its own PID file. > This is in contrast to how openconnect from other distros behave What do they do? Does your patch do the same? If so, should it not be in the upstream source? This would be for guillomovitch if he is still available; CC'ing him in hope, but assigning to DavidG who did the last Openconnect update.
Assignee: bugsquad => geiger.david68210CC: (none) => guillomovitch
Hi Markus, Could you report this issue also upstream at https://gitlab.com/openconnect/openconnect/-/issues, please? to see what they think about your proposed fix Thanks in advance!
Hi David, done: https://gitlab.com/openconnect/openconnect/-/issues/670 Thanks!
URL: (none) => https://gitlab.com/openconnect/openconnect/-/issues/670
Warning: Report this to upstream will result in getting encouraged to sign up Gitlab and create a merge request. I did so. And I regret. You then get huge amount of work (do this, change that) and finally there is a multiple-days dispute discussion where you even have to defend your ideas. In reality, they do not even think of including your patch. Instead, they admit, that the mentioned security leak is not the only backdoor. E.g., an attakcer can still get your machine under control by abusing the script option of a sudoed openconnect. So, all this is pointless. I will switch to openconnect invoked via wrapper program and can honestly recommend this
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Just seen, that, regarding running VPN software via Network-Manager -- at least these packages are missing in the official MGAx repos: networkmanager-openconnect-gnome networkmanager-openvpn-gnome networkmanager-vpnc-gnome Essentially, as a form to submit the connection details. Besides this, available / installable in every other distro and hence ready to copy from there
Resolution: FIXED => (none)Status: RESOLVED => REOPENED
(In reply to Markus Robert Keßler from comment #5) > Just seen, that, regarding running VPN software via Network-Manager -- at > least these packages are missing in the official MGAx repos: > > networkmanager-openconnect-gnome > networkmanager-openvpn-gnome > networkmanager-vpnc-gnome > > Essentially, as a form to submit the connection details. Besides this, > available / installable in every other distro and hence ready to copy from > there Nop false we have but not with same name as others distro: networkmanager-openconnect-gnome = networkmanager-openconnect networkmanager-openvpn-gnome= networkmanager-openvpn networkmanager-vpnc-gnome = networkmanager-vpnc
Closing as Invalid!
Status: REOPENED => RESOLVEDResolution: (none) => INVALID