SELinux won't let dovecot connect to postgresql

[Roland Roberts]

I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs 
installed.  I have a small user database set up for email authentication. 

The issue I'm having is that when I am in enforcing mode, dovecot can't 
connect to the database.  Turning off enforcing mode lets it work.  I'm 
having trouble diagnosing where the denial is taking place as I don't 
see any avc messages in /var/log/messages that relate to dovecot.  The 
only messages I'm getting are in /var/log/maillog from dovecot like this:

Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to 
maildb: could not connect to server: Permission denied
Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running 
on host "fred.flinstone.org" and accepting
Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on 
port 5432?

The answer to the questions is "yes" it is running and accepting 
connections.  Whether or not enforcing mode is on, when logged in, I can 
connect to the database via

$ psql -h fred.flinstone.org maildb

I *think* this is a result of updating on Nov 18.  I have not changed 
the default selinux mode since the host was set up back in September.  
At that point, I set it to enforcing mode after working out a few 
issues.  On Nov 18, a lot of things were updated, but among there were

Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch
Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64
Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64
Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64
Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch
Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch

Today, I did another update, hoping it would cure the problem and got 
these revisions

Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch
Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch

but the behavior is unchanged, I still have to turn off enforcing mode.

Any clues on what I need to do to get this to work?  Or where to look 
for clues since, as I mentioned, I can't even find log entries that 
would clue me in.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Justin P. Mattock]

On 11/28/09 20:35, Roland Roberts wrote:
>  I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql
> RPMs
>  installed. I have a small user database set up for email authentication.
>  The issue I'm having is that when I am in enforcing mode, dovecot can't
>  connect to the database. Turning off enforcing mode lets it work. I'm
>  having trouble diagnosing where the denial is taking place as I don't
>  see any avc messages in /var/log/messages that relate to dovecot. The
>  only messages I'm getting are in /var/log/maillog from dovecot like this:
>
>  Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to
>  maildb: could not connect to server: Permission denied
>  Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running
>  on host "fred.flinstone.org" and accepting
>  Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on
>  port 5432?
>
>  The answer to the questions is "yes" it is running and accepting
>  connections. Whether or not enforcing mode is on, when logged in, I can
>  connect to the database via
>
>  $ psql -h fred.flinstone.org maildb
>
>  I *think* this is a result of updating on Nov 18. I have not changed the
>  default selinux mode since the host was set up back in September. At
>  that point, I set it to enforcing mode after working out a few issues.
>  On Nov 18, a lot of things were updated, but among there were
>
>  Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch
>  Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch
>  Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch
>
>  Today, I did another update, hoping it would cure the problem and got
>  these revisions
>
>  Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch
>  Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch
>
>  but the behavior is unchanged, I still have to turn off enforcing mode.
>
>  Any clues on what I need to do to get this to work? Or where to look for
>  clues since, as I mentioned, I can't even find log entries that would
>  clue me in.
>
>  roland
>  
Maybe you just need to either
make enableaudit or check the file
labels to make sure things are legit,

Justin P. Mattock

[Thomas Harold]

On 11/28/2009 11:35 PM, Roland Roberts wrote:
>  I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql
> RPMs
>  installed. I have a small user database set up for email
>  authentication. The issue I'm having is that when I am in enforcing
>  mode, dovecot can't connect to the database. Turning off enforcing
>  mode lets it work. I'm having trouble diagnosing where the denial is
>  taking place as I don't see any avc messages in /var/log/messages
>  that relate to dovecot. The only messages I'm getting are in
>  /var/log/maillog from dovecot like this 
I think that you have to have the setroubleshoot service running in 
order to get SELinux errors in /var/log/messages.

https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ

>  Any clues on what I need to do to get this to work? Or where to look
>  for clues since, as I mentioned, I can't even find log entries that
>  would clue me in. 
First step is to look in /var/log/messages for "sealert" lines (assuming 
that the setroubleshoot service is running).  The meat of the details of 
the denial will be in /var/log/audit/audit.log.

# egrep "(dovecot|postgres)" /var/log/audit/audit* | audit2allow

It'll probably spit out something like:

allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect;

Depending on what database server you are running, of course.

You'll want to set your system to "permissive" and let SELinux gather 
messages in the audit.log.  Then you can run audit2allow once, check its 
suggestions, and then create and apply a new policy.

[Roland Roberts]

Thomas Harold wrote:
>  I think that you have to have the setroubleshoot service running in 
>  order to get SELinux errors in /var/log/messages.
>
>  https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ 
Hmmm, I seem to have both setroubleshoot and setroubleshoot-server 
packages installed, but much of that package talks about turning on the 
setroubleshoot service; the file for that should be in 
/etc/rc.d/init.d/setroubleshoot, but I have no such file.  Both packages 
verify as correct (rpm -V) and rpm -qil does not show any such file in 
the inventory.  There is a file /usr/sbin/setroubleshootd which is what 
I would expect for the daemon, but no file in /etc/rc.d/init.d 
references it.  Odd.  And if I try to manually launch it, it runs 
briefly, leaves a zero-length log file in 
/var/log/setroubleshoot/setroubleshootd.log.

Note that I am *not* on a X11 desktop on this host.  It is a server, and 
while it has X installed, it is in run level 3.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Thomas Harold]

