The current 9999 SELinux policy is missing the permission fail2ban_client_t to create and utilize the unix stream socket. The relevant audit entry: type=AVC msg=audit(1350171014.821:350): avc: denied { create } for pid=1054 comm="fail2ban-client" scontext=system_u:system_r:fail2ban_client_t tcontext=system_u:system_r:fail2ban_client_t tclass=unix_stream_socket After adding a policy with the following: allow fail2ban_client_t self:unix_stream_socket { create connect write read }; fail2ban starts but doesn't function correctly until the following is also added: logging_read_all_logs(fail2ban_client_t) This doesn't make much sense since the following directives are in the fail2ban.te in refpolicy: domtrans_pattern(fail2ban_client_t, fail2ban_exec_t, fail2ban_t) stream_connect_pattern(fail2ban_client_t, fail2ban_var_run_t, fail2ban_var_run_t, fail2ban_t) The first (if I understand it) should allow fail2ban_client_t to access things as if it's fail2ban_t if it executes a fail2ban_exec_t script. The second sounds like it should provide the necessary stream permissions but isn't for some reason. Let me know if these changes sound sane or not or if you need any more information to reproduce the issue. Reproducible: Always Steps to Reproduce: 1. Install sec-policy/selinux-*-9999 (specifically selinux-fail2ban-9999) 2. Use string enforcing and reboot with fail2ban in the default runlevel 3. fail2ban should not start with this policy Actual Results: The failure to start comes with the following audit entry: type=AVC msg=audit(1350171014.821:350): avc: denied { create } for pid=1054 comm="fail2ban-client" scontext=system_u:system_r:fail2ban_client_t tcontext=system_u:system_r:fail2ban_client_t tclass=unix_stream_socket Expected Results: Succesfully started and functioning fail2ban. After adding a policy with the following: allow fail2ban_client_t self:unix_stream_socket { create connect write read }; fail2ban starts but doesn't function correctly until the following is also added: logging_read_all_logs(fail2ban_client_t) This doesn't make much sense since the following directives are in the fail2ban.te in refpolicy: domtrans_pattern(fail2ban_client_t, fail2ban_exec_t, fail2ban_t) stream_connect_pattern(fail2ban_client_t, fail2ban_var_run_t, fail2ban_var_run_t, fail2ban_t) The first (if I understand it) should allow fail2ban_client_t to access things as if it's fail2ban_t if it executes a fail2ban_exec_t script. The second sounds like it should provide the necessary stream permissions but isn't for some reason. Let me know if these changes sound sane or not or if you need any more information to reproduce the issue.
The stream connect pattern evaluates to the following: """ allow fail2ban_client_t fail2ban_var_run_t:dir search_dir_perms; allow fail2ban_client_t fail2ban_var_run_t:sock_file write_sock_file_perms; allow fail2ban_client_t fail2ban_t:unix_stream_socket connectto; """ As such, it doesn't provide fail2ban_client_t any unix_stream_socket permissions towards itself. I'll have them added, together with the read_all_logs part (as that makes sense for a tool responsible for parsing log files).
Hmm, from reading the documentation, the fail2ban client is responsible only for communicating with the server. It is the server process that reads the log files. Can you check which process is trying to read log files (denials)? Also, are the create, connect, write and read (of fail2ban_client_t's unix_stream_socket permissions) all results of denials you had?
That would make sense but isn't the behavior I'm seeing. The denial on the log directory search: type=AVC msg=audit(1350235905.367:65): avc: denied { search } for pid=1059 comm="fail2ban-client" name="log" dev="xvda1" ino=524296 scontext=system_u:system_r:fail2ban_client_t tcontext=system_u:object_r:var_log_t tclass=dir selinux selinux # find /var -inum 524296 /var/log After adding the search capability to see which logs are being accessed, it shows that fail2ban_client_t is trying to access the logs specified in the jail.conf file: type=AVC msg=audit(1350236744.718:64): avc: denied { getattr } for pid=1052 comm="fail2ban-client" path="/var/log/sshd/current" dev="xvda1" ino=532648 scontext=system_u:system_r:fail2ban_client_t tcontext=system_u:object_r:var_log_t tclass=file Perhaps (I can verify if necessary) fail2ban_client_t opens the logs and then passes them off to fail2ban_t (fail2ban-server)? This denial does correlate with denials not executing correctly. The unix_stream_socket permissions stop the startup of the service but the access to the logs stops the denials from processing correctly. I admit this last part may be due to a flaw in fail2ban. The unix_stream_socket permissions are all results of denials I had. I can try to find a smaller set of permissions if you think it's appropriate. Let me know how else I can help with this one.
Okay, rules & explanation for this: """ # Startup failure allow fail2ban_client_t self:unix_stream_socket { create connect write read }; # Allow admin to run fail2ban-client fail2ban_run_client(sysadm_t, sysadm_r) # Needed to get output when running fail2ban-cilent userdom_use_user_terminals(fail2ban_client_t) domain_use_interactive_fds(fail2ban_client_t) # Ignore pesky searches because I'm in my home dir userdom_dontaudit_search_user_home_dirs(fail2ban_client_t) # jailreader part of the application checks log files first logging_search_logs(fail2ban_client_t) allow fail2ban_client_t self:capability dac_read_search; # runs as root, but might check non-root files allow fail2ban_client_t logfile:file getattr; allow fail2ban_client_t logfile:dir search_dir_perms; ## Probably need to create logging_getattr_all_logs & logging_search_all_logs ? """ I'll incorporate this and submit upstream (except the fail2ban_run_client part, that I'll just put in our policy)
