Description of problem: Problem when I want to connect to an OpenVPN server using NetworkManager OpenVPN client. Version-Release number of selected component (if applicable): 2.3.14-1.fc24 How reproducible: Everytime, with docker images running with port mapping. Don't know how is it related but it seems not occurs when there isn't docker image running. Steps to Reproduce: 1.Configure OpenVPN client with certificate authentification using gateway on port 443 2. try to connect 3. Actual results: Here is the log details : http://paste.fedoraproject.org/531342/84914650/ We see an USER AVC : Jan 20 09:37:02 shamash.uruk.home audit[894]: USER_AVC pid=894 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call i exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' And here is result of "audit2allow -al" command: #============= openvpn_t ============== #!!!! This avc is allowed in the current policy allow openvpn_t system_dbusd_t:dbus send_msg; Expected results: Connection without problem. I had to reboot and without docker container running launch connection. Additional info: Make an selinux package with "cat audit.log | audit2allow -M my_policy" seems to workaround the problem. Also problem occurs with and without using NetworkManager
This seems to be related to --up/--down calls. This will make OpenVPN run a script or a binary executable when setting up or tearing down a VPN connection. Perhaps there are some SELinux context switching missing? OpenVPN does not do any SELinux stuff of itself. Building OpenVPN with --enable-selinux (not enabled in fedora pkgs master nor epel7), will add some code where OpenVPN can do some context switching during the init phase. Otherwise, this should probably be tackled by the SELinux policy.
I observe this problem when using https://github.com/jonathanio/update-systemd-resolved/ script as --up/--down script with the following entry in journal: Jan 29 16:32:52 demon audit[846]: USER_AVC pid=846 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.resolve1.Manager member=SetLinkDNS dest=org.freedesktop.resolve1 spid=30054 tpid=954 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:systemd_resolved_t:s0 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I'm updating openvpn.spec files now to build OpenVPN with --enable-selinux at build-time. However I am not sure yet if this can help circumvent this issue, just thought it would be good to make people aware of this planned change.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Problem still present as of now (in Fedora 29). I raised it again in bug 1662909.
The same problem on new-installed Fedora29 with all updates. SElinux blocks calls to dbus. [root@fedora client]# audit2allow -al #============= openvpn_t ============== allow openvpn_t systemd_resolved_t:dbus send_msg; [root@fedora client]# audit2allow -w -a type=USER_AVC msg=audit(1548285348.012:265): pid=813 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.resolve1.Manager member=SetLinkDNS dest=org.freedesktop.resolve1 spid=6914 tpid=944 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:systemd_resolved_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access Interesting thing: sealert -a /var/log/audit/audit.log doesn't detect at all the issue. In addition, starts in somehow strange: /usr/bin/sealert:32: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated. Instead, use this sequence: from dbus.mainloop.glib import DBusGMainLoop DBusGMainLoop(set_as_default=True) import dbus.glib 2% done I don't know how to fix it