Bug 167949 - when selinux is enabled, httpd refuses to start
when selinux is enabled, httpd refuses to start
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Russell Coker
:
: 168346 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-09 16:02 EDT by Edward Rudd
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 15:30:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
section of /var/log/audit/audit.log when "service httpd start" was run (9.47 KB, text/plain)
2005-10-12 20:59 EDT, Edward Rudd
no flags Details

  None (edit)
Description Edward Rudd 2005-09-09 16:02:36 EDT
Description of problem:
when I enabled the default targeted polixy on my x86_64 system I can not start
httpd via "service httpd start" or via /etc/init.d/httpd start or via normal
startup. (ie the init.d script).

Version-Release number of selected component (if applicable):
httpd 2.0.54-10.2
selinux-policy-targeted 1.25.4-10

How reproducible:
every time

Steps to Reproduce:
1. service httpd start

Actual results:
Starting httpd:                                            [FAILED]

nothing, i mean NOTHING is put in the /var/log/message, /var/log/audit.log, or
/var/log/httpd/error_log.

Expected results:
apache to start.

Additional info:
if I do
sh /etc/init.d/httpd start

it starts fine. (very odd) or turn of enforcing when I start it.

this is an x86_64 system (amd 3200+)
Comment 1 Rahul Sundaram 2005-09-09 16:29:58 EDT

Thank you for the report. However this should be assigned to
selinux-targeted-policy as this has been identified as related to SELinux. Make
sure that you have all the updates (yum update) and relabel your filesystem using 

#touch /.autorelabel

and reboot your system as mentioned in the Fedora SELinux FAQ

If audit daemon is disabled in your system, you will see avc denied messages in
/var/log/messages and post the output of that if the problem still exists after
the updates
Comment 2 Edward Rudd 2005-09-10 01:10:20 EDT
I had similar problems in FC3 and had disabled SElinux when I upgraded to FC4..
I finally decided to enable it again and reboot after doing a full update to the
lastest eratta, and upon reboot it did a complete relabel of the file system.

And the auditd is enabled as I do see other messages appearing in the audit log,
just absolutely nothing when apache is attemted to start.

Also during bootup it usually says "unable to bind on port 80". but never ever
gives that error when I try to start it after the system is up.. just a failed
from the init script and nothing in the logs.. (unless I run the init script in
a subshell as I mentioned in the initial report).

I initially filed it under httpd as it seemed it might have been an issue with
the init script itself. given that oddity I noticed.
Comment 3 Rahul Sundaram 2005-09-10 01:14:56 EDT

Ok, can you try disabling SELinux with setenforce 0 and verify that this is
indeed related to SELinux?
Comment 4 Edward Rudd 2005-10-12 01:35:48 EDT
[root@urkle ~]# service httpd stop
Stopping httpd:                                            [  OK  ]
[root@urkle ~]# service httpd start
Starting httpd:                                            [FAILED]
[root@urkle ~]# setenforce 0
[root@urkle ~]# service httpd start
Starting httpd:                                            [  OK  ]
[root@urkle ~]# service httpd stop
Stopping httpd:                                            [  OK  ]
[root@urkle ~]# setenforce 1
[root@urkle ~]# service httpd start
Starting httpd:                                            [FAILED]
[root@urkle ~]# /etc/init.d/httpd start
Starting httpd:                                            [FAILED]
[root@urkle ~]# sh /etc/init.d/httpd start
Starting httpd:                                            [  OK  ]
Comment 5 Daniel Walsh 2005-10-12 15:08:55 EDT
Looks like an SELinux problem.  Just to make sure.  What context is it running in 

ps -eZ | grep http

You can enable all audit messages by installing selinux-policy-targeted-sources

cd /etc/selinux/targeted/src/policy
make enableaudit; make load

Then start the httpd server.  See if you get any avc messages in
/var/log/messages or /var/log/audit/audit.log

make clean; make load

will turn the additional auditing back off.
Comment 6 Edward Rudd 2005-10-12 20:57:06 EDT
the way it is currently running (via sh /etc/init.d/httpd start)  it is running
under "root:system_r:unconfined_t"

and enable all audit messages in the policy didn't change any of the output to
/var/log/{messages,audit/audit.log}

wait.. ahh. need to restart auditd..

I will attach the log.
Comment 7 Edward Rudd 2005-10-12 20:59:22 EDT
Created attachment 119868 [details]
section of /var/log/audit/audit.log when "service httpd start" was run
Comment 8 Daniel Walsh 2005-10-13 08:35:04 EDT
Two things come out of the log.

allow httpd_t devpts_t:chr_file { read write };
allow httpd_t ftp_port_t:tcp_socket name_bind;

Does the startup of httpd prompt the user for some input?  

Second, Why does httpd listen on the ftp port?

Dan
Comment 9 Edward Rudd 2005-10-13 10:39:52 EDT
No it doesn't ask for any input.

And the FTP port is because I have my mod_ftpd installed in it. ( I completely
for got about that).

Seems as though that is the cause of the problem.  Disabling mod_ftpd allows it
to startup..   Shouldn't there be some better way of tracking down the reason
for this?  And how do I add the ftp ports as allowable? (probably a pill due to
the fact that FTP requires port 21 and a series of random ports for the data ports)
Comment 10 Daniel Walsh 2005-10-17 11:57:35 EDT
Are you running NIS on this machine or do you have allow_ybind boolean turned
on?  If so that is why the httpd trying to access  ftp_port_t was dontaudit.  If
not then there is a problem in policy.

I am not sure how to handle mod_ftpd, I could add policy to allow httpd to
listen on this port if a boolean was set, but this is the first time I have
heard of this bug and have no idea how often mod_ftpd is used.
Comment 11 Edward Rudd 2005-10-17 12:27:27 EDT
not using NIS, and don't even think I have ypbind installed. 

mod_ftpd : http://www.outoforder.cc/projects/apache/mod_ftpd/

mod_ftpd is an FTP server for apache 2 written by me.

It's used by a few peaople, not exactly sure how many. But I am receiving a
little over 100 downloads a month, sometimes over 200, since I wrote the module
2 years ago.  Also Covalent has recently released their mod_ftp into open source
(still working it's way through the Apache incubator).

So it would be nice to have a policy added to allow httpd to listen to that
port, and to a range of high ports (unless those aren't blocked in the policy)
for passive data transfers.
Comment 12 Daniel Walsh 2005-10-17 15:00:20 EDT
If you install policy sources and add the following lines to the apache.te file

bool httpd_enable_ftp_server false;
if (httpd_enable_ftp_server) {
allow httpd_t ftp_port_t:tcp_socket name_bind;
}

Does this work without the passive outward connections?

Then if you need the outbound connections you can set the boolean
httpd_can_network_connect
Comment 13 Edward Rudd 2005-12-06 13:18:26 EST
This added selinux policy is allowing my FTP module to work (and it seems it's
already made it into the targeted policy.   Now as passive requires the server
to bind localy for incoming connections so we need to add in an option to allow
incoming passive connections on a range of high ports.

Active FTP requires the server make outgoing connections to the client and
requires the httpd_can_network_connect to be enabled.
Comment 14 John Thacker 2007-03-10 14:08:21 EST
*** Bug 168346 has been marked as a duplicate of this bug. ***

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