Bug 585704 - setroubleshoot does not report SELinux violations
setroubleshoot does not report SELinux violations
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Walsh
Milos Malik
Depends On:
  Show dependency treegraph
Reported: 2010-04-25 13:54 EDT by Joshua Kramer
Modified: 2010-11-10 16:34 EST (History)
2 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-30.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-10 16:34:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joshua Kramer 2010-04-25 13:54:51 EDT
Description of problem:

While experimenting with an alternate configuration of Postgres, I cannot 'initdb' or 'start' the postgres service via /sbin/service.  This is a SELinux error because when I set SELinux to 'Permissive' mode, I can initdb and start successfully.  However, when it is set to 'Enforcing' and the postgres stat fails, I do not get any notification in the SELinux troubleshooter that there is a violation of policy.

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

RHEL x86_64 running in Sun VirtualBox 3.1.6 r59338




How reproducible:

I was experimenting with hosting PostgreSQL databases on an XFS filesystem.

Steps to Reproduce:

1. Under VirtualBox, create a 6.4 GB volume and attach it to the VM.  Boot the VM.

2. Once booted, create a partition on this drive and make the filesystem like this:
   mkfs -t xfs -f /dev/sdb1

3. Mount this filesystem as /opt

4. Under /opt, create a directory, pgdata.  Chown postgres:postgres pgdata.

5. chcon system_u:object_r:postgresql_db_t:s0 pgdata

6. Modify the file /etc/init.d/postgresql at approximately line 110 to change PGDATA to /opt/pgdata.

7. Modify the file /etc/init.d/postgresql at approximately line 250 to remove the call to 'restorecon' for $PGDATA.

8. Ensure that SELinux is in Enforcing mode via the GUI tool (System -> Administration -> SELinux Management).

9. Start the SETroubleshooter application via Applications -> System Tools -> SELinux Troubleshooter.

10. As root, run '/sbin/service postgresql initdb'

11. Note that it fails.

12. Put SELinux in Permissive mode using the GUI tool.

13. As root, run '/sbin/service postgresql initdb'.  Note that it runs OK.

14. Put SELinux in Enforcing mode using the GUI tool.

15. As root, run '/sbin/service postgresql start'.  Note that it fails.

16. Consult the file /var/lib/pgsql/pgstartup.log and see that there is a permission error reading /opt/pgdata/postgresql.conf.

17. Put SELinux in Permissive mode using the GUI tool.

18. As root, run '/sbin/service postgresql start'.  Note that it runs.

19. As root, run '/sbin/service postgresql stop'.

20. Put SELinux in Enforcing mode using the GUI tool.

21. As root, run:
    su -l postgres -c "/usr/bin/postmaster -p '5432' -D '/opt/pgdata'"

22. Note that postmaster is running, and you can connect to it using the psql command line tool.

23. Note that during this exercise the SELinux troubleshooter did not display any errors.

Actual results:

Note that during this exercise the SELinux troubleshooter did not display any errors.

Expected results:

I would expect that SELinux troubleshooter would provide information on why SELinux is denying access to /opt/pgdata/postgresql.conf when I run postgres from the init script.
Comment 2 RHEL Product and Program Management 2010-04-25 15:21:24 EDT
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
Comment 3 Joshua Kramer 2010-04-25 15:52:36 EDT
(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.
Comment 4 Daniel Walsh 2010-04-26 09:43:31 EDT
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
Comment 5 Joshua Kramer 2010-04-26 11:16:46 EDT
(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.
Comment 6 Joshua Kramer 2010-04-26 11:19:34 EDT
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.
Comment 7 Daniel Walsh 2010-04-26 11:42:02 EDT
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.
Comment 8 Joshua Kramer 2010-04-26 23:10:58 EDT
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
Comment 9 Daniel Walsh 2010-04-27 10:19:34 EDT
This means there is no label on the directory.

Run restorecon on the directory.

restorecon -R -v /opt.ext4
Comment 10 Joshua Kramer 2010-04-27 23:06:03 EDT
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?
Comment 11 Daniel Walsh 2010-06-18 09:54:26 EDT
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.


Miroslav the fix to remove dontaudit rules on daemons search directories, should fix this.
Comment 14 releng-rhel@redhat.com 2010-11-10 16:34:22 EST
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.

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