Bug 728025 - postgresql heartbeat resource can't be run by matahari with selinux on
Summary: postgresql heartbeat resource can't be run by matahari with selinux on
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Matahari
Classification: Retired
Component: matahari
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 0.6
Assignee: Perry Myers
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-04 00:33 UTC by Angus Salkeld
Modified: 2016-04-26 21:09 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-04 16:22:56 UTC


Attachments (Terms of Use)
audit2allow output (2.20 MB, text/plain)
2011-08-04 23:39 UTC, Angus Salkeld
no flags Details

Description Angus Salkeld 2011-08-04 00:33:11 UTC
Description of problem:
With selinux on matahari can not run the heartbeat/pgsql resource.

Note: when I turned selinux off all was well.

Version-Release number of selected component (if applicable):
I am testing on F14, but probably the same on f15+

How reproducible:
100%

Steps to Reproduce:
1.use the Resources->invoke() API to start pgsql
2.it will fail with selinux on
3.
  
Actual results:
PCMK [info] unpack_rsc_op: Hard error - rsc_a14-2_r_postgresql_start_0 failed with rc=4: Preventing rsc_a14-2_r_postgresql from re-starting on a14-2
PCMK [info] unpack_rsc_op: Processing failed op rsc_a14-2_r_postgresql_start_0 on a14-2: insufficient privileges (4)


Expected results:
success

Additional info:

Run from shell (not perfect but doing something)
--------------

[root@a14-2 heartbeat]# ./pgsql start
pgsql[28640]: INFO: I am root, id:uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; test -w /var/lib/pgsql/data
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; test -w /dev/null
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; /usr/bin/pg_ctl  -D /var/lib/pgsql/data -l /dev/null start
pgsql[28640]: INFO: server starting
pgsql[28640]: INFO: PostgreSQL start command sent.
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; kill -s 0 28693 >/dev/null 2>&1
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; /usr/bin/psql -p 5432 -U postgres template1 -c 'select now();'
pgsql[28640]: WARNING: psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
pgsql[28640]: WARNING: PostgreSQL template1 isn't running
pgsql[28640]: WARNING: Connection error (connection to the server went bad and the session was not interactive) occurred while executing the psql command.
pgsql[28640]: DEBUG: PostgreSQL still hasn't started yet. Waiting...
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; kill -s 0 28693 >/dev/null 2>&1
pgsql[28640]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; /usr/bin/psql -p 5432 -U postgres template1 -c 'select now();'
pgsql[28640]: INFO: PostgreSQL is started.

Run from matahari
-----------------
Aug  3 20:12:29 a14-2 service[1448]: virtual gboolean SrvAgent::invoke(qmf::AgentSession, qmf::AgentEvent, void*): Calling resources API
Aug  3 20:12:29 a14-2 pgsql[28547]: INFO: I am root, id:uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:matahari_serviced_t:s0
Aug  3 20:12:29 a14-2 pgsql[28547]: INFO: ocf_run su postgres -c cd /var/lib/pgsql/data; test -w /var/lib/pgsql/data
Aug  3 20:12:29 a14-2 pgsql[28547]: INFO: Password: su: incorrect password
Aug  3 20:12:29 a14-2 pgsql[28547]: ERROR: Directory /var/lib/pgsql/data is not writable by postgres


This might make sense to you?

type=USER_START msg=audit(1312417818.621:2087): user pid=30413 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:matahari_serviced_t:s0 msg='op=PAM:session_open acct="postgres" exe="/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_ACQ msg=audit(1312417818.621:2088): user pid=30413 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:matahari_serviced_t:s0 msg='op=PAM:setcred acct="postgres" exe="/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_DISP msg=audit(1312417818.624:2089): user pid=30413 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:matahari_serviced_t:s0 msg='op=PAM:setcred acct="postgres" exe="/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_END msg=audit(1312417818.624:2090): user pid=30413 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:matahari_serviced_t:s0 msg='op=PAM:session_close acct="postgres" exe="/bin/su" hostname=? addr=? terminal=? res=success'

Comment 1 Andrew Beekhof 2011-08-04 01:19:02 UTC
Adam, you're our resident selinux expert - could you take a look please?

Comment 2 Adam Stokes 2011-08-04 20:30:06 UTC
Angus,

