Bug 508451

Dan,

DenyHosts is running within the initrc domain

# ps -eZ | grep deny
system_u:system_r:initrc_t:s0 4811 ?       00:00:00 denyhosts.py

I guess we need policy for DenyHosts.

denyhost is leaking an open file descriptor to /var/lock/subsys/denyhosts.  THere is no reason for restorecon to write to this file.  So I think the denyhosts.py file needs to close the descriptor on exec before execing restorecon.

denyhost.py needs to do something like

import fcntl
fcntl.fcntl(fd, fcntl.F_SETFD, fcntl.FD_CLOEXEC)

Where fd is the open file descrotor to the lock file


denyhost should probably have a policy written for it.

The original report is missing sufficient information for me to understand from the perspective of denyhosts what's actually happening.  I'd like to understand the situation rather than randomly patching things in the hope that it will work.

In its default configuration, the denyhosts daemon doesn't exec anything, so in that case I can't quite see how it could leak any file descriptors.  Can someone verify any changes from the default configuration that have been made?  Could I perhaps see the denyhosts logs from the time when the selinux denial happens?

My best guess is that a plugin is enabled, which would make sense, but there was no mention of this in the original bug report.

When I am back with the offending machine I will attach the denyhosts.conf, but IIRC it is minimally different from the default.

Created attachment 350061 [details]
denyhosts.conf

So you did enable the non-default plugin which calls restorecon.  Not sure why that wasn't just stated at the beginning, but at least it makes sense now.  Actually I'm not quite sure what difference it makes since you're also not using the default file to stored denied hosts (hosts.evil instead of hosts.deny).  Perhaps the selinux policy will actually label those the same, I'm not really sure.

I have a couple of different approaches for fixing the file descriptor leak; I'll try to put together some test builds for you tomorrow.  (Simplest would be to just pass O_CLOEXEC to open, but python doesn't support it for whatever bizarre reason.)

> So you did enable the non-default plugin which calls restorecon.  Not sure
why that wasn't just stated at the beginning...

Cut me some slack.  I installed denyhosts around F8 or earlier.

> Actually I'm not quite sure what difference it makes since you're also not
using the default file to stored denied hosts (hosts.evil instead of
hosts.deny).

AFAICT its irrelevant.  The warnings are all about the lock file.

The problem is the execing of restorecon.

Since denyhosts does not have a policy, denyhosts runs as initrc_t.  SELinux policy says initrc_t running restorecon transitions to restorecon_t which sees the leaked file descriptors and reports it.  So renaming hosts.deny to hosts.evil, is not really the problem.  The problem is that the plugin is running restorecon to set the label back from etc_runtime_t to etc_t.  ( I guess) and this is exposing the leaked file descriptors.

initrc_t creating files in /etc creates them as etc_runtime_t not etc_t.

Jason,

correct me if I am wrong. I see from denyhosts.spec

* Wed Mar 04 2009 Jason L Tibbitts III <tibbs.edu> - 2.6-18
- Add patch to keep proper file context on the hosts.deny file.

But denyhosts-2.6-selinux.patch isn't applied. Then I need to use restorecon.sh plugin to set the label back from etc_runtime_t to etc_t.

That's because that patch didn't actually work.  I used some code that Dan had provided which did the restorecon call in python code but it never had any effect for me.  You'll note that version exists only in CVS; I provided a scratch build for testing but did not build it for distribution.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

The bug is still there in F13.

And as far as I know it's still unfixable in denyhosts.  Until the selinux folks come up with some policy for denyhosts I don't see this changing.  I'm not going to write such a policy so other than lobby the selinux folks to do so there's not much I can do.

Fair enough.  It is certainly in the SElinux folks interest that SElinux generate fewer false positives which only encourage me to turn it off.

Created attachment 427707 [details]
This patch will close the lockfile on exec.

Mike if you apply this patch to your code, the leak should go away.

Applied, with thanks.  I will report back in a couple of days.

That took longer than expected, but I can confirm the patch quietens the SElinux warnings.

Thank you for testing.  I am out of the country and away from my development environment at the moment, but I'll provide an updated package when I return from vacation in August.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I am no longer seeing the problem, and recommend this bug be closed.