Description of problem: I am upgraded from F37 to Fedora 38 Beta and my wireguard VPN client blocked by selinux. Version-Release number of selected component (if applicable): wireguard-tools-1.0.20210914-4.fc38.x86_64 selinux-policy-38.8-2.fc38.noarch selinux-policy-targeted-38.8-2.fc38.noarch How reproducible: Always. Steps to Reproduce: 1. sudo systemctl start wg-quick Actual results: мар 10 06:26:50 milkyway.localdomain systemd[1]: Starting wg-quick - WireGuard via wg-quick(8) for wg0... мар 10 06:26:50 milkyway.localdomain wg-quick[5151]: [#] ip link add wg0 type wireguard мар 10 06:26:50 milkyway.localdomain wg-quick[5151]: [#] wg setconf wg0 /dev/fd/63 мар 10 06:26:50 milkyway.localdomain wg-quick[5151]: [#] ip -4 address add 10.9.0.2/24 dev wg0 мар 10 06:26:50 milkyway.localdomain wg-quick[5151]: [#] ip link set mtu 1420 up dev wg0 мар 10 06:26:50 milkyway.localdomain wg-quick[5173]: [#] resolvconf -a wg0 -m 0 -x мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] wg set wg0 fwmark 51820 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip -4 rule add not fwmark 51820 table 51820 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip -4 rule add table main suppress_prefixlength 0 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 мар 10 06:26:51 milkyway.localdomain wg-quick[5192]: sysctl: permission denied on key "net.ipv4.conf.all.src_valid_mark" мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] resolvconf -d wg0 -f мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip -4 rule delete table 51820 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip -4 rule delete table main suppress_prefixlength 0 мар 10 06:26:51 milkyway.localdomain wg-quick[5151]: [#] ip link delete dev wg0 мар 10 06:26:51 milkyway.localdomain systemd[1]: wg-quick: Main process exited, code=exited, status=1/FAILURE мар 10 06:26:51 milkyway.localdomain systemd[1]: wg-quick: Failed with result 'exit-code'. мар 10 06:26:51 milkyway.localdomain systemd[1]: Failed to start wg-quick - WireGuard via wg-quick(8) for wg0. Expected results: Normal start of wireguard client service. Additional info: Att selinux log I see this: time->Fri Mar 10 06:25:48 2023 type=AVC msg=audit(1678418748.271:319): avc: denied { getattr } for pid=5058 comm="sysctl" path="/proc/sys/net/ipv4/conf/all/src_valid_mark" dev="proc" ino=137070 scontext=system_u:system_r:wireguard_t:s0 tcontext=system_u:object_r:sysctl_net_t:s0 tclass=file permissive=0 Creating local policy via grep and audit2allow not helped. Only after setenforce 0 I can run wireguard.
Please remove the dontaudit rules: # semodule -DB re-run your scenario, collect SELinux denials # ausearch -m avc -m user_avc -m selinux_err -i -ts today and paste them here. Thank you.
Created attachment 1949504 [details] Requested data.
I would like you to test a special policy module which should fix the issue: # setenforce 1 # cat testpolicy.cil ( allow iptables_t wireguard_t ( fifo_file ( open ))) ( allow wireguard_t debugfs_t ( dir ( search ))) ( allow wireguard_t wireguard_t ( capability ( sys_module ))) ( allow wireguard_t sysctl_net_t ( dir ( search ))) ( allow wireguard_t sysctl_net_t ( file ( getattr open write ))) # semodule -i testpolicy.cil # Re-run your scenario. Let us know if your scenario works. The following command adds the dontaudit rules back into SELinux policy: # semodule -B The following command removes the special policy module: # semodule -r testpolicy Thank you.
Thanks. This policy fixed the issue.
I had previously found this https://bugzilla.redhat.com/show_bug.cgi?id=2188799 but I think this bugzilla more closely matches what I'm seeing. I used audit2allow to generate the following policy that worked: module wireguard 1.0; require { type iptables_t; type wireguard_t; class fifo_file open; } #============= iptables_t ============== allow iptables_t wireguard_t:fifo_file open;
I believe all reported problems have been fixed in current Fedora releases. Feel free to reopen this bug a create a new one in case of an outstanding issue.