Bug 508451 - False positive warnings for denyhosts lock file.
False positive warnings for denyhosts lock file.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: denyhosts (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-27 07:02 EDT by Mike Pope
Modified: 2011-06-23 07:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-23 07:49:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
denyhosts.conf (20.94 KB, text/plain)
2009-07-01 02:44 EDT, Mike Pope
no flags Details
This patch will close the lockfile on exec. (613 bytes, application/octet-stream)
2010-06-29 11:01 EDT, Daniel Walsh
no flags Details

  None (edit)
Description Mike Pope 2009-06-27 07:02:26 EDT
Description of problem:

Regular warnings from setroubleshoot:

"SELinux is preventing restorecon (setfiles_t) "write" to /var/lock/subsys/denyhosts (var_lock_t)." 

Version-Release number of selected component (if applicable):

selinux-policy-3.6.12-53.fc11.noarch

How reproducible:

Always.

Steps to Reproduce:
1. Install and run denyhosts with selinux enabled.
  
Actual results:

Warnings as above.

Expected results:

No warnings, AFAICT /var/lock/subsys/denyhosts should be var_lock_t.

Additional info:

Denyhosts version is: denyhosts-2.6-17.fc11.noarch
Comment 1 Miroslav Grepl 2009-06-29 06:46:45 EDT
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.
Comment 2 Daniel Walsh 2009-06-29 10:57:30 EDT
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.
Comment 3 Jason Tibbitts 2009-06-29 12:21:48 EDT
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.
Comment 4 Mike Pope 2009-06-29 20:53:57 EDT
When I am back with the offending machine I will attach the denyhosts.conf, but IIRC it is minimally different from the default.
Comment 5 Mike Pope 2009-07-01 02:44:48 EDT
Created attachment 350061 [details]
denyhosts.conf
Comment 6 Jason Tibbitts 2009-07-01 02:56:25 EDT
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.)
Comment 7 Mike Pope 2009-07-01 03:26:28 EDT
> 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.
Comment 8 Daniel Walsh 2009-07-01 09:10:44 EDT
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.
Comment 9 Miroslav Grepl 2009-07-01 12:18:14 EDT
Jason,

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

* Wed Mar 04 2009 Jason L Tibbitts III <tibbs@math.uh.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.
Comment 10 Jason Tibbitts 2009-07-01 12:32:00 EDT
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.
Comment 12 Bug Zapper 2010-04-27 11:17:30 EDT
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
Comment 13 Bug Zapper 2010-06-28 09:19:38 EDT
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.
Comment 14 Mike Pope 2010-06-28 19:53:43 EDT
The bug is still there in F13.
Comment 15 Jason Tibbitts 2010-06-28 20:13:25 EDT
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.
Comment 16 Mike Pope 2010-06-28 20:47:47 EDT
Fair enough.  It is certainly in the SElinux folks interest that SElinux generate fewer false positives which only encourage me to turn it off.
Comment 17 Daniel Walsh 2010-06-29 11:01:28 EDT
Created attachment 427707 [details]
This patch will close the lockfile on exec.
Comment 18 Daniel Walsh 2010-06-29 11:02:10 EDT
Mike if you apply this patch to your code, the leak should go away.
Comment 19 Mike Pope 2010-06-29 19:49:23 EDT
Applied, with thanks.  I will report back in a couple of days.
Comment 20 Mike Pope 2010-07-13 21:19:44 EDT
That took longer than expected, but I can confirm the patch quietens the SElinux warnings.
Comment 21 Jason Tibbitts 2010-07-19 17:13:22 EDT
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.
Comment 22 Bug Zapper 2011-06-02 13:58:42 EDT
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
Comment 23 Mike Pope 2011-06-23 00:15:13 EDT
I am no longer seeing the problem, and recommend this bug be closed.

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