Description of problem: SELinux is preventing /usr/sbin/openvpn from 'name_connect' accesses on the tcp_socket . ***** Plugin connect_ports (85.9 confidence) suggests ********************* If you want to allow /usr/sbin/openvpn to connect to network port 11942 Then you need to modify the port type. Do # semanage port -a -t PORT_TYPE -p tcp 11942 where PORT_TYPE is one of the following: dns_port_t, dnssec_port_t, http_cache_port_t, http_port_t, kerberos_port_t, ldap_port_t, ocsp_port_t, openvpn_port_t, squid_port_t, tor_port_t. ***** Plugin catchall_boolean (7.33 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. You can read 'None' man page for more details. Do setsebool -P nis_enabled 1 ***** Plugin catchall_boolean (7.33 confidence) suggests ****************** If you want to allow openvpn to can network connect Then you must tell SELinux about this by enabling the 'openvpn_can_network_connect' boolean. You can read 'None' man page for more details. Do setsebool -P openvpn_can_network_connect 1 ***** Plugin catchall (1.35 confidence) suggests ************************** If you believe that openvpn should be allowed name_connect access on the tcp_socket 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: # grep openvpn /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:openvpn_t:s0 Target Context system_u:object_r:unreserved_port_t:s0 Target Objects [ tcp_socket ] Source openvpn Source Path /usr/sbin/openvpn Port 11942 Host (removed) Source RPM Packages openvpn-2.3.2-4.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-149.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 3.13.8-200.fc20.x86_64 #1 SMP Tue Apr 1 03:35:46 UTC 2014 x86_64 x86_64 Alert Count 2 First Seen 2014-04-06 13:41:24 YEKT Last Seen 2014-04-06 13:59:43 YEKT Local ID ec5e6892-a1ce-4cfc-b1e4-d03366ebb89f Raw Audit Messages type=AVC msg=audit(1396771183.144:990): avc: denied { name_connect } for pid=24752 comm="openvpn" dest=11942 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1396771183.144:990): arch=x86_64 syscall=connect success=no exit=EINPROGRESS a0=5 a1=7fff009f70c8 a2=10 a3=4000 items=0 ppid=24750 pid=24752 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null) Hash: openvpn,openvpn_t,unreserved_port_t,tcp_socket,name_connect Additional info: reporter: libreport-2.2.1 hashmarkername: setroubleshoot kernel: 3.13.8-200.fc20.x86_64 type: libreport
Again the alert tells you what to do. Did it happen by default or did you setup this port?
I am really don't understand why usual user of desktop system needed configure SELinux for use VPN??? So we will achieve that users will either disable SELinux or move to other distributions (Debian, Ubuntu) :( I am really don't understand why I need grant network or file access for every application :(
Did you setup this port?
We are not able to know all configurations. This is a reason why we have booleans for example.
(In reply to Miroslav Grepl from comment #3) > Did you setup this port? Of course no. I am received ".ovpn" file for automatic VPN client configuration and I am expected that it would connect out of box. I am really don't want to know which port and ip address used for it.
I agree that protection is needed for server applications to configure them will always be administrators. But I disagree configure client applications because that is only discourages users from Fedora.
Hi, In this case we can only tell you what to do to fix your issue. Please, If you want to fix it, follow these steps: ***** Plugin catchall_boolean (7.33 confidence) suggests ****************** If you want to allow openvpn to can network connect Then you must tell SELinux about this by enabling the 'openvpn_can_network_connect' boolean. You can read 'None' man page for more details. Do setsebool -P openvpn_can_network_connect 1 Thank you.
I get it. Are you think is correct for each installed client application to configure booleans SELinux? Ok, why I don't do it either for browser, IM client and other applications which is needed some network connections?
I think this boolean "openvpn_can_network_connect" should be setted to 1 by default.
(In reply to Mikhail from comment #8) > I get it. Are you think is correct for each installed client application to > configure booleans SELinux? From security point of view, it's necessary. > > Ok, why I don't do it either for browser, IM client and other applications > which is needed some network connections? Because every service or applications needs different rights, e.g IM client has different network rights than openvpn.
I thought SELinux helps prevent real problems with secure, when blocks atypical behavior of programs. For example why the database server wants to connect to somewhere. Or why the Web server read the contents of home directories. But there is another case. I see no other purpose of openvpn how to create tunnels. Ie my outrage is based on the logic of why allow what should have permissions is the usual behavior. Extra blocking here only annoying and not create a sense of increased security.
I have no problem with turning this boolean on by default.
OK Dan, I'll change it.
commit 53d5f49e0411bf0d8158a3868828db5769e1798f Author: Lukas Vrabec <lvrabec> Date: Tue Apr 8 16:11:22 2014 +0200 openvpn_can_network_connect boolean set default on
Thanks Dan. Let's talk about the problem https://bugzilla.redhat.com/show_bug.cgi?id=1074830 constructively. I am agree that certificates must be stored in safe place. But with this block of SELinux protect certificates only from openvpn LOL. It's means any another process can access and steal certificates. Be right way if all certificates automatically moved to safe place and SELinux block any process to access to this place except trusted processes. Are you agree with me? I suggest fill separate bug report for NetworkManager developers that they when importing ".ovpn" file automatically transferred certificates in safe place (~/.cert folder). Can you do this? And while this is not done , I believe that SELinux should not block access to the home folder for openvpn. Cause it now more annoying than protects from real threats . Thank you for understanding .
By the way do not necessarily move files rather they just change the label of SELinux automatically It can do NetworkManager :)
(In reply to Mikhail from comment #16) > By the way do not necessarily move files rather they just change the label > of SELinux automatically > > It can do NetworkManager :) AFAIK there is a NM bug for this issue where we have been discussing it.
Miroslav, thanks. I need fill separate bug report or NM team know about it?
Let me find this bug.
selinux-policy-3.12.1-153.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2014-4933/selinux-policy-3.12.1-153.fc20
Package selinux-policy-3.12.1-153.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-153.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4933/selinux-policy-3.12.1-153.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-153.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.