Created attachment 945430 [details] All generated policy files which done it working Description of problem: When I try start OpenVPN through 'systemctl status openvpn', OpenVPN should ask user for password, but SELinux prevent it. Version-Release number of selected component (if applicable): openvpn.x86_64 2.3.2-6.fc20 @updates I put it into operation by recomandation of SELinux trubleshoter, by running following commands until it works: 1. systemctl status openvpn 2. grep openvpn /var/log/audit/audit.log | audit2allow -M mypol 3. semodule -i mypol.pp Now it works and final agregated policy file should be following, but I am not sure if it is correct, so I attach all generated policy file in zip archive. require { type openvpn_t; type cgroup_t; type systemd_passwd_agent_t; type fmpro_internal_port_t; type systemd_passwd_var_run_t; class sock_file { create unlink }; class process signull; class file { rename setattr read create write getattr unlink open }; class udp_socket name_bind; class dir { write getattr remove_name search add_name }; } #============= openvpn_t ============== allow openvpn_t cgroup_t:dir { getattr search }; allow openvpn_t fmpro_internal_port_t:udp_socket name_bind; allow openvpn_t systemd_passwd_var_run_t:dir { write remove_name getattr search add_name }; allow openvpn_t systemd_passwd_var_run_t:file { rename setattr read create write getattr unlink open }; allow openvpn_t systemd_passwd_var_run_t:sock_file { create unlink }; #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t openvpn_t:process signull;
I forgot explicitely say: My problem was solved, but attached policy fix should be added into Fedora. Thanks
I'm adding Dan Walsh (our SELinux guru) to this. As there's a lot of OpenVPN SELinux rules already in the base selinux-policy package, this might be more suitable there. Another coincidence is that I four days ago did come up with something quite similar to the proposal in comment #0 and bug #1145978 ---------------------------------------------------------------- require { type openvpn_t; type systemd_passwd_var_run_t; type systemd_passwd_agent_t; class dir { search write add_name remove_name }; class file { create unlink read write open rename getattr setattr }; class sock_file { create unlink }; } #============= openvpn_t ============== allow openvpn_t systemd_passwd_var_run_t:dir { search write add_name remove_name }; allow openvpn_t systemd_passwd_var_run_t:file { create unlink read write open rename getattr setattr }; allow openvpn_t systemd_passwd_var_run_t:sock_file { create unlink }; #============= systemd_passwd_agent_t ============== allow systemd_passwd_agent_t openvpn_t:dir search; allow systemd_passwd_agent_t openvpn_t:file { read open getattr }; ---------------------------------------------------------------- You probably notice that I'm not having the cgroup_t here. That is because I submitted a patch upstream to OpenVPN which avoids checking the cgroups tree. It rather uses a systemd library call to check if systemd is available or not. http://sourceforge.net/p/openvpn/openvpn-testing/ci/f33ee6bcb12fdc3869b17b7c528a209f16581e2e/ I would recommend Jon to apply this patch (and a few other systemd related patches) to our current OpenVPN releases in Fedora to improve the systemd integration.
One thing I forgot to mention, I've tested my SELinux rules against 3 different OpenVPN configurations. Two of them have been started via systemctl. One of them ask only for username/password, the other one username/password and encryption key password. The last configuration OpenVPN is started manually (from the root account) using only PKCS#12 password (not PKCS#11 PIN code).
We need to see this actual avc's this looks like openvpnc is executing systemd_passwd systemd_passwd_agent_domtrans(openvpn_t)
I went through my logs and found these AVC denials: type=AVC msg=audit(1409055562.976:998): avc: denied { setattr } for pid=1316 comm="systemd-ask-pas" name="tmp.13RScD" dev="tmpfs" ino=534338 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:systemd_passwd_var_run_t:s0 tclass=file type=AVC msg=audit(1409055562.976:997): avc: denied { add_name } for pid=1316 comm="systemd-ask-pas" name="tmp.13RScD" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:systemd_passwd_var_run_t:s0 tclass=dir type=AVC msg=audit(1409055562.976:999): avc: denied { create } for pid=1316 comm="systemd-ask-pas" name="sck.5938281464376043045" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:systemd_passwd_var_run_t:s0 tclass=sock_file type=AVC msg=audit(1409055562.977:1001): avc: denied { signull } for pid=811 comm="systemd-tty-ask" scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:system_r:mount_t:s0 tclass=process type=AVC msg=audit(1409055600.374:1002): avc: denied { remove_name } for pid=1316 comm="systemd-ask-pas" name="sck.5938281464376043045" dev="tmpfs" ino=534340 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:systemd_passwd_var_run_t:s0 tclass=dir type=AVC msg=audit(1409055600.374:1003): avc: denied { unlink } for pid=1316 comm="systemd-ask-pas" name="ask.13RScD" dev="tmpfs" ino=534338 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:systemd_passwd_var_run_t:s0 tclass=file type=AVC msg=audit(1413191225.64:31): avc: denied { read } for pid=894 comm="systemd-tty-ask" name="cmdline" dev="proc" ino=4026531981 scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file type=AVC msg=audit(1412323962.542:507): avc: denied { search } for pid=840 comm="systemd-tty-ask" name="2962" dev="proc" ino=41131 scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dir But your observation is correct, OpenVPN compiled with --enable-systemd will try to start systemd-ask-password when it asks for usernames, passwords and other passphrases.
Could you please re-test it with $ cat mypol.te policy_module(mypol,1.0) require{ type mount_t; type openvpn_t; type systemd_passwd_agent_t; } systemd_passwd_agent_domtrans(mount_t) systemd_passwd_agent_domtrans(openvpn_t) kernel_read_system_state(systemd_passwd_agent_t) and run # make -f /usr/share/selinux/devel/Makefile mypol # semodule -i mypol.pp
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I tested it on clear Fedora 21 and policy by Miroslav Grepl solved problem. I confirm solution from comment 6. Can be this policy added into Fedora? Thanks.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 '21'. 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 21 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 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.