Description of problem: Conecting to a VPN with opeconnect. Apparently at the moment of establishing the connection. SELinux is preventing openconnect from read, write access on the chr_file vhost-net. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that openconnect should be allowed read write access on the vhost-net chr_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'openconnect' --raw | audit2allow -M my-openconnect # semodule -X 300 -i my-openconnect.pp Additional Information: Source Context system_u:system_r:vpnc_t:s0 Target Context system_u:object_r:vhost_device_t:s0 Target Objects vhost-net [ chr_file ] Source openconnect Source Path openconnect Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.20-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.20-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 6.3.11-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Jul 2 13:17:31 UTC 2023 x86_64 Alert Count 1 First Seen 2023-07-09 16:46:17 CEST Last Seen 2023-07-09 16:46:17 CEST Local ID 311abdca-bdb3-4e5d-92d6-570c8be5cc42 Raw Audit Messages type=AVC msg=audit(1688913977.326:312): avc: denied { read write } for pid=11514 comm="openconnect" name="vhost-net" dev="devtmpfs" ino=580 scontext=system_u:system_r:vpnc_t:s0 tcontext=system_u:object_r:vhost_device_t:s0 tclass=chr_file permissive=0 Hash: openconnect,vpnc_t,vhost_device_t,chr_file,read,write Version-Release number of selected component: selinux-policy-targeted-38.20-1.fc38.noarch Additional info: reporter: libreport-2.17.11 reason: SELinux is preventing openconnect from read, write access on the chr_file vhost-net. kernel: 6.3.11-200.fc38.x86_64 type: libreport hashmarkername: setroubleshoot package: selinux-policy-targeted-38.20-1.fc38.noarch comment: Conecting to a VPN with opeconnect. Apparently at the moment of establishing the connection. component: selinux-policy component: selinux-policy
Created attachment 1974853 [details] File: os_info
Created attachment 1974854 [details] File: description
Enrique, Can you elaborate a bit on the scenario - why would openconnect need access to /dev/vhost-net?
(In reply to Zdenek Pytela from comment #3) > Enrique, > > Can you elaborate a bit on the scenario - why would openconnect need access > to /dev/vhost-net? I have no idea why openconnect tries to access vhost. This has appeared after upgrading to openconnect-9.12-1.fc38; earlier versions did not show any security alert. Connection is to a Juniper Network VPN, and works fine.
*** Bug 2222580 has been marked as a duplicate of this bug. ***
David, Can you help us with understanding the problem which was reported independently by 2 users?
For info: This (actually bug 2222580) happened to me when authenticating for a VPN that uses Microsoft services to call my phone for a 2FA.
*** Bug 2223968 has been marked as a duplicate of this bug. ***
I can also confirm this issue. It does not seem to have an impact on functionality though. The VPN works fine.
OpenConnect uses vhost-net for acceleration, because it's basically just io_uring for the tun device; has nothing fundamentally to do with *virtualization*. https://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/c6ef119693
*** Bug 2227315 has been marked as a duplicate of this bug. ***
*** Bug 2228342 has been marked as a duplicate of this bug. ***
FEDORA-2023-a79a6bdd37 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a79a6bdd37
FEDORA-2023-a79a6bdd37 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a79a6bdd37` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a79a6bdd37 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2229870 has been marked as a duplicate of this bug. ***
FEDORA-2023-a79a6bdd37 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
I have installed selinux-policy-38.24-1.fc38 from the stable repositories but I still get an alert Aug 18 07:17:43 xxxx setroubleshoot[3526]: SELinux is preventing openconnect from open access on the chr_file /dev/vhost-net. What am I missing?
(In reply to Enrique Meléndez from comment #17) > I have installed selinux-policy-38.24-1.fc38 from the stable repositories > but I still get an alert > > Aug 18 07:17:43 xxxx setroubleshoot[3526]: SELinux is preventing openconnect > from open access on the chr_file /dev/vhost-net. > > What am I missing? I'm facing the same situation. As noted in BZ#2228342, SELinux raises 3 AVCs during the connection : 18869:type=AVC msg=audit(1690957704.598:255609): avc: denied { read write } for pid=1285918 comm="openconnect" name="vhost-net" dev="devtmpfs" ino=592 scontext=system_u:system_r:vpnc_t:s0 tcontext=system_u:object_r:vhost_device_t:s0 tclass=chr_file permissive=1 18870:type=AVC msg=audit(1690957704.598:255610): avc: denied { open } for pid=1285918 comm="openconnect" path="/dev/vhost-net" dev="devtmpfs" ino=592 scontext=system_u:system_r:vpnc_t:s0 tcontext=system_u:object_r:vhost_device_t:s0 tclass=chr_file permissive=1 18871:type=AVC msg=audit(1690957704.598:255611): avc: denied { ioctl } for pid=1285918 comm="openconnect" path="/dev/vhost-net" dev="devtmpfs" ino=592 ioctlcmd=0xaf01 scontext=system_u:system_r:vpnc_t:s0 tcontext=system_u:object_r:vhost_device_t:s0 tclass=chr_file permissive=1 It seems only the first line has been addressed by the latest update.
I tried to reopen this by changing the status again to NEW. Not sue this is the correct way to do that. The issue is not solved, see my comment and the one from francois.poirotte
Generally it's better to create a new bz, comments after the bug is in the update process are easily missed. This time refer to bz#2234359.