The selinux module for fail2ban (0.9.1, probably earlier) seems incomplete. I am currently playing with selinux in strict mode. Some problems I've had to fix: 1.) Contexts are incorrect on /usr/lib/python-exec/python2.7/fail2ban-{client,server}. Actually, there is no context specified for these files. Rather, the contexts are specified for /usr/bin/fail2ban*. 2.) Module is missing init_daemon_pid_file() 3.) fail2ban_client_t needs to manage (I think, probably more than just read) fail2ban_var_run_t stuff 4.) Logrotate needs to be able to transition to fail2ban_client_t domain (it runs fail2ban-client). I can try to dig up my log files if needed, but it took a few rounds of fix-and-see-what-else-broke. My fixes: # local.te init_daemon_pid_file(fail2ban_var_run_t, dir, "fail2ban") manage_dirs_pattern(fail2ban_client_t, fail2ban_var_run_t, fail2ban_var_run_t) manage_files_pattern(fail2ban_client_t, fail2ban_var_run_t, fail2ban_var_run_t) fail2ban_domtrans_client(logrotate_t) # local.fc /usr/lib/python-exec/python2.7/fail2ban-client -- gen_context(system_u:object_r:fail2ban_client_exec_t,s0) /usr/lib/python-exec/python2.7/fail2ban-server -- gen_context(system_u:object_r:fail2ban_exec_t,s0) At least for me, after these fixes, fail2ban runs smoothly, although there are a few iptables-related entries I'm not sure what to do about. They don't seem to affect fail2ban's operation, at least in my case: denied { read write } for pid=1462 comm="iptables" path=2F746D702F6661693262616E5F364F4A6971452E7374646F7574202864656C6574656429 dev="tmpfs" ino=3870 scontext=system_u:system_r:iptables_t tcontext=system_u:object_r:fail2ban_tmp_t tclass=file permissive=0 denied { read write } for pid=1462 comm="iptables" path=2F746D702F6661693262616E5F616B6176366D2E737464657272202864656C6574656429 dev="tmpfs" ino=3871 scontext=system_u:system_r:iptables_t tcontext=system_u:object_r:fail2ban_tmp_t tclass=file permissive=0 denied { read write } for pid=1464 comm="iptables" path=2F746D702F6661693262616E5F364F4A6971452E7374646F7574202864656C6574656429 dev="tmpfs" ino=3870 scontext=system_u:system_r:iptables_t tcontext=system_u:object_r:fail2ban_tmp_t tclass=file permissive=0 denied { read write } for pid=1464 comm="iptables" path=2F746D702F6661693262616E5F616B6176366D2E737464657272202864656C6574656429 dev="tmpfs" ino=3871 scontext=system_u:system_r:iptables_t tcontext=system_u:object_r:fail2ban_tmp_t tclass=file permissive=0 denied { read write } for pid=1459 comm="iptables" path=2F746D702F6661693262616E5F364F4A6971452E7374646F7574202864656C6574656429 dev="tmpfs" ino=3870 scontext=system_u:system_r:iptables_t tcontext=system_u:object_r:fail2ban_tmp_t tclass=file permissive=0
Hm, do you happen to have any error logs that show the client requiring manage privileges in fail2ban_var_run_t? Read privileges I can easily assume (access to PID file or socket to know if the daemon is running or not, or to connect to the daemon) but I fail to see directly how a client needs manage rights on those resources.
(In reply to Sven Vermeulen from comment #1) > Hm, do you happen to have any error logs that show the client requiring > manage privileges in fail2ban_var_run_t? It's just a single line: avc: denied { write } for pid=1446 comm="fail2ban-client" name="fail2ban" dev="tmpfs" ino=2761 scontext=system_u:system_r:fail2ban_client_t tcontext=system_u:object_r:fail2ban_var_run_t tclass=dir permissive=1 It looks like you are correct in that the manage permissions are far too broad. What is happening is that fail2ban-client checks that the directory is writable before calling fail2ban-server. From /usr/lib/python-exec/python2.7/fail2ban-client:197 if not os.access(socket_dir, os.W_OK | os.X_OK): logSys.error( "Directory %s exists but not accessible for writing" % (socket_dir,)) return False Commenting out those lines allows fail2ban start without the extra permissions for fail2ban_client_t. (As well as allowing fail2ban_client_t to write to fail2ban_var_run_t dir) (This is assuming the other fixes I've posted, ie the daemon_init_pid_file and the file contexts added)
Can you try and find the minimal permissions that are needed? If only "write" on the directory is sufficient?
(In reply to Sven Vermeulen from comment #3) > Can you try and find the minimal permissions that are needed? If only > "write" on the directory is sufficient? After trying it, yes, all that is needed is write permissions for fail2ban_client_t to the directory. Sorry if my previous post was a little confusing. Also, the iptables denials I mentioned in the initial report can be ignored/dontaudited. Fail2ban uses the subprocess module and redirects the output from various commands (iptables, sendmail) to temporary files. They are only used in debugging and are otherwise deleted pretty quickly.
Suggestions 2, 3 (but just write then), 4 and a use_ptys one are now in the policy. I do not have any python-execs on my system. Is there anything different for you from the following? [binary R ] net-analyzer/fail2ban-0.9.2::gentoo USE="(selinux) -systemd" PYTHON_SINGLE_TARGET="python2_7 -pypy -python3_3 -python3_4" PYTHON_TARGETS="python2_7 python3_3 -pypy -python3_4" 0 KiB Anyway, policy is committed to our repo, will be in rev 7.
r7 is now ~arch
Sorry for the late reply. I don't have the python-execs anymore either, so something must have changed since I reported the bug. A diff of fail2ban-0.9.2.ebuild (what I currently have) and fail2ban-0.9.1.ebuild shows someone added DISTUTILS_SINGLE_IMPL, which probably has something to do with it. Anyway, with the new changes it starts up correctly. I'll have to see about logrotate still, but that is more of a minor issue. Thanks
r7 is stable