On 11/29/2009 12:29 AM, Roland Roberts wrote:
>  Hmmm, I seem to have both setroubleshoot and setroubleshoot-server
>  packages installed, but much of that package talks about turning on the
>  setroubleshoot service; the file for that should be in
>  /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages
>  verify as correct (rpm -V) and rpm -qil does not show any such file in
>  the inventory. There is a file /usr/sbin/setroubleshootd which is what I
>  would expect for the daemon, but no file in /etc/rc.d/init.d references
>  it. Odd. And if I try to manually launch it, it runs briefly, leaves a
>  zero-length log file in /var/log/setroubleshoot/setroubleshootd.log. 
You could try uninstalling and then reinstalling the setroubleshoot 
package.  Specifically "setroubleshoot-server" package contains the 
daemon and init.d file and only depends on the -plugins package.

Even on our servers, the setroubleshoot.log file is generally empty. 
I'm guessing that you'll only see content there if the daemon fails to 
initialize or has errors.

[Roland Roberts]

Thomas Harold wrote:
>  You could try uninstalling and then reinstalling the setroubleshoot 
>  package.  Specifically "setroubleshoot-server" package contains the 
>  daemon and init.d file and only depends on the -plugins package. 
But it doesn't seem to include the init.d file, or is rpm -qil not 
telling me what I think it is telling me:

572 root> rpm -qil setroubleshoot-server | grep /etc
/etc/audisp/plugins.d/sedispatch.conf
/etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf
/etc/logrotate.d/setroubleshoot
/etc/setroubleshoot
/etc/setroubleshoot/setroubleshoot.cfg

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Roland Roberts]

Roland Roberts wrote:
>  Thomas Harold wrote:
> > You could try uninstalling and then reinstalling the setroubleshoot 
> > package.  Specifically "setroubleshoot-server" package contains the 
> > daemon and init.d file and only depends on the -plugins package. 
Oo-oo.  I just discovered something *very* interesting.  When I first 
set up this host, I set it up in parallel with the existing host it was 
replacing and it had a different host name. I find, in 
/var/lib/setroubleshoot/audit_listener_database.xml, the old host name.  
Perhaps that's why I'm not getting my messages.  I'm going to try 
correcting the host name there.  I'm not sure if I *need* to reboot, but 
I'm not sure what processes will need to be restarted if I don't.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Roland Roberts]

Roland Roberts wrote:
>  Roland Roberts wrote:
> > Thomas Harold wrote:
> >> You could try uninstalling and then reinstalling the setroubleshoot 
> >> package.  Specifically "setroubleshoot-server" package contains the 
> >> daemon and init.d file and only depends on the -plugins package.
>
>  Oo-oo.  I just discovered something *very* interesting.  When I first 
>  set up this host, I set it up in parallel with the existing host it 
>  was replacing and it had a different host name. I find, in 
>  /var/lib/setroubleshoot/audit_listener_database.xml, the old host 
>  name.  Perhaps that's why I'm not getting my messages.  I'm going to 
>  try correcting the host name there.  I'm not sure if I *need* to 
>  reboot, but I'm not sure what processes will need to be restarted if I 
>  don't. 
Well, that by itself is not sufficient.  But perhaps these two lines in 
syslog are a clue if only I could decipher them:

dbus: avc:  received setenforce notice (enforcing=0)
tycho dbus: Can't send to audit system: USER_AVC avc:  received 
setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?, 
addr=?, terminal=?)

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Justin P. Mattock]

On 11/28/09 22:05, Roland Roberts wrote:
>  Roland Roberts wrote:
> > Roland Roberts wrote:
> >> Thomas Harold wrote:
> >>> You could try uninstalling and then reinstalling the setroubleshoot
> >>> package. Specifically "setroubleshoot-server" package contains the
> >>> daemon and init.d file and only depends on the -plugins package.
> >
> > Oo-oo. I just discovered something *very* interesting. When I first
> > set up this host, I set it up in parallel with the existing host it
> > was replacing and it had a different host name. I find, in
> > /var/lib/setroubleshoot/audit_listener_database.xml, the old host
> > name. Perhaps that's why I'm not getting my messages. I'm going to try
> > correcting the host name there. I'm not sure if I *need* to reboot,
> > but I'm not sure what processes will need to be restarted if I don't.
>
>  Well, that by itself is not sufficient. But perhaps these two lines in
>  syslog are a clue if only I could decipher them:
>
>  dbus: avc: received setenforce notice (enforcing=0)
>  tycho dbus: Can't send to audit system: USER_AVC avc: received
>  setenforce notice (enforcing=0)#012: exe="?" (sauid=81, hostname=?,
>  addr=?, terminal=?)
>
>  roland
>  
why is dbus sending a setenforce=0 call?

Justin P. Mattock

[Thomas Harold]

On 11/29/2009 12:49 AM, Roland Roberts wrote:
>  Thomas Harold wrote:
> > You could try uninstalling and then reinstalling the setroubleshoot
> > package. Specifically "setroubleshoot-server" package contains the
> > daemon and init.d file and only depends on the -plugins package.
>
>  But it doesn't seem to include the init.d file, or is rpm -qil not
>  telling me what I think it is telling me:
>
>  572 root> rpm -qil setroubleshoot-server | grep /etc
>  /etc/audisp/plugins.d/sedispatch.conf
>  /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf
>  /etc/logrotate.d/setroubleshoot
>  /etc/setroubleshoot
>  /etc/setroubleshoot/setroubleshoot.cfg
>  
Not sure, that's sounding more like a Fedora issue then an SELinux issue 
(and I'm not running Fedora, I'm running RHEL/CentOS).  But a bit of 
google-fu turned up:

http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html

(the linked message was posted by Daniel J Walsh)

Basically, they've restructured things back in June 2009.  So you'll 
probably have to go digging in the audit.log file for the AVC messages.

# grep "AVC" /var/log/audit/audit.log

