Hi,
I had to disable SELinux on my apache httpd in order to get my php scripts to work. They proc_open() gpg and SELinux didn't like that. Is there anyway to allow gpg to get through proc_open() so i can still have SELinux checking up on my webserver?
Thanks in advance, -brett
On Tue, 2005-04-26 at 23:09 -0400, brett wrote:
Hi,
I had to disable SELinux on my apache httpd in order to get my php scripts to work. They proc_open() gpg and SELinux didn't like that. Is there anyway to allow gpg to get through proc_open() so i can still have SELinux checking up on my webserver?
Details, please: - what policy are you running: strict or targeted, FC3 or FC4/devel? - what httpd_* booleans do you have enabled? - where have you placed the keyring for gpg that you want accessible via httpd? - what avc denials did you get in /var/log/messages (FC3) or /var/log/audit/audit.log (FC4)?
Thanks Stephen. See answers below. -brett
On Tue, 2005-04-26 at 23:09 -0400, brett wrote:
Hi,
I had to disable SELinux on my apache httpd in order to get my php scripts to work. They proc_open() gpg and SELinux didn't like that. Is there anyway to allow gpg to get through proc_open() so i can still have SELinux checking up on my webserver?
Details, please:
- what policy are you running: strict or targeted, FC3 or FC4/devel?
targeted. FC3
- what httpd_* booleans do you have enabled?
httpd_disable_trans active httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_tty_comm inactive httpd_unified active
- where have you placed the keyring for gpg that you want accessible via
httpd?
/home/test/.gnupg
test is a user. Also, i plan on using symmetric encryption so i don't think it needs the keyring file.
- what avc denials did you get in /var/log/messages (FC3)
or /var/log/audit/audit.log (FC4)?
Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 ino=3919093 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:ld_so_cache_t tclass=file Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:bin_t tclass=file
On Wed, 2005-04-27 at 22:09 -0400, brett wrote:
httpd_disable_trans active
What? That should have disabled all protection on httpd, i.e. the transition into httpd_t in the first place. Or did you just make that change after being unable to get it to work?
httpd_enable_homedirs active
Allows access to user home directories. For better security, disable.
httpd_unified active
This folds together the distinct types of web content; preferable to disable it if possible.
/home/test/.gnupg
test is a user. Also, i plan on using symmetric encryption so i don't think it needs the keyring file.
Why isn't it just part of the web tree under /var/www so that you can prohibit access to user home directories entirely?
Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 ino=3919093 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:ld_so_cache_t tclass=file Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:bin_t tclass=file
This is a result of gpg being marked as requiring an executable stack (and still looks that way in FC4/devel - execstack -q /usr/bin/gpg reports X - Dan?). With a newer kernel (>= 2.6.12-rc2, also included in FC4/devel kernels), you'd at least avoid the noise on ld.so.cache due to the checkreqprot compatibility support. But you would still need execmod on the gpg binary; under strict policy, gpg has its own separate executable type (gpg_exec_t) and domain (gpg_t), so we only need to allow execmod for that particular case. What's suggested for FC3 targeted policy, Dan?
Stephen Smalley wrote:
On Wed, 2005-04-27 at 22:09 -0400, brett wrote:
httpd_disable_trans active
What? That should have disabled all protection on httpd, i.e. the transition into httpd_t in the first place. Or did you just make that change after being unable to get it to work?
httpd_enable_homedirs active
Allows access to user home directories. For better security, disable.
httpd_unified active
This folds together the distinct types of web content; preferable to disable it if possible.
/home/test/.gnupg
test is a user. Also, i plan on using symmetric encryption so i don't think it needs the keyring file.
Why isn't it just part of the web tree under /var/www so that you can prohibit access to user home directories entirely?
Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execute } for pid=6266 comm=gpg path=/etc/ld.so.cache dev=dm-0 ino=3919093 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:ld_so_cache_t tclass=file Apr 24 22:29:06 razorfold kernel: audit(1114396146.398:0): avc: denied { execmod } for pid=6266 comm=gpg path=/usr/bin/gpg dev=dm-0 ino=4972274 scontext=user_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:bin_t tclass=file
This is a result of gpg being marked as requiring an executable stack (and still looks that way in FC4/devel - execstack -q /usr/bin/gpg reports X - Dan?).
Hopefully fixed again in tomorrow's rawhide.
With a newer kernel (>= 2.6.12-rc2, also included in FC4/devel kernels), you'd at least avoid the noise on ld.so.cache due to the checkreqprot compatibility support. But you would still need execmod on the gpg binary; under strict policy, gpg has its own separate executable type (gpg_exec_t) and domain (gpg_t), so we only need to allow execmod for that particular case. What's suggested for FC3 targeted policy, Dan?
Fix takes care of the problem.
On Thu, 2005-04-28 at 14:54 -0400, Daniel J Walsh wrote:
Hopefully fixed again in tomorrow's rawhide.
You mean a fixed gpg that isn't marked as requiring an executable stack, or a "fixed" targeted policy to workaround it?
Fix takes care of the problem.
For FC4, possibly. But the original poster is running FC3+targeted policy.
Stephen Smalley wrote:
On Thu, 2005-04-28 at 14:54 -0400, Daniel J Walsh wrote:
Hopefully fixed again in tomorrow's rawhide.
You mean a fixed gpg that isn't marked as requiring an executable stack, or a "fixed" targeted policy to workaround it?
Fixed gpg to not require exec stack.
Fix takes care of the problem.
For FC4, possibly. But the original poster is running FC3+targeted policy.
I don't know what to do then. Maybe we need to release a FC3 policy that just allows execmem/execmod for apache.
Dan
selinux@lists.fedoraproject.org
-
brett -
Daniel J Walsh -
Stephen Smalley