gpg through apache and php?

[brett]

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

[Stephen Smalley]

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)?

-- 
Stephen Smalley <sds(a)tycho.nsa.gov&gt;
National Security Agency

[brett]

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

[Stephen Smalley]

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 <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Daniel J Walsh]

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.


--

[Stephen Smalley]

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 <sds(a)tycho.nsa.gov&gt;
National Security Agency

[Daniel J Walsh]

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

--