gpg through apache and php?
Daniel J Walsh
dwalsh at redhat.com
Thu Apr 28 18:54:52 UTC 2005
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.
--
More information about the fedora-selinux-list
mailing list