Bug 585704
Summary: | setroubleshoot does not report SELinux violations | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Joshua Kramer <jkramer> |
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Milos Malik <mmalik> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 6.0 | CC: | mmalik, syeghiay |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | selinux-policy-3.7.19-30.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-11-10 21:34:22 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: |
Description
Joshua Kramer
2010-04-25 17:54:51 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion. (In reply to comment #2) > This request was evaluated by Red Hat Product Management for inclusion in a Red > Hat Enterprise Linux major release. Product Management has requested further > .... Can you please explain this statement? All of the components listed in this ticket are supported in RHEL 6 - at this time, none of the components are a "technology preview" or otherwise marketed as not being supported. This ticket references a possible problem with these supported components - it is not a request to add more components to RHEL6 or a future release. That is a cookie cutter message that basically says, reporting a bug does not guarantee it will be fixed. Lets look at what is breaking in postgresql. Collect the avc's after a restart in enforcing mode ausearch -m avc -ts recent Then attach them here. Also can you get the latest rhel6 setroubleshooter latestrhel6 setroubleshoot Build Tag Built by ---------------------------------------- -------------------- ---------------- setroubleshoot-2.2.72-1.el6 RHEL-6-candidate dwalsh (In reply to comment #4) > Collect the avc's after a restart in enforcing mode > ausearch -m avc -ts recent The AVC's do not appear to be generated: [root@RHEL6-64 ~]# /sbin/service postgresql start Starting postgresql service: [FAILED] [root@RHEL6-64 ~]# ausearch -m avc -ts recent <no matches> [root@RHEL6-64 ~]# > Also can you get the latest rhel6 setroubleshooter > setroubleshoot-2.2.72-1.el6 RHEL-6-candidate dwalsh Is there a publicly-accessible place from which I can get this version of the package? The current FTP server has the old 2.2.52 versions under x86_64 and sources. I believe this may be related to one of two things: 1. XFS, or 2. The fact that I am working with an alternate filesystem. To test this theory, I created a new directory under / named /opt.pg; I then created a directory /opt.pg/pgdata and configured it exactly as noted above with regards to owner and chcon. Finally, I modified /etc/init.d/postgresql script to point PG_HOME to /opt.pg/pgdata. Postgres runs initdb and starts fine under this configuration. I will make an ext4 filesystem, and mount it under /opt.ext4 and repeat the exercise to see if Postgres still runs under that condition. Well xfs should work. Since you are getting no AVC's on the xfs one, please try # semodule -DB # /sbin/service postgresql start # ausearch -m avc -ts recent And see if there is anything. This is interesting. I attempted this same exercise, except formatted the partition as ext4 and mounted it under /opt.ext4. I then repeated the steps creating pgdata, chown and chcon, etc. under the new /opt.ext4/pgdata directory. I get the same error with ext4 as I got with xfs. I did finally get an AVC denial message: time->Mon Apr 26 22:34:48 2010 type=SYSCALL msg=audit(1272335688.560:216): arch=c000003e syscall=4 success=yes exit=128 a0=1c07b30 a1=7fff50d92410 a2=7fff50d92410 a3=666e6f632e6c7173 items=0 ppid=1 pid=5251 auid=500 uid=26 gid=26 euid=26 suid=26 fsuid=26 egid=26 sgid=26 fsgid=26 tty=(none) ses=4 comm="postmaster" exe="/usr/bin/postgres" subj=unconfined_u:system_r:postgresql_t:s0 key=(null) type=AVC msg=audit(1272335688.560:216): avc: denied { search } for pid=5251 comm="postmaster" name="/" dev=sdc1 ino=2 scontext=unconfined_u:system_r:postgresql_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir This means there is no label on the directory. Run restorecon on the directory. restorecon -R -v /opt.ext4 After running restorecon, I was able to initdb and run postgres in both the XFS and ext4 mount points. The question remains, however - why does selinuxtroubleshooter report some AVC denials and not others? SELinux has the concept of dontaudit rules. For many apps this is appropriate. An app will try to access a file one way and then when it gets permission denied it will go another path. For example login programs try to read /etc/shadow, when they get denied the execute unix_chkpwd which can read /etc/shadow. If selinux reported everytime a login attempted to read /etc/shadow, it would flood the logs. Not sure which dontaudit rule caused your checks to fail. But I think if you try the next selinux-policy your problem might be fixed. selinux-policy-3.7.19-30 Miroslav the fix to remove dontaudit rules on daemons search directories, should fix this. Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you. |