Red Hat Bugzilla – Bug 487836
Wrong security context set on /etc/hosts.deny
Last modified: 2009-06-28 17:59:29 EDT
Description of problem:
The context on /etc/hosts.deny is etc_runtime_t, but it should be etc_t.
Compare to /etc/hosts.allow. Applications that use tcp_wrappers but cannot access hosts.deny (because of its context) are allowing access that they shouldn't.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ls -Z /etc/hosts.[ad]*
Context is different from /etc/hosts.allow.
Context is the same as /etc/hosts.allow.
There appears to be a tug-of-war over the context of hosts.deny.
See Bug 212771, Bug 463191, and Bug 483928.
Can you change deny hosts to execute restorecon on any files that it creates within the /etc/ directory. Or better yet executes setfscreatecon() on it before they get created.
I am not familiar with the code base and where files like /etc/deny.host get created. But I could help you fix the code to do the right thing, and we could change selinux-policy to always have /etc/deny.host with the correct label.
Which should probably be etc_t going forward.
I think there are two bugs here. I don't use denyhosts, but the context of /etc/hosts.deny is still *installed* incorrectly (so just right now executing restorecon won't work).
(Digging into selinux-policy a bit more...)
... In /etc/selinux/targeted/contexts/files/file_contexts, there is a line:
/etc/hosts.deny -- system_u:object_r:etc_runtime_t:s0
... which shouldn't be there, since:
/etc/.* -- system_u:object_r:etc_t:s0
... (which is and should be there) should cover it correctly.
This bug is in selinux-policy, against which I originally filed this report.
Then there's the bug where denyhosts *changes* the context to the incorrect value because of the way it updates the file.
I originally intended only the first bug. Although, of course, both should be addressed.
Given the above comment I'm not sure if this is really supposed to be my ticket, but I'll comment anyway.
The Fedora package of denyhosts includes code to call restorecon already, though it must be enabled by the user. See PLUGIN_PURGE in the installed configuration file. Of course, this still leaves a race and is in general a bit suboptimal.
I don't know if it is possible to call setfscreatecon() in python code. If there's an interface, I'll be happy to see if I can use it. My main concern is that things continue to work properly in the case that selinux is not being used.
I believe there is only one place in the denyhosts code which needs inspection. The normal mode of modifying hosts.deny is to open it in append mode, which I believe does not alter the context. Instead I think the only problem area is when denyhosts goes to purge old entries from the file, where it opens a temp file, copies the non-purged entries to it, and then renames the temp file over the original file. The relevant place in the code is in DenyHosts/denyfileutil.py line 167 (class Purge, function create_temp):
fp = open(self.temp_file, "w")
What would I sneak in here in order to get the context set properly? Just a shell out to restorecon, or is there a native python interface I can import ant call? What happens if selinux isn't enabled or configured if I call that?
Technically there are a couple of other places where hosts.deny might be overwritten in this manner, but they relate to updating from extremely old versions and shouldn't be relevant to the issue raised in this ticket.
It should work. I think this will work on a disabled machine, although I would never run one that way :^)
Might be saver to do
if selinux.is_selinux_enabeled() > 0:
As long as the temp_file is created under /etc, this should give it a label of etc_t which is what we want.
I have committed a patched package to rawhide CVS. I'm going to run this on a text box for a bit before pushing a build into rawhide, but if someone wants to try it, they'll find a scratch build at https://koji.fedoraproject.org/koji/taskinfo?taskID=1222388
However, I really don't know if it's going to actually help at all, because the temp file still isn't going to get etc_runtime_t context and so host.deny will still get the wrong context when the temp file is renamed over it. Or am I missing something?
The only race-free method I can see is to force a specific context on the created temp file, or perhaps to update the policy so that the temp file also gets etc_runtime_t context. I honestly don't know how to do either of those, but I'm happy to do additional hacking if I can get a hint.
I've cloned (end edited) this bug into Bug 488677 for the selinux-policy part.
I orginally intended this bug to be just an selinux-policy report. Since work has progressed against it for denyhosts, it probably makes sense to continue to use it to track the denyhosts work and to use Bug 488677 for the selinux-policy work.
I am changing the labeling of /etc/deny.hosts back to etc_t. So whey you create the tmp file it will be labeled etc_run_time_t (If it is created in etc_t directory). Restorecon will change it to etc_t.
Mv will maintain etc_t.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
I'm closing this report.
If anyone thinks the bug isn't fixed, let me know and I can reopen it (but not fix it, myself, of course).