Bug 338091
| Summary: | SELinux, httpd apcupsd socket denial | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Anthony Messina <amessina> |
| Component: | apcupsd | Assignee: | Tomas Smetana <tsmetana> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | CC: | dwalsh, jorton, triage |
| 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: | 2008-06-17 02:41:26 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: | |||
Oops, I DO get this denial in enforcing mode as well. The same type of errors also occur with upsimage.cgi and upsstats.cgi 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? 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 CGI scripts "do not get direct access", I meant to say. 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.
(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 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. Re-assigning to apcupsd for further input. The cgi script connects to the network UPS servers (apcupsd). I'm trying to reproduce the AVC messages but no luck yet... Did you alter the httpd or SELinux configuration somehow (relabeling files or so) I really can't reproduce this. Eh -- There should be a question mark after ')'... Sorry. I have not altered any of the files that are in any of the httpd* or apcupsd* rpms. 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 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. |
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.