Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452410 - SE-PostgreSQL not built with SSL
Summary: SE-PostgreSQL not built with SSL
Alias: None
Product: Fedora
Classification: Fedora
Component: sepostgresql
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: KaiGai Kohei
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-22 10:01 UTC by Eric Desgranges
Modified: 2009-06-10 01:58 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-10 01:58:13 UTC

Attachments (Terms of Use)

Description Eric Desgranges 2008-06-22 10:01:49 UTC
Description of problem:
When enabling SSL in config file postgresql.conf I get the following error message:
LOG:  SSL is not supported by this build
FATAL:  invalid value for parameter "ssl": 1

Expected results:
I'm expecting SSL support for this version which is supposed to be more secure!

Comment 1 KaiGai Kohei 2008-06-25 02:19:43 UTC
I'm now verifying a package built "--with-ssl".

However, we have a matter to communicate between client and server applications 
(not only SE-PostgreSQL) over TCP/IP connection (not only SSL) in this version 
of Fedora.

SE-PostgreSQL invokes getpeercon() API of SELinux. It enables to obtain the 
security context of the peer process, so we can know what authority should
be applied on the server side.

When you communicate via UNIX domain socket (local connection), this API does
not require any additional configuration. However, when you communicate via
TCP/IP socket (remote connection), this API requires to set up Labeled IPsec
or static fallbacked context.

These features are included within kernel, ipsec-tools and netlabel_tools 
packages. But the selinux-polixy package does not support it enough.

Most of the current security policy covers only unlabeled packet come from
outside the system, so it reject to receive labeled packets.
We can include a hot fix policy within sepostgresql package, but it is not
a correct way. Are you harrying to this?

FYI: I reopened this issue in the SELinux community:

Comment 2 Eric Desgranges 2008-06-25 19:27:16 UTC
You gave me a good explanation about the issues related to communicating via
TCP/IP from a remote computer. I was thinking of using TCP/IP mainly for
replication (master-slave) purpose.

Comment 3 Eric Desgranges 2008-07-10 20:31:53 UTC
I put that problem on the side for some time... But I'm now back after trying a
couple of things:

-1- Use of stunnel but obviously it doesn't propagate the selinux security context

-2- Use of IPSec as described in the SE-PostgreSQL documentation, the only
difference is that I used public addresses instead of local IP addresses. But
I'm not too familiar with IPSec and the result was still negative as for the
propagation of the context.

I'm wondering if IPSec will work with public addresses, or there are any changes
to make to the configuration files...

Comment 4 KaiGai Kohei 2008-07-11 09:19:52 UTC
Could you point out the URL of the documentation?
Labeled Networking is one of the most rapid progressed component in SELinux,
so there is a possibility the description being already legacy.

And some questions here:
1. The communication channel go through one or more router?
   or, both machines are deployed within a same network?
2. Can you observe the metter, even if you run "setenforce 0"
   on both machniines?
3. Can you find anything from:
   grep ^type=AVC /var/log/audit/audit.log | grep association
4. What is the version of selinux-policy?

Now I'm making a clean environment of Fedora 9 to reproduce the IPsec matter.
Sorry, please wait for some days more.

And, preparing to update '--with-openssl' version package here:

NOTE: This package contains many backing port from 8.4devel tree.
It improves design refinement, simplification and fixes to avoid M$ patent
confliction, however, we have to run initdb again.

Comment 5 Eric Desgranges 2008-07-11 09:49:11 UTC
The document I was refering to is this one:

My setup is:
Computer 1 <-> Gateway 1 <-> Internet <-> Gateway 2 <-> Computer 2

The version of selinux-policy is 3.3.1.

A grep ^type=AVC /var/log/messages | grep association leads to an empty result. 

I guess my problem is I have no prior knowledge of IPSec, I'm not even sure to
test if a tunnel was set up (All the info I'm getting from Google involves
private addresses). Does the labeled IPSec setup suppose that openswan must be

Comment 6 KaiGai Kohei 2008-07-16 01:45:20 UTC
In my test environment, labeled IPsec works correctly.
(Fedora 9, selinux-policy-3.3.1, sepostgresql-8.3.3-2.952.fc9)

I want two more information.

1. Is there any firewall configuration to drop IPsec key exchanging packet?
   In the Fedora9 default, it is not available. And there is a possibility
   to be dropped by your gateway.

2. Do you tries to connect SE-PostgreSQL from unconfined_t domain?
   (It is the default domain of login shell. You can confirm it by "id -Z".)

In addition, "tcpdump" command enables you to confirm whether the communication 
is IPsec'ed, or not. The following article shows the usage:


Comment 7 Bug Zapper 2009-06-10 01:43:43 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here:

Comment 8 KaiGai Kohei 2009-06-10 01:58:13 UTC
We already added --with-openssl option on the current sepostgresql package, but I didn't close the entry yet...

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