Bug 240355
| Summary: | setroubleshoot gives bad suggestions | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Eric Paris <eparis> |
| Component: | setroubleshoot | Assignee: | John Dennis <jdennis> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.0 | CC: | jhutar |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHSA-2008-0061 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-05-21 14:25:38 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I thing this is same issue. Sealert advises me to do "restorecon -R -v /", but
I don't thing this is a good advise (setroubleshoot-1.8.11-4.el5.noarch):
Summary
SELinux is preventing the /usr/sbin/snmpd from using potentially mislabeled
files (/tmp).
Detailed Description
SELinux has denied /usr/sbin/snmpd access to potentially mislabeled file(s)
(/tmp). This means that SELinux will not allow /usr/sbin/snmpd to use these
files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is
that the files end up with the wrong file context which confined
applications are not allowed to access.
Allowing Access
If you want /usr/sbin/snmpd to access this files, you need to relabel them
using restorecon -v /tmp. You might want to relabel the entire directory
using restorecon -R -v /.
Additional Information
Source Context root:system_r:snmpd_t
Target Context system_u:object_r:tmp_t
Target Objects /tmp [ dir ]
Affected RPM Packages net-snmp-5.3.1-17.el5
[application]filesystem-2.4.0-1 [target]
Policy RPM selinux-policy-2.4.6-30.el5
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name plugins.home_tmp_bad_labels
Host Name wolverine.test.redhat.com
Platform Linux wolverine.test.redhat.com 2.6.18-8.el5xen #1
SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64
Alert Count 55
Line Numbers
Raw Audit Messages
avc: denied { getattr } for comm="snmpd" dev=hda2 egid=0 euid=0
exe="/usr/sbin/snmpd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="tmp"
path="/tmp" pid=22409 scontext=root:system_r:snmpd_t:s0 sgid=0
subj=root:system_r:snmpd_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:tmp_t:s0 tty=(none) uid=0
There are a few issues here we need to fix. 1) The plugs use a template variable TARGET_DIR, but this value may be incorrectly set in analyze.py at line 125 self.template_substitutions["TARGET_DIR"] = os.path.dirname(self.path) The problem is dirname() strips the last path component which is only correct if the path was not a directory to begin with. We need to test the path to see if it is a directory before calling dirname(). 2) If the path is insufficiently specified (see bug #244345) then these snipets from several plugins restorecon -v $TARGET_PATH entire directory using restorecon -R -v $TARGET_DIR will produce bogus instructions thusly: "restorecon -v $TARGET_PATH" will be incorrect if path was not a full path but derived via the "name" field. "entire directory using restorecon -R -v $TARGET_DIR" will be incorrect if the full path was not available -or- if TARGET_DIR was incorrect set because of the dirname() bug noted above. This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. should be fixed in setroubleshoot-2.0.2. The path handling code is now much more robust, we check for standard directory paths, if the tclass is 'file' we strip one component from the tpath, if the tclass is 'dir' we preserve the tpath, otherwise we return <Unknown> for TARGET_DIR. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0061.html |
SummarySELinux is preventing the /sbin/depmod from using potentially mislabeled files (tmp).Detailed DescriptionSELinux has denied /sbin/depmod access to potentially mislabeled file(s) (tmp). This means that SELinux will not allow /sbin/depmod to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access.Allowing AccessIf you want /sbin/depmod to access this files, you need to relabel them using restorecon -v tmp. You might want to relabel the entire directory using restorecon -R -v .Additional InformationSource Context: root:system_r:depmod_t:SystemLow-SystemHighTarget Context: system_u:object_r:tmp_tTarget Objects: tmp [ dir ]Affected RPM Packages: module-init-tools-3.3-0.pre3.1.16.el5 [application]filesystem-2.4.0-1 [target]Policy RPM: selinux-policy-2.4.6-30.el5Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: EnforcingPlugin Name: plugins.home_tmp_bad_labelsHost Name: aurora.lanl.govPlatform: Linux aurora.lanl.gov 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686Alert Count: 16Line Numbers: Raw Audit Messages :avc: denied { search } for comm="depmod" dev=hda2 egid=0 euid=0 exe="/sbin/depmod" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="tmp" pid=27137 scontext=root:system_r:depmod_t:s0-s0:c0.c1023 sgid=0 subj=root:system_r:depmod_t:s0-s0:c0.c1023 suid=0 tclass=dir tcontext=system_u:object_r:tmp_t:s0 tty=pts0 uid=0 Above is the cut and paste from an setroubleshoot message. The suggestion of running restorecon on /tmp is wrong. /tmp is already labeled tmp_t Is it possible for setroubleshoot to realize that /tmp was already labeled correctly and not give restorecon as a possible solution?