Bug 149237

Summary: selinux <<EOF bug breaks PostgreSQL too
Product: [Fedora] Fedora Reporter: Tom Lane <tgl>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: ajsfedora, hhorak, mkanat, sdsmall, zing
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-19 17:21:54 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 Tom Lane 2005-02-21 16:07:06 UTC 
Description of problem:
PostgreSQL database initialization fails silently when selinux is in
enforcement mode.  The problem is that the initdb script uses this
construct in several places:
	postgres <<EOF
	  ... sql commands ...
	EOF
and selinux denies permission to read the here-document.  This results
in large chunks of needed functionality not being installed.  An easy
check that it's broken is
$ su postgres
$ psql -l
ERROR:  relation "pg_catalog.pg_user" does not exist


Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.17.30-2.80
postgresql-server-7.4.7-1.FC3.2

How reproducible:
100%

Steps to Reproduce:
1.  service postgresql stop (if running)
2.  rm -rf /var/lib/pgsql/data
3.  service postgresql start
4.  psql -l

Actual results:


Expected results:


Additional info:
This is the same issue that broke mysql (bug #141062) --- I'm
surprised it hasn't been reported against postgres earlier.  I know I
can work around it by hacking the script, but I remain convinced that
I should not have to.  There is nothing inherently insecure about a
here-document; the fact that I can't use one is either a selinux
policy bug or a bash bug.  I think we are going to keep seeing more
and more of this sort of gripe until something is done about it in the
policy or in bash.
Comment 1 Daniel Walsh 2005-02-28 14:54:35 UTC 
Well there is not much that can be done by SELinux.  Since this is fundamentally
an information from from one one security context to another via a file.  Now we
can give the postgress/mysql access to tmp files created by root in order to
make this work, but this significantly lowers the security level of the
programs,  Since if later on a tmp file is created, a hacked mysql/postgres
could read it.  By changing it to a 
cat /tmp/XYZ | postgres  type app, we are only handing a file descriptor, to the
newly created application which is a lot smaller information flow.  If bash was
changed to open the file and hand the descriptor that would solve the SELinux
problem also.
Comment 2 Tom Lane 2005-02-28 20:38:32 UTC 
Perhaps I am missing something, but it seems to me that this can be fixed
trivially as long as SELinux can distinguish opening a file from reading/writing
a descriptor that is already open.  Just allow daemons to read/write files in
/tmp only when the descriptor was handed to them already open.

BTW, I would like to see the same behavior apply to /dev/tty.  The current
restriction that daemon programs cannot write on /dev/tty means that interactive
error messages from postgres are suppressed, which is VERY user unfriendly, and
completely unhelpful from a security standpoint too.

As far as your last comment goes, doesn't bash already hand the thing as an
opened file descriptor?
Comment 3 Tom Lane 2005-03-30 18:15:21 UTC 
*** Bug 152591 has been marked as a duplicate of this bug. ***
Comment 4 Stephen Smalley 2005-03-31 16:02:27 UTC 
Dan asked me to comment on this bug, with the question of:
Is there a way to distinguish between having the ability to open a file versus
having the file discriptor handed to you by a parent?  IE Is there a way we
could add an open access type?

My answer is below:
Only by a change to the SELinux module code.  At present, we apply the
same set of permission checks for file open, inheriting a descriptor
upon execve, and transfer of a descriptor via local IPC.  That is
consistent with our goals for MAC, i.e. the ability to consistently
control the ability of a process to access an object no matter how
access is gained.  Otherwise, you don't truly have any confinement
guarantees; a process can leak a descriptor at will (or by mistake, as
happens all too often) to a process that shouldn't have access.  We
could change the SELinux module code to apply some kind of distinct
permission checks upon open vs. inherit/transfer, but that means
defining new permissions (and these would be needed for all file
classes, and can't modify common file set without compatibility issues),
modifying the kernel module code, gettting it all upstreamed, tracking
down all the policy changes that are needed, ...  Not worth it IMHO.
Comment 5 Tom Lane 2005-04-19 17:21:54 UTC 
Well, I've worked around the problem in PostgreSQL, and it looks like we can't
have a more general solution :-(
Comment 6 Josh Bressers 2005-06-01 13:24:09 UTC 
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-2005-433.html