Created attachment 317376 [details] denyhosts purge plugin to restore selinux context to /etc/hosts.deny Description of problem: When denyhosts purges the /etc/hosts.deny file it creates a temporary file /etc/hosts.deny.purge.tmp which it edits and then renames to /etc/hosts.deny This new file has a selinux label applied of "user_u:object_r:etc_runtime_t:s0" applied since it is a file created at runtime by a daemon without any special selinux policy. The fact that a new file in /etc/ has the etc_runtime_t label is correct as that prevents other daemons from reading a file that might have been created or modified by an untrusted process, however, denyhosts has to do this to operate correctly and when it edits the file all of the other daemons which need to read the /etc/hosts.deny (as they enforce tcpwrappers policy as well) can not read the file and incorrectly deny service to valid clients. This includes critical services like: NFS (used for sharing filesystems) and tftp (used to install systems) and maybe others. This makes using denyhosts out of the box with an enforcing selinux install impossible. I've seen a similar bug #212771 reported in bugzilla in 2006 and closed early 2008 without any fix as https://bugzilla.redhat.com/show_bug.cgi?id=212771 The solutions I've seen in some discussion of this problem on email lists include: Best: Write a selinux policy for denyhosts that allows it to edit and set the the /etc/hosts.deny file to a special type, and modify the policy of other daemons that need to access it so they also have access to that new type. To avoid race conditions the temporary file needs to be created in the denyhosts code with the right type (or it might be possible for the policy type transistion rules to set it correctly at creation) Current work-around/solution: I wrote a denyhosts plugin that is called whenever the "purge" operation is done. The plugin just calls "restorecon" on the /etc/hosts.deny* files after the purge occurs so the files are changed back to "etc_t" type files and thus can be read by other programs. This is not a completely correct solution as there is a race condition while the purge file is being created and renamed and before the "plugin" is executed -- but I would guess it's a small window. I've included my plugin as an attachment to this report. Version-Release number of selected component (if applicable):denyhosts-2.6-5.el5 How reproducible: Any system using selinux in enforcing mode, denyhosts, nfs (or tftp) and waiting at least 4 weeks (the default PURGE time in the default denyhosts.conf that is installed by the rpm) should experience the problem. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is indeed a dup of 212771. Your plugin is a good idea but unfortunately this is not really fixable without significant changes to the underlying selinux system. I am not well versed in selinux and have not been successful in getting the selinux folks to take an interest in this issue. Honestly I don't know that the problem is really even properly solvable under the selinux framework. It seems to me that the best solution would be to make tcp_wrappers look in a directory for hosts.deny files which could then each have the proper context. You are welcome to file a ticket against the selinux policy. I'll be happy to include your plugin in the Fedora denyhosts package. *** This bug has been marked as a duplicate of bug 212771 ***
See also the thread beginning here: https://www.redhat.com/archives/fedora-selinux-list/2007-September/msg00050.html
Including the plugin would be great, as then I would not have to verify that my custom plugin is included whenever there are updates to denyhosts. I'll look at filing a report against selinux policy and see what happens.