Bug 2391164 - SELinux blocking OpenVPN from creating generic netlink socket
Summary: SELinux blocking OpenVPN from creating generic netlink socket
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 42
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-08-26 21:06 UTC by Ian Pilcher
Modified: 2025-09-01 00:50 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-42.7-1.fc42
Clone Of:
Environment:
Last Closed: 2025-09-01 00:50:44 UTC
Type: ---
Embargoed:
zpytela: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 2848 0 None open Allow openvpn create and use generic netlink socket 2025-08-27 08:17:35 UTC
Red Hat Issue Tracker FC-2057 0 None None None 2025-08-27 08:19:33 UTC

Description Ian Pilcher 2025-08-26 21:06:36 UTC
type=AVC msg=audit(1756218769.705:22736): avc:  denied  { create } for  pid=11149 comm="openvpn" scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=netlink_generic_socket permissive=0

I haven't yet noticed any loss of functionality.

Reproducible: Always

Steps to Reproduce:
1. (Re-)start openvpn-client service
2. ausearch -c openvpn

Actual Results:
type=AVC msg=audit(1756218769.705:22736): avc:  denied  { create } for  pid=11149 comm="openvpn" scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=netlink_generic_socket permissive=0

Expected Results:
No denial logged.

Additional Information:
OpenVPN configuration:

client
dev rht0
dev-type tun
tun-mtu 1360

#proto tcp-client
proto udp
topology subnet

remote ovpn-rdu2.redhat.com 443
nobind
persist-key
persist-tun
user openvpn
group openvpn


cd /etc/openvpn
ca /etc/openvpn/client/RH-IT-Root-CA.crt
cipher AES-256-CBC
reneg-sec 0
#tls-remote ovpn-rdu2.redhat.com
verify-x509-name ovpn.redhat.com name

auth-user-pass
auth-nocache

ping 30
ping-exit 120

# Enable 'verb 4' for basic debug
# Enable 'verb 5' for debug + packet traversal notification
#verb 4
#verb 5

#up /etc/openvpn/client.up 

# i386
#plugin /usr/lib/openvpn/plugin/lib/openvpn-down-root.so /etc/openvpn/client.down

# x86_64
#plugin /usr/lib64/openvpn/plugins/openvpn-plugin-down-root.so /etc/openvpn/client.down

#script-security 2
#up "/usr/sbin/sysctl -p /etc/openvpn/client/rht0-sysctl.conf"

Comment 1 Ian Pilcher 2025-08-27 14:26:06 UTC
FYI, I think that I figured out what OpenVPN is doing here.  Here is the relevant portion of an strace when I run OpenVPN from the console.

socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_GENERIC) = 3
setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
getpid()                                = 18029
bind(3, {sa_family=AF_NETLINK, nl_pid=-218085779, nl_groups=00000000}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, nl_pid=-218085779, nl_groups=00000000}, [12]) = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0

sendmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{nlmsg_len=36, nlmsg_type=nlctrl, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2538663848, nlmsg_pid=-218085779}, {cmd=CTRL_CMD_GETFAMILY, version=1}, [{nla_len=16, nla_type=CTRL_ATTR_FAMILY_NAME}, "ovpn-dco-v2"]], iov_len=36}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 36

recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12,
msg_iov=[{iov_base=[{nlmsg_len=56, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0, nlmsg_seq=2538663848, nlmsg_pid=-218085779}, {error=-ENOENT, msg=[{nlmsg_len=36, nlmsg_type=nlctrl, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2538663848, nlmsg_pid=-218085779}, {cmd=CTRL_CMD_GETFAMILY, version=1}, [{nla_len=16, nla_type=CTRL_ATTR_FAMILY_NAME}, "ovpn-dco-v2"]]}], iov_len=16384}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_PEEK|MSG_TRUNC) = 56

recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{nlmsg_len=56, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0, nlmsg_seq=2538663848, nlmsg_pid=-218085779}, {error=-ENOENT, msg=[{nlmsg_len=36, nlmsg_type=nlctrl, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=2538663848, nlmsg_pid=-218085779}, {cmd=CTRL_CMD_GETFAMILY, version=1}, [{nla_len=16, nla_type=CTRL_ATTR_FAMILY_NAME}, "ovpn-dco-v2"]]}], iov_len=16384}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 56

close(3)

So it's trying to find a netlink family named "ovpn-dco-v2".  OpenVPN DCO appears to be a kernel-based accelerator for OpenVPN - https://openvpn.net/as-docs/openvpn-dco.html.

Comment 2 Ian Pilcher 2025-08-27 14:37:43 UTC
For now, the denial can be eliminated by adding the "disable-dco" option to the OpenVPN configuration.

Comment 3 Zdenek Pytela 2025-08-27 15:42:31 UTC
Excellent, thank you, information added to the commit message. You can now try the coprbuild from

https://github.com/fedora-selinux/selinux-policy/pull/2848
checks -> rawhide build

Comment 4 Fedora Update System 2025-08-29 12:09:26 UTC
FEDORA-2025-7a468a12c5 (selinux-policy-42.7-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-7a468a12c5

Comment 5 Fedora Update System 2025-08-30 02:01:29 UTC
FEDORA-2025-7a468a12c5 has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-7a468a12c5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-7a468a12c5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2025-09-01 00:50:44 UTC
FEDORA-2025-7a468a12c5 (selinux-policy-42.7-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.