Description of problem: fail2ban fails to start because an avc denial occurs. I did a touch/.autorelabel to trigger a filesystem relabel and rebooted, but the problem still exists with the freshly relabelled filesystem, so I suspect an error in the policy. Summary SELinux is preventing the fail2ban-server from using potentially mislabeled files (<Unknown>). Detailed Description SELinux has denied fail2ban-server access to potentially mislabeled file(s) (<Unknown>). This means that SELinux will not allow fail2ban-server to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access If you want fail2ban-server to access this files, you need to relabel them using restorecon -v <Unknown>. You might want to relabel the entire directory using restorecon -R -v <Unknown>. Additional Information Source Context unconfined_u:system_r:fail2ban_t:s0 Target Context system_u:object_r:tmp_t:s0 Target Objects None [ dir ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-74.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.home_tmp_bad_labels Host Name withnail.phys.ucl.ac.uk Platform Linux withnail.phys.ucl.ac.uk 2.6.23.9-85.fc8 #1 SMP Fri Dec 7 15:49:36 EST 2007 x86_64 x86_64 Alert Count 6 First Seen Fri Jan 18 14:30:35 2008 Last Seen Fri Jan 18 14:42:59 2008 Local ID ddb254f5-c167-4ab7-b7ee-e3a02435e70c Line Numbers Raw Audit Messages avc: denied { search } for comm=fail2ban-server dev=sda2 egid=0 euid=0 exe=/usr/bin/python exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=tmp pid=3658 scontext=unconfined_u:system_r:fail2ban_t:s0 sgid=0 subj=unconfined_u:system_r:fail2ban_t:s0 suid=0 tclass=dir tcontext=system_u:object_r:tmp_t:s0 tty=(none) uid=0 Version-Release number of selected component (if applicable): libselinux-2.0.43-1.fc8 libselinux-python-2.0.43-1.fc8 selinux-policy-3.0.8-74.fc8 selinux-policy-targeted-3.0.8-74.fc8 libselinux-2.0.43-1.fc8 selinux-policy-devel-3.0.8-74.fc8 fail2ban-0.8.1-10.fc8 How reproducible: Everytime Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This says that fail2ban is searching the /tmp directory. Why would fail2ban be reading this directory? Looks like a configuration problem.
it seems that according to default fail2ban.conf file, in /tmp there should be fail2ban.sock which fail2ban uses to communicate with the daemon. Also, I googled a bit and i found that command '/usr/bin/fail2ban-client start' seems to start the server.. haven't really yet examined why.
Well, it's this part of the fail2ban init script: start() { echo -n $"Starting fail2ban: " getpid if [ -z "$pid" ]; then rm -rf /tmp/fail2ban.sock # in case of unclean shutdown $FAIL2BAN start > /dev/null RETVAL=$? fi if [ $RETVAL -eq 0 ]; then touch /var/lock/subsys/fail2ban echo_success else echo_failure fi echo return $RETVAL } It's getting stuck at deleting /tmp/fail2ban.sock (even though it doesn't exist).... fail2ban creates that file when it starts, and removes it when it cleanly shuts down. That line is needed in the init script in case the system has been uncleanly shutdown - if the fail2ban.sock file is there when fail2ban tries to start, it fails.
fail2ban should not be using /tmp for communications. /tmp is owned by users, any process that is running as root should never use /tmp. They should use /var/run. If fail2ban has to communicate with a user via a fifo_file or socket it should use /var/run and set the protections appropriately to allow this communications. Jonathan if you want to allow this access you can use audit2allow to build a local policy. # grep fail2ban /var/log/audit/audit.log | audit2allow -m myfail2ban # semodule -i myfail2ban.pp
Same problem here. I'll be glad if fail2ban should "natively" use corrects paths... This fix allowed me to start fail2ban, but there are other SELinux denials, so I'm not sure it works properly :/ By the way, audit2allow should be launched with '-M' and not '-m' :-)
This (see below) is what I had to add to SELinux so that at least the ssh-jail of fail2ban works, I created the module with audit2allow, so I'm quite sure it's not optimal and that a lot of stuff is still missing :-). And you can see hat the /tmp problem is not really the biggest part of it :-) -------------------------------------------------------- module myfail2ban 1.0; require { type net_conf_t; type dns_port_t; type iptables_t; type fs_t; type fail2ban_t; type mqueue_spool_t; type node_t; type reserved_port_t; type inotifyfs_t; type netif_t; type etc_runtime_t; type tmp_t; type devlog_t; type var_spool_t; type syslogd_t; type smtp_port_t; type etc_mail_t; type sendmail_exec_t; class node { tcp_recv tcp_send udp_recv udp_send }; class netif { tcp_recv tcp_send udp_recv udp_send }; class unix_stream_socket { read write connectto }; class capability { setuid setgid }; class tcp_socket { name_connect send_msg read create recv_msg write getattr connect getopt }; class file { execute read lock create ioctl execute_no_trans write getattr unlink }; class filesystem getattr; class sock_file { write create unlink getattr }; class netlink_route_socket { write getattr read bind create nlmsg_read }; class unix_dgram_socket { write create connect sendto }; class udp_socket { write getattr send_msg connect read create recv_msg }; class dir { search read write getattr remove_name add_name }; } #============= fail2ban_t ============== allow fail2ban_t devlog_t:sock_file write; allow fail2ban_t dns_port_t:udp_socket { send_msg recv_msg }; allow fail2ban_t etc_mail_t:dir { search getattr }; allow fail2ban_t etc_mail_t:file { read getattr }; allow fail2ban_t etc_runtime_t:file { read getattr }; allow fail2ban_t fs_t:filesystem getattr; allow fail2ban_t inotifyfs_t:dir { read getattr }; allow fail2ban_t mqueue_spool_t:dir { write search read remove_name getattr add_name }; allow fail2ban_t mqueue_spool_t:file { write getattr read lock create unlink }; allow fail2ban_t net_conf_t:file { read getattr }; allow fail2ban_t netif_t:netif { tcp_recv tcp_send udp_recv udp_send }; allow fail2ban_t node_t:node { tcp_recv tcp_send udp_recv udp_send }; allow fail2ban_t reserved_port_t:tcp_socket { name_connect send_msg recv_msg }; allow fail2ban_t self:capability { setuid setgid }; allow fail2ban_t self:netlink_route_socket { write getattr read bind create nlmsg_read }; allow fail2ban_t self:tcp_socket { write getattr connect read getopt create }; allow fail2ban_t self:udp_socket { write read create connect getattr }; allow fail2ban_t self:unix_dgram_socket { write create connect }; allow fail2ban_t self:unix_stream_socket connectto; allow fail2ban_t sendmail_exec_t:file { read execute execute_no_trans }; allow fail2ban_t smtp_port_t:tcp_socket { name_connect send_msg recv_msg }; allow fail2ban_t syslogd_t:unix_dgram_socket sendto; allow fail2ban_t tmp_t:dir { write remove_name search add_name getattr }; allow fail2ban_t tmp_t:file { write getattr read create unlink ioctl }; allow fail2ban_t tmp_t:sock_file { create unlink getattr }; allow fail2ban_t var_spool_t:dir { search getattr }; #============= iptables_t ============== allow iptables_t fail2ban_t:unix_stream_socket { read write }; --------------------------------------------------------
And another problem is that /etc/fail2ban/fail2ban.conf has an option socket = /tmp/fail2ban.sock So if you change the path there then /etc/init.d/fail2ban has no luck in removing the socket with rm -rf /tmp/fail2ban.sock It would be better if /etc/init.d/fail2ban reads the configuration to remove the correct socket. Btw. /usr/bin/fail2ban-client has the option -s to set the socket path, so maybe an /etc/sysconfig/fail2ban configuration file with a define for the socket path would be a solution? Another option of /usr/bin/fail2ban-client is -x which (according to the source code) force execution of the server and to remove the socket file so instead of if [ -z "$pid" ]; then rm -rf /tmp/fail2ban.sock # in case of unclean shutdown $FAIL2BAN start > /dev/null RETVAL=$? fi you could use if [ -z "$pid" ]; then $FAIL2BAN -x start > /dev/null RETVAL=$? fi and then you can change the socket path in /etc/fail2ban/fail2ban.conf
I'll move the socket file out of /tmp to /var/run as suggested by Dan in comment #4, thanks!
Created attachment 293664 [details] Patch to spec file Patch to spec file
Created attachment 293665 [details] Updated init file patch Removes the "rm -rf /tmp/fail2ban.sock" and adds the -x argument to the start command which removes the socket file if present.
Created attachment 293666 [details] Change the defaul location of the socket file to /var/run Change the defaul location of the socket file to /var/run
Even with those patches to move the socket file to /var/run, fail2ban doesn't start as it triggers another SElinux denial. Adding Dan Walsh to cc. Warning below: Summary SELinux is preventing fail2ban-server (fail2ban_t) "create" to <Unknown> (var_run_t). Detailed Description SELinux denied access requested by fail2ban-server. It is not expected that this access is required by fail2ban-server and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for <Unknown>, restorecon -v <Unknown> If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context unconfined_u:system_r:fail2ban_t:s0 Target Context unconfined_u:object_r:var_run_t:s0 Target Objects None [ sock_file ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-81.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name renton.jgu Platform Linux renton.jgu 2.6.23.12-101.fc8 #1 SMP Fri Jan 4 16:29:29 EST 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 31 Jan 2008 23:06:31 GMT Last Seen Thu 31 Jan 2008 23:06:31 GMT Local ID 5c3e5f2f-a408-4da2-9071-26f82ce3cfd8 Line Numbers Raw Audit Messages avc: denied { create } for comm=fail2ban-server egid=0 euid=0 exe=/usr/bin/python exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=fail2ban.sock pid=9084 scontext=unconfined_u:system_r:fail2ban_t:s0 sgid=0 subj=unconfined_u:system_r:fail2ban_t:s0 suid=0 tclass=sock_file tcontext=unconfined_u:object_r:var_run_t:s0 tty=(none) uid=0
Fixed in selinux-policy-3.2.5-25.fc9
Thanks Dan. Any chance of adding the fix to the policies in F-7 and F-8 as well?
Fixed in selinux-policy-3.0.8-84.fc8 Fixed in selinux-policy-2.6.4-71.fc7
Thanks Dan. I am actually re-opening the bug though, as it's not fixed until Axel adds the patches and builds new packages.
Dan - still not seeing selinux-policy-3.0.8-84.fc8 in updates or updates testing. Latest I see is 3.0.8-83.fc8 in updates-testing. Axel - any chance of applying these patches and pushing an updated package?
Thanks, new packages will appear in rawhide and updates-testing!
fail2ban-0.8.1-11.fc8 has been submitted as an update for Fedora 8
fail2ban-0.8.1-11.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update fail2ban'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1678
With fail2ban-0.8.1-11.fc8 selinux-policy-3.0.8-84.fc8 selinux-policy-targeted-3.0.8-84.fc8 I still get the access denial in comment 12. time->Mon Feb 18 22:27:33 2008 type=SYSCALL msg=audit(1203370053.248:2761): arch=c000003e syscall=49 success=no exit=-13 a0=3 a1=7ffffd18fe20 a2=18 a3=0 items=0 ppid=21018 pid=21019 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="fail2ban-server" exe="/usr/bin/python" subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) type=AVC msg=audit(1203370053.248:2761): avc: denied { create } for pid=21019 comm="fail2ban-server" name="fail2ban.sock" scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file Should I pick up a newer selinux-policy? I couldn't see any in updates-testing.
By the way, the path in /usr/share/fail2ban/server/ssocket.py is changed, but both .../client/csocket.py and .../client/fail2banreader.py still point to /tmp. Shouldn't they all be the same?
I still need at least this (see below) to get fail2ban (fail2ban-0.8.1-11.fc8) to work wth selinux (selinux-policy-3.0.8-84.fc8), and this is only the SSH jail. I used grep fail2ban /var/log/audit/audit.log | audit2allow -M myfail2ban to create the file. ----------------------------------------------- module myfail2ban 1.0; require { type net_conf_t; type dns_port_t; type iptables_t; type fail2ban_t; type node_t; type reserved_port_t; type inotifyfs_t; type netif_t; type etc_runtime_t; type tmp_t; type fail2ban_log_t; type system_mail_t; class node { tcp_recv tcp_send udp_recv udp_send }; class netif { tcp_recv tcp_send udp_recv udp_send }; class unix_stream_socket { read write connectto }; class capability setgid; class tcp_socket { name_connect send_msg read create recv_msg write connect getopt }; class file { read create write getattr unlink append }; class netlink_route_socket { write getattr read bind create nlmsg_read }; class udp_socket { write getattr send_msg connect read create recv_msg }; class dir { write getattr read remove_name search add_name }; } #============= fail2ban_t ============== allow fail2ban_t dns_port_t:udp_socket { send_msg recv_msg }; allow fail2ban_t etc_runtime_t:file getattr; allow fail2ban_t inotifyfs_t:dir { read getattr }; allow fail2ban_t net_conf_t:file { read getattr }; allow fail2ban_t netif_t:netif { tcp_recv tcp_send udp_recv udp_send }; allow fail2ban_t node_t:node { tcp_recv tcp_send udp_recv udp_send }; allow fail2ban_t reserved_port_t:tcp_socket { name_connect send_msg recv_msg }; allow fail2ban_t self:capability setgid; allow fail2ban_t self:netlink_route_socket { write getattr read bind create nlmsg_read }; allow fail2ban_t self:tcp_socket { write getopt create read connect }; allow fail2ban_t self:udp_socket { write read create connect getattr }; allow fail2ban_t self:unix_stream_socket connectto; allow fail2ban_t tmp_t:dir { write remove_name getattr search add_name }; allow fail2ban_t tmp_t:file { write read create unlink getattr }; #============= iptables_t ============== allow iptables_t fail2ban_t:unix_stream_socket { read write }; #============= system_mail_t ============== allow system_mail_t fail2ban_log_t:file append; allow system_mail_t fail2ban_t:unix_stream_socket { read write }; ----------------------------------------------- So, to move the socket from /tmp to /var/run changed changed the problem only a little bit :-)
Please attach the audit.log used to build these rules.
fail2ban-0.8.1-11.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Created attachment 298458 [details] Audit log file Yep, I still have problems with fail2ban and selinux. I use fail2ban-0.8.1-11.fc8 and selinux-policy-3.0.8-93.fc8 and still have permission problems. I included the audit.log file. I created a .pp module from the audit.log file and with the additional .pp module it works.
Well selinux-policy-3.0.8-94.fc8 Has the fix for etc_runtime_t and connecto, You seem to be missing a transition to email, what mail agent are you using?
Does it work if you execute chcon -t sendmail_exec_t /bin/mail
Created attachment 298461 [details] audit log file I use sendmail and 'chcon -t sendmail_exec_t /bin/mail' changed something but I get still errors.
The errors you are now showing: audit2allow -i ~/Download/audit.log #============= fail2ban_t ============== allow fail2ban_t etc_runtime_t:file { read getattr }; allow fail2ban_t self:unix_stream_socket connectto; >>> Fixed in selinux-policy-3.0.8-94.fc8 #============= iptables_t ============== allow iptables_t fail2ban_t:unix_stream_socket { read write }; #============= system_mail_t ============== allow system_mail_t fail2ban_t:unix_stream_socket { read write }; >>> Both of these are leaked file descriptors in the fail2ban program, which I believe is also being released. These can safely be ignored, since the will not stop the apps from functioning. selinux-policy-3.0.8-95.fc8 will have the labeling of /bin/mail changed to sendmail_exec_t
The permissions for fail2ban seem to be a bit off still. This is F11 with the latest updates-testing policy installed. root@smaug:[~]# rpm -q fail2ban fail2ban-0.8.4-23.fc11.noarch root@smaug:[~]# rpm -q selinux-policy-targeted selinux-policy-targeted-3.6.12-86.fc11.noarch Starting a default configuration of fail2ban results in: Raw Audit Messages : node=smaug.lan type=AVC msg=audit(1257265563.624:246): avc: denied { read write } for pid=31230 comm="iptables" path="socket:[224507]" dev=sockfs ino=224507 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=smaug.lan type=AVC msg=audit(1257265563.624:246): avc: denied { read write } for pid=31230 comm="iptables" path="socket:[224518]" dev=sockfs ino=224518 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=smaug.lan type=AVC msg=audit(1257265563.624:246): avc: denied { read write } for pid=31230 comm="iptables" path="socket:[224515]" dev=sockfs ino=224515 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_dgram_socket node=smaug.lan type=AVC msg=audit(1257265563.624:246): avc: denied { read write } for pid=31230 comm="iptables" path="socket:[224578]" dev=sockfs ino=224578 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket node=smaug.lan type=SYSCALL msg=audit(1257265563.624:246): arch=c000003e syscall=59 success=yes exit=0 a0=e56630 a1=e566b0 a2=e56120 a3=50 items=0 ppid=31225 pid=31230 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:system_r:iptables_t:s0 key=(null)