Bug 338091 - SELinux, httpd apcupsd socket denial
SELinux, httpd apcupsd socket denial
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: apcupsd (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-18 11:08 EDT by Anthony Messina
Modified: 2008-06-16 22:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:41:26 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)

  None (edit)
Description Anthony Messina 2007-10-18 11:08:50 EDT
Description of problem:
When accessing apcupsd's multimon.cgi from an apache server, a socket denial 
error is created in permissive mode, though it does not seem to affect 
function.

I do not get the audit in enforcing mode, and multimon.cgi seems to work 
properly.

Version-Release number of selected component (if applicable):
apcupsd-3.14.2-1.fc7
apcupsd-cgi-3.14.2-1.fc7
httpd-2.2.6-1.fc7
selinux-policy-targeted-2.6.4-48.fc7

How reproducible:
When a user accesses the multimon.cgi file through a web browser.
  
Actual results:
avc: denied { read, write } for comm="multimon.cgi" dev=sockfs egid=48 euid=48 
exe="/var/www/apcupsd/multimon.cgi" exit=0 fsgid=48 fsuid=48 gid=48 items=0 
name="" path="socket:[4307226]" pid=14926 
scontext=system_u:system_r:httpd_apcupsd_cgi_script_t:s0 sgid=48 
subj=system_u:system_r:httpd_apcupsd_cgi_script_t:s0 suid=48 tclass=tcp_socket 
tcontext=system_u:system_r:httpd_t:s0 tty=(none) uid=48

Expected results:
I'm not sure whether apcupsd should have this access or not.
Comment 1 Anthony Messina 2007-10-18 11:09:52 EDT
Oops, I DO get this denial in enforcing mode as well.
Comment 2 Anthony Messina 2007-10-18 11:26:19 EDT
The same type of errors also occur with upsimage.cgi and upsstats.cgi
Comment 3 Daniel Walsh 2007-10-18 15:57:25 EDT
This looks like a leaked file descriptory from apache

Joe are httpd cgi scripts supposed to have access to the tcp_socket owned by httpd?
Comment 4 Joe Orton 2007-10-23 06:10:54 EDT
CGI scripts do not direct access to the TCP socket fds, they just get pipes to
the httpd child process as fd 0/1/2.

It looks like multimon.cgi uses TCP sockets directly so presumably needs extra
policy/tweaks, or just:

setsebool httpd_can_network_connect=1
Comment 5 Joe Orton 2007-10-23 06:11:18 EDT
CGI scripts "do not get direct access", I meant to say.
Comment 6 Daniel Walsh 2007-10-23 07:18:51 EDT
avc: denied { read, write } for comm="multimon.cgi" dev=sockfs egid=48 euid=48 
exe="/var/www/apcupsd/multimon.cgi" exit=0 fsgid=48 fsuid=48 gid=48 items=0 
name="" path="socket:[4307226]" pid=14926 
scontext=system_u:system_r:httpd_apcupsd_cgi_script_t:s0 sgid=48 
subj=system_u:system_r:httpd_apcupsd_cgi_script_t:s0 suid=48 tclass=tcp_socket 
tcontext=system_u:system_r:httpd_t:s0 tty=(none) uid=48

But this avc is saying httpd_apcupsd_sgi_script_t process wants to {read/write }
on a tcp_socket owned by the httpd_t process.  Which means the httpd_t process
did not FD_CLOSEXEC the tcp_socket.

We have in policy right now

allow httpd_sys_script_t httpd_t:tcp_socket { read write };

Which allows this, but I am not sure if this is necessary or just a fact that we
are covering up a leaked file descriptor from httpd.
Comment 7 Anthony Messina 2007-10-23 20:42:55 EDT
(In reply to comment #4)
> setsebool httpd_can_network_connect=1

already using:
allow_httpd_anon_write --> on
allow_httpd_dbus_avahi --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> on
httpd_builtin_scripting --> on
httpd_can_network_connect --> on
httpd_can_network_connect_db --> on
httpd_can_network_relay --> off
httpd_can_sendmail --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_ssi_exec --> off
httpd_tty_comm --> off
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_nfs --> off
Comment 8 Joe Orton 2008-01-24 10:39:27 EST
It is trivial to demonstrate that the only fds available to a CGI script are as
follows, a CGI script which does "ls -l /proc/self/fd":

total 0
lr-x------ 1 apache apache 64 Jan 24 15:35 0 -> pipe:[622521]
l-wx------ 1 apache apache 64 Jan 24 15:35 1 -> pipe:[622522]
l-wx------ 1 apache apache 64 Jan 24 15:35 2 -> pipe:[622523]
lr-x------ 1 apache apache 64 Jan 24 15:35 3 -> /proc/14226/fd

barring any better information this needs to be debugged in multimon, e.g. by
stracing it to see exactly what socket is being used.
Comment 9 Joe Orton 2008-01-24 10:40:19 EST
Re-assigning to apcupsd for further input.
Comment 10 Tomas Smetana 2008-01-25 04:33:42 EST
The cgi script connects to the network UPS servers (apcupsd).  I'm trying to
reproduce the AVC messages but no luck yet...
Comment 11 Tomas Smetana 2008-01-30 06:24:27 EST
Did you alter the httpd or SELinux configuration somehow (relabeling files or
so) I really can't reproduce this.
Comment 12 Tomas Smetana 2008-01-30 06:25:12 EST
Eh -- There should be a question mark after ')'...  Sorry.
Comment 13 Anthony Messina 2008-01-30 18:18:02 EST
I have not altered any of the files that are in any of the httpd* or apcupsd* 
rpms.
Comment 14 Bug Zapper 2008-05-14 10:47:14 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Bug Zapper 2008-06-16 22:41:24 EDT
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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