[Roland Roberts]

Thomas Harold wrote:
>  On 11/29/2009 12:49 AM, Roland Roberts wrote:
> > But it doesn't seem to include the init.d file, or is rpm -qil not
> > telling me what I think it is telling me:
> >
> > 572 root> rpm -qil setroubleshoot-server | grep /etc
> > /etc/audisp/plugins.d/sedispatch.conf
> > /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf
> > /etc/logrotate.d/setroubleshoot
> > /etc/setroubleshoot
> > /etc/setroubleshoot/setroubleshoot.cfg
> >
>
>  Not sure, that's sounding more like a Fedora issue then an SELinux 
>  issue (and I'm not running Fedora, I'm running RHEL/CentOS).  But a 
>  bit of google-fu turned up:
>
>  http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html
>
>  (the linked message was posted by Daniel J Walsh)
>
>  Basically, they've restructured things back in June 2009.  So you'll 
>  probably have to go digging in the audit.log file for the AVC messages.
>
>  # grep "AVC" /var/log/audit/audit.log 
Thanks.  Maybe I'll file a report with bugzilla.  Not sure that my 
missing messages are a bug, but there is nothing in 
/var/log/audit/audit.log with "avc".  In any event, it's past my bedtime 
here for today

g'nite.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[David P. Quigley]

On Sun, 2009-11-29 at 01:11 -0500, Roland Roberts wrote:
>  Thomas Harold wrote:
>  > On 11/29/2009 12:49 AM, Roland Roberts wrote:
>  >> But it doesn't seem to include the init.d file, or is rpm -qil not
>  >> telling me what I think it is telling me:
>  >>
>  >> 572 root> rpm -qil setroubleshoot-server | grep /etc
>  >> /etc/audisp/plugins.d/sedispatch.conf
>  >> /etc/dbus-1/system.d/org.fedoraproject.Setroubleshootd.conf
>  >> /etc/logrotate.d/setroubleshoot
>  >> /etc/setroubleshoot
>  >> /etc/setroubleshoot/setroubleshoot.cfg
>  >>
>  >
>  > Not sure, that's sounding more like a Fedora issue then an SELinux 
>  > issue (and I'm not running Fedora, I'm running RHEL/CentOS).  But a 
>  > bit of google-fu turned up:
>  >
>  > http://osdir.com/ml/fedora-selinux/2009-06/msg00053.html
>  >
>  > (the linked message was posted by Daniel J Walsh)
>  >
>  > Basically, they've restructured things back in June 2009.  So you'll 
>  > probably have to go digging in the audit.log file for the AVC messages.
>  >
>  > # grep "AVC" /var/log/audit/audit.log
>  
>  Thanks.  Maybe I'll file a report with bugzilla.  Not sure that my 
>  missing messages are a bug, but there is nothing in 
>  /var/log/audit/audit.log with "avc".  In any event, it's past my bedtime 
>  here for today
>  
>  g'nite.
>  
>  roland
>   
Just as a bit of advice for the future. You are better off using the
ausearch command to find denials. You can narrow it down to just AVC
denials by using ausearch -m AVC. After that you can restrict based on
time using some of the other flags for the utility.

Dave

[Sandro Janke]

On 11/29/2009 06:29 AM, Roland Roberts wrote:
>  Thomas Harold wrote:
> > I think that you have to have the setroubleshoot service running in
> > order to get SELinux errors in /var/log/messages.
> >
> > https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ
>
>  Hmmm, I seem to have both setroubleshoot and setroubleshoot-server
>  packages installed, but much of that package talks about turning on the
>  setroubleshoot service; the file for that should be in
>  /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages
>  verify as correct (rpm -V) and rpm -qil does not show any such file in
>  the inventory. There is a file /usr/sbin/setroubleshootd which is what I
>  would expect for the daemon, but no file in /etc/rc.d/init.d references
>  it. Odd. And if I try to manually launch it, it runs briefly, leaves a
>  zero-length log file in /var/log/setroubleshoot/setroubleshootd.log.
>
>  Note that I am *not* on a X11 desktop on this host. It is a server, and
>  while it has X installed, it is in run level 3. 
Actually, you don't need to have any of the setroubleshoot packages 
installed to get AVC messages logged. What you need is auditd running 
and it will log AVC messages to /var/log/audit/audit.log

With setroubleshoot-server installed you can watch the logged messages 
using:

# sealert -a /var/log/audit/audit.log

The output will be long and in the style of setroubleshoot browser, so 
take your measures.

Another tool - from the audit package - that can prove very useful is 
ausearch. It will search the audit logs for messages matching the given 
criteria.

[Justin P. Mattock]

