Bug 212771

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. ***