Red Hat Bugzilla – Bug 212771
Wrong security context set on /etc/hosts.deny, breaks NFS server
Last modified: 2008-09-22 11:35:33 EDT
Description of problem: Have denyhosts setup to manage my /etc/hosts.deny list and I find that remote clients fail to mount NFS shares from my machine. Not sure if this is a denyhosts problem as such or the configured SELinux policy. What is the correct place to report SELinux issues with extras packages? Version-Release number of selected component (if applicable): denyhosts-2.5-1.fc5 selinux-policy-targeted-2.3.7-2.fc5 selinux-policy-2.3.7-2.fc5 How reproducible: Every time, after denyhosts updates /etc/hosts.deny Steps to Reproduce: 1. Configure denyhosts to download blacklists and update /etc/hosts.deny 2. Enable NFS server with a share 3. Try mounting NFS chare on remote client, which fails Actual results: /var/log/messages Oct 28 23:35:56 shark portmap[2883]: warning: cannot open /etc/hosts.deny: Permission denied Expected results: Client mounts share OK :-) Additional info: The problem seems to the the SELinux security context of the /etc/hosts.deny file, here it is in the broken state: [root@shark ssh]# ls -lZ /etc/hosts.deny -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/hosts.deny [root@shark ssh]# restorecon -v /etc/hosts.deny restorecon reset /etc/hosts.deny context system_u:object_r:etc_runtime_t->system_u:object_r:etc_t With the correct security context, the NFS mount now works OK. [root@shark ssh]# ls -lZ /etc/hosts.deny -rw-r--r-- root root system_u:object_r:etc_t /etc/hosts.deny Unfortunately the security policy on that file gets reset every time denyhosts performs an update.
I am not blessed with any kind of server or desktop that actually keeps working once I enable selinux, so I'm not really able to do any testing with it and I am not well versed in using it. However, the problem is clearly that denyhosts performs atomic modifications to the hosts.deny file by copying it to a modified .tmp file and then renaming that into place. The .tmp file gets a different security context which it keeps as it is renamed. It seems that in general the base Fedora policy is modified to accommodate even Extras packages, so any long-term fix for this is probably going to come from the Core selinux maintainers. However, I would ask you to add a selinux context for /etc/hosts.deny.tmp and see if it helps you. From reading the semanage manpage, I'm going to guess that this would be: semanage fcontext -a -t etc_t /etc/hosts.deny.tmp If this works, I could put it into the base package. I think that denyhosts could really benefit from its own selinux policy, but this policy is probably going to have to some from someone other than me.
After further reading of the source, I realized that the .tmp file only comes into play when entries are purged; normal added entries are simply appended to the file. So my understanding of selinux must be off; I didn't think the context of a file would change depending on who appends to it. In any case, a surefire workaround for this issue would be to make a quick plugin that runs restorecon on the file and reference it with PLUGIN_DENY (and PLUGIN_PURGE). I'll ping the selinux list and try to acquire a better understanding of what selinux does here.
I am getting hosts purged at the moment. I've been running denyhosts for months and it has been catching lots of brute force SSH attempts. [root@shark bak]# ls -l /etc/hosts.deny* -rw-r--r-- 1 root root 332515 Oct 29 00:13 /etc/hosts.deny -rw-r--r-- 1 root root 332833 Oct 29 00:13 /etc/hosts.deny.purge.bak A diff shows that several hosts from Oct 1 have been removed and some new ones added. I have applied the semanage command that you suggested but it doesn't seem to have worked. An update has just occured and the file contexts have been set wrong again (I did the semanage command before the update and i've been waiting for the file to change). # semanage fcontext -a -t etc_t /etc/hosts.deny.tmp # semanage fcontext -l | grep hosts.deny /etc/hosts.deny.tmp all files system_u:object_r:etc_t:s0 Files before update: # ls -l /etc/hosts.deny* -rw-r--r-- 1 root root 332515 Oct 29 00:13 /etc/hosts.deny -rw-r--r-- 1 root root 332833 Oct 29 00:13 /etc/hosts.deny.purge.bak # ls -lZ /etc/hosts.deny* -rw-r--r-- root root system_u:object_r:etc_t /etc/hosts.deny -rw-r--r-- root root user_u:object_r:etc_runtime_t /etc/hosts.deny.purge.bak Files after update: # ls -l /etc/hosts.deny* -rw-r--r-- 1 root root 332589 Oct 29 01:13 /etc/hosts.deny -rw-r--r-- 1 root root 332515 Oct 29 01:13 /etc/hosts.deny.purge.bak # ls -lZ /etc/hosts.deny* -rw-r--r-- root root system_u:object_r:etc_runtime_t /etc/hosts.deny -rw-r--r-- root root user_u:object_r:etc_runtime_t /etc/hosts.deny.purge.bak
Well, it seems that the temp file for purging is actually /etc/hosts.deny.purge.tmp; perhaps you could try passing that to semanage, or use a pattern like /etc/hosts.deny.*. Try experimenting a bit.
I just realized it also broke my tftpd server in the same way :( Should I file a separate bug report?
No, I'm certain you have the same problem; more reports would only be closed as duplicates. The solution as of now is to make a hook that does a restorecon /etc/hosts.deny.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
*** Bug 463191 has been marked as a duplicate of this bug. ***