On 11/29/09 02:11, Sandro Janke wrote:
>  On 11/29/2009 06:29 AM, Roland Roberts wrote:
> > Thomas Harold wrote:
> >> I think that you have to have the setroubleshoot service running in
> >> order to get SELinux errors in /var/log/messages.
> >>
> >> https://fedorahosted.org/setroubleshoot/wiki/SETroubleShoot%20User%20FAQ
> >
> > Hmmm, I seem to have both setroubleshoot and setroubleshoot-server
> > packages installed, but much of that package talks about turning on the
> > setroubleshoot service; the file for that should be in
> > /etc/rc.d/init.d/setroubleshoot, but I have no such file. Both packages
> > verify as correct (rpm -V) and rpm -qil does not show any such file in
> > the inventory. There is a file /usr/sbin/setroubleshootd which is what I
> > would expect for the daemon, but no file in /etc/rc.d/init.d references
> > it. Odd. And if I try to manually launch it, it runs briefly, leaves a
> > zero-length log file in /var/log/setroubleshoot/setroubleshootd.log.
> >
> > Note that I am *not* on a X11 desktop on this host. It is a server, and
> > while it has X installed, it is in run level 3.
>
>  Actually, you don't need to have any of the setroubleshoot packages
>  installed to get AVC messages logged. What you need is auditd running
>  and it will log AVC messages to /var/log/audit/audit.log
>
>  With setroubleshoot-server installed you can watch the logged messages
>  using:
>
>  # sealert -a /var/log/audit/audit.log
>
>  The output will be long and in the style of setroubleshoot browser, so
>  take your measures.
>
>  Another tool - from the audit package - that can prove very useful is
>  ausearch. It will search the audit logs for messages matching the given
>  criteria.
>
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
agree..
In my case I normaly just do:
audit2allow -d > to_the_allow_rules
audit2allow -i /var/log/*(and the rest of
the log messages havng any left over avc's
to define into the policy);

Justin P. Mattock

[Roland Roberts]

On 11/29/2009 05:18 AM, Justin P. Mattock wrote:
>  In my case I normaly just do:
>  audit2allow -d > to_the_allow_rules
>  audit2allow -i /var/log/*(and the rest of
>  the log messages havng any left over avc's
>  to define into the policy); 
Guys, you're driving me crazy :-/  I can't *find* a log entry to fix.  
There's nothing where it's supposed to be.  So...if you agree that that 
looks like a bug, I'll just go on and file a bug.  Otherwise I'm really 
stuck.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Eric Paris]

On Sun, 2009-11-29 at 20:46 -0500, Roland Roberts wrote:
>  On 11/29/2009 05:18 AM, Justin P. Mattock wrote:
>  > In my case I normaly just do:
>  > audit2allow -d > to_the_allow_rules
>  > audit2allow -i /var/log/*(and the rest of
>  > the log messages havng any left over avc's
>  > to define into the policy);
>  
>  Guys, you're driving me crazy :-/  I can't *find* a log entry to fix.  
>  There's nothing where it's supposed to be.  So...if you agree that that 
>  looks like a bug, I'll just go on and file a bug.  Otherwise I'm really 
>  stuck. 
I see that my F12 policy has a rule that allows dovecot_t to talk to
postgresql_port_t.  Not certain if it is controlled by a boolean which
is toggled wrong on your system or if you are having some other problem,
so lets start by seeing the actual avc denial.

AVCs can end up either in /var/log/messages or /var/log/audit/audit.log
(depending on the system setup.) Also in permissive move denials are
only logged one time.  So you won't see a denial every time it ~would~
have triggered.  To flush the selinux cache I typically suggest you set
the system enforcing and back permissive quickly.  So lets do these
steps.

setenforce 1
setenforce 0
reproduce problem (or what would be a problem)
grep -i avc /var/log/messages
grep -i avc /var/log/audit/audit.log

If both of those come up blank you likely are hitting a problem that is
being 'dontaudit'  I believe you said F11 (if not and it is old enough
to not understand semodule -DB let me know as there are other ways to do
this on older systems)?  If so do these steps

semodule -DB
setenforce 1
setenforce 0
reproduce problem (or what would be a problem)
grep -i avc /var/log/messages /var/log/audit/audit.log
semodule -B

Let us know the output this time.  Hopefully we can get to the bottom of
this.

-Eric

[Justin P. Mattock]

On 11/29/09 17:46, Roland Roberts wrote:
>  On 11/29/2009 05:18 AM, Justin P. Mattock wrote:
> > In my case I normaly just do:
> > audit2allow -d > to_the_allow_rules
> > audit2allow -i /var/log/*(and the rest of
> > the log messages havng any left over avc's
> > to define into the policy);
>
>  Guys, you're driving me crazy :-/ I can't *find* a log entry to fix.
>  There's nothing where it's supposed to be. So...if you agree that that
>  looks like a bug, I'll just go on and file a bug. Otherwise I'm really
>  stuck.
>
>  roland
>  
What you might try is
in the source tree of the policy
(/usr/share/selinux/*)
do a
make clean
make enableaudit
make policy
make install
make load(reboot)
then you should be able to see some
avc's in /var/log/messages,audit.log.

keep in mind if this is the targeted policy
you might have to download the source for that policy
then(depending on binary/monolithic) build
your module for that policy(semodule) once you've
collected the extra dontaudit avc's(/var/log/*) that's probably
preventing you from going further.


Justin P. Mattock

[Justin P. Mattock]

keep in mind this is running
the latest git refpolicy and everything.
You can use these tools(setools)although normally try to
keep things as simple as possible, especially
during development(that is until things get worked out);

Justin P. Mattock

[Roland Roberts]

On 11/29/2009 05:11 AM, Sandro Janke wrote:
>  Actually, you don't need to have any of the setroubleshoot
> packages 
>  installed to get AVC messages logged. What you need is auditd running 
>  and it will log AVC messages to /var/log/audit/audit.log
>
>  With setroubleshoot-server installed you can watch the logged messages 
>  using:
>
>  # sealert -a /var/log/audit/audit.log
>
>  The output will be long and in the style of setroubleshoot browser, so 
>  take your measures.
>
>  Another tool - from the audit package - that can prove very useful is 
>  ausearch. It will search the audit logs for messages matching the 
>  given criteria. 
But I'm not getting any messages there.  And changing enforcing mode 
fixes the problem, so it seems like it has to be SELinux, but with no 
log, I can't figure out what rule needs to be changed.


-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Roland Roberts]

On 11/29/2009 08:44 PM, Roland Roberts wrote:
>  On 11/29/2009 05:11 AM, Sandro Janke wrote:
> > Actually, you don't need to have any of the setroubleshoot packages 
> > installed to get AVC messages logged. What you need is auditd running 
> > and it will log AVC messages to /var/log/audit/audit.log
> >
> > With setroubleshoot-server installed you can watch the logged 
> > messages using:
> >
> > # sealert -a /var/log/audit/audit.log
> >
> > The output will be long and in the style of setroubleshoot browser, 
> > so take your measures.
> >
> > Another tool - from the audit package - that can prove very useful is 
> > ausearch. It will search the audit logs for messages matching the 
> > given criteria.
>
>  But I'm not getting any messages there.  And changing enforcing mode 
>  fixes the problem, so it seems like it has to be SELinux, but with no 
>  log, I can't figure out what rule needs to be changed.
>
>  
At the suggestion of Daniel Walsh, I ran

semodule -DB

then restarted dovecot and got my messages.   I've used those to create 
policy, but can't load it.

I've configured dovecot to use a local socket connection to postgres.  
Here is what I for SELinux:

grep 'Dec  2.*dovecot-auth' /var/log/messages| audit2allow -m local > 
local.te
328 root> cat local.te

module local 1.0;

require {
     type dovecot_auth_t;
     type unlabeled_t;
     type postgresql_tmp_t;
     class sock_file write;
     class unix_stream_socket read;
}

#============= dovecot_auth_t ==============
allow dovecot_auth_t postgresql_tmp_t:sock_file write;

#============= unlabeled_t ==============
allow unlabeled_t self:unix_stream_socket read;
329 root> make -f /usr/share/selinux/devel/Makefile local.pp
Compiling targeted local module
/usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 10) to 
tmp/local.mod
Creating targeted local.pp policy package
rm tmp/local.mod.fc tmp/local.mod
330 root> semodule -i local.pp
libsepol.print_missing_requirements: local's global requirements were 
not met: type/attribute dovecot_auth_t
libsemanage.semanage_link_sandbox: Link packages failed
semodule:  Failed!

I'm at a loss on what to do here.  Suggestions on why it would tell me this?

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

[Bandan Das]

On Wed, 2009-12-02 at 15:22 -0500, Roland Roberts wrote:
>  On 11/29/2009 08:44 PM, Roland Roberts wrote:
>  > On 11/29/2009 05:11 AM, Sandro Janke wrote:
>  >> Actually, you don't need to have any of the setroubleshoot packages
>  
>  >> installed to get AVC messages logged. What you need is auditd
>  running 
>  >> and it will log AVC messages to /var/log/audit/audit.log
>  >>
>  >> With setroubleshoot-server installed you can watch the logged 
>  >> messages using:
>  >>
>  >> # sealert -a /var/log/audit/audit.log
>  >>
>  >> The output will be long and in the style of setroubleshoot browser,
>  
>  >> so take your measures.
>  >>
>  >> Another tool - from the audit package - that can prove very useful
>  is 
>  >> ausearch. It will search the audit logs for messages matching the 
>  >> given criteria.
>  >
>  > But I'm not getting any messages there.  And changing enforcing mode
>  
>  > fixes the problem, so it seems like it has to be SELinux, but with
>  no 
>  > log, I can't figure out what rule needs to be changed.
>  >
>  >
>  
>  At the suggestion of Daniel Walsh, I ran
>  
>  semodule -DB
>  
>  then restarted dovecot and got my messages.   I've used those to
>  create 
>  policy, but can't load it.
>  
>  I've configured dovecot to use a local socket connection to postgres. 
>  
>  Here is what I for SELinux:
>  
>  grep 'Dec  2.*dovecot-auth' /var/log/messages| audit2allow -m local > 
>  local.te
>  328 root> cat local.te
>  
>  module local 1.0;
>  
>  require {
>       type dovecot_auth_t;
>       type unlabeled_t;
>       type postgresql_tmp_t;
>       class sock_file write;
>       class unix_stream_socket read;
>  }
>  
>  #============= dovecot_auth_t ==============
>  allow dovecot_auth_t postgresql_tmp_t:sock_file write;
>  
>  #============= unlabeled_t ==============
>  allow unlabeled_t self:unix_stream_socket read;
>  329 root> make -f /usr/share/selinux/devel/Makefile local.pp
>  Compiling targeted local module
>  /usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
>  /usr/bin/checkmodule:  policy configuration loaded
>  /usr/bin/checkmodule:  writing binary representation (version 10) to 
>  tmp/local.mod
>  Creating targeted local.pp policy package
>  rm tmp/local.mod.fc tmp/local.mod
>  330 root> semodule -i local.pp
>  libsepol.print_missing_requirements: local's global requirements were 
>  not met: type/attribute dovecot_auth_t
>  libsemanage.semanage_link_sandbox: Link packages failed
>  semodule:  Failed!
>  
>  I'm at a loss on what to do here.  Suggestions on why it would tell me
>  this? 
I guess dovecot_auth_t should have been defined in dovecot.te. Are you
sure you have dovecot.pp loaded ? 

>  roland
>

[Daniel J Walsh]

On 12/02/2009 03:22 PM, Roland Roberts wrote:
>  On 11/29/2009 08:44 PM, Roland Roberts wrote:
> > On 11/29/2009 05:11 AM, Sandro Janke wrote:
> >> Actually, you don't need to have any of the setroubleshoot packages
> >> installed to get AVC messages logged. What you need is auditd running
> >> and it will log AVC messages to /var/log/audit/audit.log
> >>
> >> With setroubleshoot-server installed you can watch the logged
> >> messages using:
> >>
> >> # sealert -a /var/log/audit/audit.log
> >>
> >> The output will be long and in the style of setroubleshoot browser,
> >> so take your measures.
> >>
> >> Another tool - from the audit package - that can prove very useful is
> >> ausearch. It will search the audit logs for messages matching the
> >> given criteria.
> >
> > But I'm not getting any messages there.  And changing enforcing mode
> > fixes the problem, so it seems like it has to be SELinux, but with no
> > log, I can't figure out what rule needs to be changed.
> >
> >
>  
>  At the suggestion of Daniel Walsh, I ran
>  
>  semodule -DB
>  
>  then restarted dovecot and got my messages.   I've used those to create
>  policy, but can't load it.
>  
>  I've configured dovecot to use a local socket connection to postgres. 
>  Here is what I for SELinux:
>  
>  grep 'Dec  2.*dovecot-auth' /var/log/messages| audit2allow -m local >
>  local.te
>  328 root> cat local.te
>  
>  module local 1.0;
>  
>  require {
>      type dovecot_auth_t;
>      type unlabeled_t;
>      type postgresql_tmp_t;
>      class sock_file write;
>      class unix_stream_socket read;
>  }
>  
>  #============= dovecot_auth_t ==============
>  allow dovecot_auth_t postgresql_tmp_t:sock_file write;
>  
>  #============= unlabeled_t ==============
>  allow unlabeled_t self:unix_stream_socket read;
>  329 root> make -f /usr/share/selinux/devel/Makefile local.pp
>  Compiling targeted local module
>  /usr/bin/checkmodule:  loading policy configuration from tmp/local.tmp
>  /usr/bin/checkmodule:  policy configuration loaded
>  /usr/bin/checkmodule:  writing binary representation (version 10) to
>  tmp/local.mod
>  Creating targeted local.pp policy package
>  rm tmp/local.mod.fc tmp/local.mod
>  330 root> semodule -i local.pp
>  libsepol.print_missing_requirements: local's global requirements were
>  not met: type/attribute dovecot_auth_t
>  libsemanage.semanage_link_sandbox: Link packages failed
>  semodule:  Failed!
>  
>  I'm at a loss on what to do here.  Suggestions on why it would tell me
>  this?
>  
>  roland
>   
Did you replace the dovecot.pp when you first tried this?

SELinux won't let dovecot connect to postgresql (SOLVED!)

[Roland Roberts]

Roland Roberts wrote:
>  I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql
> RPMs 
>  installed.  I have a small user database set up for email authentication.
>  The issue I'm having is that when I am in enforcing mode, dovecot 
>  can't connect to the database.  Turning off enforcing mode lets it 
>  work.  I'm having trouble diagnosing where the denial is taking place 
>  as I don't see any avc messages in /var/log/messages that relate to 
>  dovecot.  The only messages I'm getting are in /var/log/maillog from 
>  dovecot like this:
>
>  Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to 
>  maildb: could not connect to server: Permission denied
>  Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running 
>  on host "fred.flinstone.org" and accepting
>  Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on 
>  port 5432?
>
>  The answer to the questions is "yes" it is running and accepting 
>  connections.  Whether or not enforcing mode is on, when logged in, I 
>  can connect to the database via
>
>  $ psql -h fred.flinstone.org maildb
>
>  I *think* this is a result of updating on Nov 18.  I have not changed 
>  the default selinux mode since the host was set up back in September.  
>  At that point, I set it to enforcing mode after working out a few 
>  issues.  On Nov 18, a lot of things were updated, but among there were
>
>  Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch
>  Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64
>  Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch
>  Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch
>
>  Today, I did another update, hoping it would cure the problem and got 
>  these revisions
>
>  Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch
>  Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch
>
>  but the behavior is unchanged, I still have to turn off enforcing mode.
>
>  Any clues on what I need to do to get this to work?  Or where to look 
>  for clues since, as I mentioned, I can't even find log entries that 
>  would clue me in.
>
>  roland 
Okay, here's what I finally ended up with that have me running in 
enforcing mode.  I have  both dovecot and exim using PostgreSQL for 
authentication.  I had originally had them connecting via tcp, but 
changed them to use the unix domain socket.  The policies below allow 
either.

I also ran into a problem with httpd needing access to PostgreSQL since 
I'm running Drupal with PostgreSQL as the backend.  And I have 
SquirrelMail running so httpd needs access to the imap/pop port.  I 
don't think this is complete as I'm using the tcp port for PostgreSQL 
and the policy only allows that, not the unix domain socket (which I 
should probably configure instead).  But at least I can now run in 
enforcing mode.

365 root> cat *.te

module dovecotauthfixes 1.0;

require {
        type dovecot_auth_t;
        type postgresql_port_t;
        type postgresql_tmp_t;
        type postgresql_t;
        class sock_file write;
        class tcp_socket name_connect;
        class unix_stream_socket connectto;
}

#============= dovecot_auth_t ==============
allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect;
allow dovecot_auth_t postgresql_t:unix_stream_socket connectto;
allow dovecot_auth_t postgresql_tmp_t:sock_file write;

module eximfixes 1.0;

require {
        type postgresql_tmp_t;
        type exim_t;
        type postgresql_t;
        class sock_file write;
        class unix_stream_socket connectto;
}

#============= exim_t ==============
allow exim_t postgresql_t:unix_stream_socket connectto;
allow exim_t postgresql_tmp_t:sock_file write;

module httpdfixes 1.0;

require {
        type postgresql_port_t;
        type httpd_t;
        type pop_port_t;
        class tcp_socket { name_bind name_connect };
}

#============= httpd_t ==============
allow httpd_t pop_port_t:tcp_socket { name_bind name_connect };
allow httpd_t postgresql_port_t:tcp_socket name_connect;

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220

SELinux won't let dovecot connect to postgresql (SOLVED!)

[Justin P. Mattock]

On 12/02/09 15:57, Roland Roberts wrote:
>  Roland Roberts wrote:
> > I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs
> > installed. I have a small user database set up for email authentication.
> > The issue I'm having is that when I am in enforcing mode, dovecot
> > can't connect to the database. Turning off enforcing mode lets it
> > work. I'm having trouble diagnosing where the denial is taking place
> > as I don't see any avc messages in /var/log/messages that relate to
> > dovecot. The only messages I'm getting are in /var/log/maillog from
> > dovecot like this:
> >
> > Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to
> > maildb: could not connect to server: Permission denied
> > Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running
> > on host "fred.flinstone.org" and accepting
> > Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on
> > port 5432?
> >
> > The answer to the questions is "yes" it is running and accepting
> > connections. Whether or not enforcing mode is on, when logged in, I
> > can connect to the database via
> >
> > $ psql -h fred.flinstone.org maildb
> >
> > I *think* this is a result of updating on Nov 18. I have not changed
> > the default selinux mode since the host was set up back in September.
> > At that point, I set it to enforcing mode after working out a few
> > issues. On Nov 18, a lot of things were updated, but among there were
> >
> > Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch
> > Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch
> > Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch
> >
> > Today, I did another update, hoping it would cure the problem and got
> > these revisions
> >
> > Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch
> > Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch
> >
> > but the behavior is unchanged, I still have to turn off enforcing mode.
> >
> > Any clues on what I need to do to get this to work? Or where to look
> > for clues since, as I mentioned, I can't even find log entries that
> > would clue me in.
> >
> > roland
>
>  Okay, here's what I finally ended up with that have me running in
>  enforcing mode. I have both dovecot and exim using PostgreSQL for
>  authentication. I had originally had them connecting via tcp, but
>  changed them to use the unix domain socket. The policies below allow
>  either.
>
>  I also ran into a problem with httpd needing access to PostgreSQL since
>  I'm running Drupal with PostgreSQL as the backend. And I have
>  SquirrelMail running so httpd needs access to the imap/pop port. I don't
>  think this is complete as I'm using the tcp port for PostgreSQL and the
>  policy only allows that, not the unix domain socket (which I should
>  probably configure instead). But at least I can now run in enforcing mode.
>
>  365 root> cat *.te
>
>  module dovecotauthfixes 1.0;
>
>  require {
>  type dovecot_auth_t;
>  type postgresql_port_t;
>  type postgresql_tmp_t;
>  type postgresql_t;
>  class sock_file write;
>  class tcp_socket name_connect;
>  class unix_stream_socket connectto;
>  }
>
>  #============= dovecot_auth_t ==============
>  allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect;
>  allow dovecot_auth_t postgresql_t:unix_stream_socket connectto;
>  allow dovecot_auth_t postgresql_tmp_t:sock_file write;
>
>  module eximfixes 1.0;
>
>  require {
>  type postgresql_tmp_t;
>  type exim_t;
>  type postgresql_t;
>  class sock_file write;
>  class unix_stream_socket connectto;
>  }
>
>  #============= exim_t ==============
>  allow exim_t postgresql_t:unix_stream_socket connectto;
>  allow exim_t postgresql_tmp_t:sock_file write;
>
>  module httpdfixes 1.0;
>
>  require {
>  type postgresql_port_t;
>  type httpd_t;
>  type pop_port_t;
>  class tcp_socket { name_bind name_connect };
>  }
>
>  #============= httpd_t ==============
>  allow httpd_t pop_port_t:tcp_socket { name_bind name_connect };
>  allow httpd_t postgresql_port_t:tcp_socket name_connect;
>
>  roland
>  
cool,
so your up and running..

Justin P. Mattock

SELinux won't let dovecot connect to postgresql (SOLVED!)

[Daniel J Walsh]

On 12/02/2009 06:57 PM, Roland Roberts wrote:
>  Roland Roberts wrote:
> > I'm running Fedora 11 x86_64 with the dovecot and dovecot-pgsql RPMs
> > installed. I have a small user database set up for email authentication.
> > The issue I'm having is that when I am in enforcing mode, dovecot
> > can't connect to the database. Turning off enforcing mode lets it
> > work. I'm having trouble diagnosing where the denial is taking place
> > as I don't see any avc messages in /var/log/messages that relate to
> > dovecot. The only messages I'm getting are in /var/log/maillog from
> > dovecot like this:
> >
> > Nov 28 22:23:11 fred dovecot: auth(default): pgsql: Connect failed to
> > maildb: could not connect to server: Permission denied
> > Nov 28 22:23:11 fred dovecot: auth(default): #011Is the server running
> > on host "fred.flinstone.org" and accepting
> > Nov 28 22:23:11 fred dovecot: auth(default): #011TCP/IP connections on
> > port 5432?
> >
> > The answer to the questions is "yes" it is running and accepting
> > connections. Whether or not enforcing mode is on, when logged in, I
> > can connect to the database via
> >
> > $ psql -h fred.flinstone.org maildb
> >
> > I *think* this is a result of updating on Nov 18. I have not changed
> > the default selinux mode since the host was set up back in September.
> > At that point, I set it to enforcing mode after working out a few
> > issues. On Nov 18, a lot of things were updated, but among there were
> >
> > Nov 18 10:00:02 Updated: kernel-firmware-2.6.30.9-96.fc11.noarch
> > Nov 18 10:00:15 Updated: kernel-headers-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:00:28 Installed: kernel-devel-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:01:30 Installed: kernel-2.6.30.9-96.fc11.x86_64
> > Nov 18 10:02:01 Updated: selinux-policy-3.6.12-86.fc11.noarch
> > Nov 18 10:02:46 Updated: selinux-policy-targeted-3.6.12-86.fc11.noarch
> >
> > Today, I did another update, hoping it would cure the problem and got
> > these revisions
> >
> > Nov 28 10:57:33 Updated: selinux-policy-3.6.12-88.fc11.noarch
> > Nov 28 10:57:47 Updated: selinux-policy-targeted-3.6.12-88.fc11.noarch
> >
> > but the behavior is unchanged, I still have to turn off enforcing mode.
> >
> > Any clues on what I need to do to get this to work? Or where to look
> > for clues since, as I mentioned, I can't even find log entries that
> > would clue me in.
> >
> > roland
>
>  Okay, here's what I finally ended up with that have me running in
>  enforcing mode. I have both dovecot and exim using PostgreSQL for
>  authentication. I had originally had them connecting via tcp, but
>  changed them to use the unix domain socket. The policies below allow
>  either.
>
>  I also ran into a problem with httpd needing access to PostgreSQL since
>  I'm running Drupal with PostgreSQL as the backend. And I have
>  SquirrelMail running so httpd needs access to the imap/pop port. I don't
>  think this is complete as I'm using the tcp port for PostgreSQL and the
>  policy only allows that, not the unix domain socket (which I should
>  probably configure instead). But at least I can now run in enforcing mode.
>
>  365 root> cat *.te
>
>  module dovecotauthfixes 1.0;
>
>  require {
>  type dovecot_auth_t;
>  type postgresql_port_t;
>  type postgresql_tmp_t;
>  type postgresql_t;
>  class sock_file write;
>  class tcp_socket name_connect;
>  class unix_stream_socket connectto;
>  }
>
>  #============= dovecot_auth_t ==============
>  allow dovecot_auth_t postgresql_port_t:tcp_socket name_connect;
>  allow dovecot_auth_t postgresql_t:unix_stream_socket connectto;
>  allow dovecot_auth_t postgresql_tmp_t:sock_file write;
>
>  module eximfixes 1.0;
>
>  require {
>  type postgresql_tmp_t;
>  type exim_t;
>  type postgresql_t;
>  class sock_file write;
>  class unix_stream_socket connectto;
>  }
>
>  #============= exim_t ==============
>  allow exim_t postgresql_t:unix_stream_socket connectto;
>  allow exim_t postgresql_tmp_t:sock_file write;
>
>  module httpdfixes 1.0;
>
>  require {
>  type postgresql_port_t;
>  type httpd_t;
>  type pop_port_t;
>  class tcp_socket { name_bind name_connect };
>  }
>
>  #============= httpd_t ==============
>  allow httpd_t pop_port_t:tcp_socket { name_bind name_connect };
>  allow httpd_t postgresql_port_t:tcp_socket name_connect;
>
>  roland
>  
You can also just set the booleans

# setsebool -P httpd_can_network_connect_db=1 httpd_can_sendmail=1

Please read:

http://people.fedoraproject.org/~dwalsh/SELinux/Presentations/selinux_fou...


This explains the four things SELinux is trying to tell you.  In order 
of most common to least

1 You have a labeling problem (restorecon/semanage fcontext)
2 You have a selinux confiuration problem (booleans, semanage selinux 
settings)
3 Bug in selinux-policy or application (audit2allow -M localpolicy)
4 You have been hacked.

In the case of what you are reporting most fall into category 2.

SELinux won't let dovecot connect to postgresql (SOLVED!)

[Roland Roberts]

On 12/02/2009 06:57 PM, Roland Roberts wrote:
>  Okay, here's what I finally ended up with that have me running in
>
>  enforcing mode.  I have  both dovecot and exim using PostgreSQL for 
>  authentication.  I had originally had them connecting via tcp, but 
>  changed them to use the unix domain socket.  The policies below allow 
>  either.
>
>  [...]
>  module eximfixes 1.0;
>
>  require {
>         type postgresql_tmp_t;
>         type exim_t;
>         type postgresql_t;
>         class sock_file write;
>         class unix_stream_socket connectto;
>  }
>
>  #============= exim_t ==============
>  allow exim_t postgresql_t:unix_stream_socket connectto;
>  allow exim_t postgresql_tmp_t:sock_file write;
>
>  module httpdfixes 1.0;
>
>  require {
>         type postgresql_port_t;
>         type httpd_t;
>         type pop_port_t;
>         class tcp_socket { name_bind name_connect };
>  }
>
>  #============= httpd_t ==============
>  allow httpd_t pop_port_t:tcp_socket { name_bind name_connect };
>  allow httpd_t postgresql_port_t:tcp_socket name_connect; 
The above are not actually necessary; only the dovecot fix was needed.  
Daniel Walsh pointed out that there were booleans I could set for the 
other problems, namely

# setsebool -P httpd_can_network_connect_db=1 httpd_can_sendmail=1 
exim_can_connect_db=1

replaces all of the above.

roland

-- 
		       PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD                             RL Enterprises
roland(a)rlenter.com                            6818 Madeline Court
roland(a)astrofoto.org                           Brooklyn, NY 11220