Bug 212771 - Wrong security context set on /etc/hosts.deny, breaks NFS server
Summary: Wrong security context set on /etc/hosts.deny, breaks NFS server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: denyhosts
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: bzcl34nup
: 463191 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-28 22:48 UTC by Jon Burgess
Modified: 2008-09-22 15:35 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-06 16:35:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jon Burgess 2006-10-28 22:48:16 UTC
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.

Comment 1 Jason Tibbitts 2006-10-28 23:04:02 UTC
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.

Comment 2 Jason Tibbitts 2006-10-28 23:58:40 UTC
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.

Comment 3 Jon Burgess 2006-10-29 00:21:11 UTC
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


Comment 4 Jason Tibbitts 2006-10-29 03:47:35 UTC
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.

Comment 5 Gianluca Sforna 2006-11-23 16:19:01 UTC
I just realized it also broke my tftpd server in the same way :(

Should I file a separate bug report?

Comment 6 Jason Tibbitts 2006-11-23 16:44:13 UTC
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.

Comment 7 Bug Zapper 2008-04-04 04:12:42 UTC
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

Comment 8 Bug Zapper 2008-05-06 16:35:58 UTC
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.

Comment 9 Jason Tibbitts 2008-09-22 15:35:33 UTC
*** Bug 463191 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.