Could you see if the following gives you a better indication of the problem?

cat /var/log/audit/audit.log | audit2allow -w

Thanks,
Adam

Comment 3 Angus Salkeld 2011-08-04 23:37:07 UTC
(In reply to comment #2)
> Angus,
> 
> Could you see if the following gives you a better indication of the problem?
> 
> cat /var/log/audit/audit.log | audit2allow -w
> 
> Thanks,
> Adam

These below look the most obvious, but there are heaps so I will attach the file.


type=AVC msg=audit(1312374486.979:175): avc:  denied  { open } for  pid=1667 comm="pgsql" name="su" dev=dm-1 ino=130125 scontext=system_u:system_r:matahari_serviced_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1312374486.979:175): avc:  denied  { execute_no_trans } for  pid=1667 comm="pgsql" path="/bin/su" dev=dm-1 ino=130125 scontext=system_u:system_r:matahari_serviced_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file

	Was caused by:
		Missing type enforcement (TE) allow rule.

		You can use audit2allow to generate a loadable module to allow this access.

Comment 4 Angus Salkeld 2011-08-04 23:39:05 UTC
Created attachment 516801 [details]
audit2allow output

Comment 5 Adam Stokes 2011-08-15 16:27:05 UTC
Dan,

It looks like matahari service isn't giving enough access to all these operations reported in the audit2allow output?

Seeing as how matahari-service would actually need basically ulimited execution power I dont really know the best way to approach this issue.

Thanks
Adam

Comment 6 Daniel Walsh 2011-08-16 11:54:54 UTC
The AVC's you are reporting are file_t which means no labels are present.  Usually this means you added a disk that does not have labels on it.  Running restorecon on the disk will fix the labels.

The other avc's in the bug report indicate that matahari_serviced is not transitioning domains to their proper context.  If matahari_serviced is supposed to start and stop all services, we have to write that policy.

Adding the following policy might fix that problem.

# ====================  mymatahari.te ==========================================
policy_module(mymatahari, 1.0)
gen_require(`
type matahari_serviced_t;
')

init_spec_domtrans_script(matahari_serviced_t)
#===============================================================================

make -f /usr/share/selinux/devel/Makefile
# semodule -i mymatahari.pp

Comment 7 Adam Stokes 2011-08-16 12:45:34 UTC
Angus,

Will you test comment #6 and see if the problem persists? If so, make sure to get another audit2allow report.

Thanks,
Adam

Comment 8 Andrew Beekhof 2011-08-18 22:22:07 UTC
Dan,

Not sure audit2allow is the right thing to do here.

matahari-qmf-serviced could conceivably need to run any script in /etc/init.d which in turn could need to run any binary on the system, it would be analogous to trying to come up with a policy for /sbin/init.

Is there any way to run this daemon unconstrained?  I can't think of any other path forward that makes sense.

Comment 9 Daniel Walsh 2011-08-20 10:59:12 UTC
init_spec_domtrans_script(matahari_serviced_t)

Will allow it to run any script within the init directory but more important then running matahari-qmf-serviced as an unconfined domain is to make sure that all confined applications continue to be confined after marahari restarts them.

For example if matahari-qmf-serviced was to restart apache we want the apache to be running as httpd_t not matahari_serviced_t.


selinux-policy-3.10.0-18.fc16

Will have the policy described above.

Comment 10 Miroslav Grepl 2011-08-22 11:19:33 UTC
I am adding it to RHEL6/F15/F14

Comment 11 Adam Stokes 2011-08-30 18:28:13 UTC
Angus,

Can you test the latest selinux-policy to see if the problem persists?

Thanks,
Adam

Comment 12 Steven Dake 2011-10-27 23:26:23 UTC
-18 appears broken just as -46 and -52 does.

Comment 13 Daniel Walsh 2011-10-28 13:35:51 UTC
This seems to be a duplicate of 749682

Comment 14 Perry Myers 2011-11-09 16:33:39 UTC
Angus, can you retest with the selinux policy package that is listed in: https://bugzilla.redhat.com/show_bug.cgi?id=749682#c9 as dwalsh thinks that this new selinux package should fix the issue

Comment 16 Perry Myers 2012-01-04 16:22:56 UTC
Closing since Angus hasn't complained about this in nearly two months.  Angus, please reopen if you're still having issues.


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