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.