Relabeling PHP uploads when they are moved into place

[Scott Gifford]

PHP uploads files into a temporary directory, where they are given the label
"httpd_tmp_t".  When a PHP script processes them, it calls
move_uploaded_file<http://php.net/manual/en/function.move-uploaded-fil... to
move the newly uploaded file into its final location.  This function does
some validity checks, then does a rename(2) from the temporary location to
the location passwd to move_uploaded_file.

The problem is that after the rename, the file still retains its original
label, "httpd_tmp_t".  That makes it inconsistent with files and directories
which weren't uploaded, and requires some policy gymnastics to take into
account that anything that could have been uploaded might have the
"httpd_tmp_t" type.

I am wondering if there is some good way to automatically relabel this file
when it is renamed?

I would like for the PHP application to work on SELinux and non-SELinux
systems, so I would prefer not to make calls out to SELinux-specific scripts
and programs (like restorecon).  What I would really like is some
configuration option that would just relabel files according to their
destination when they are rename(2)'d, but that may be asking too much.  :-)

Thanks for any advice,

-----Scott.

[Dominick Grift]

On Mon, 2011-10-03 at 12:29 -0400, Scott Gifford wrote:
>  PHP uploads files into a temporary directory, where they are given
> the
>  label "httpd_tmp_t".  When a PHP script processes them, it
>  calls move_uploaded_file to move the newly uploaded file into its
>  final location.  This function does some validity checks, then does a
>  rename(2) from the temporary location to the location passwd to
>  move_uploaded_file. 
Your web app would need to copy the file instead.

Or why not make your app create the file in the final destination in the
first place. then rename it there.

>  The problem is that after the rename, the file still retains its
>  original label, "httpd_tmp_t".  That makes it inconsistent with files
>  and directories which weren't uploaded, and requires some policy
>  gymnastics to take into account that anything that could have been
>  uploaded might have the "httpd_tmp_t" type. 
>  I am wondering if there is some good way to automatically relabel
> this
>  file when it is renamed?
>  
>  I would like for the PHP application to work on SELinux and
>  non-SELinux systems, so I would prefer not to make calls out to
>  SELinux-specific scripts and programs (like restorecon).  What I would
>  really like is some configuration option that would just relabel files
>  according to their destination when they are rename(2)'d, but that may
>  be asking too much.  :-) 
That is not practical because whatever moves the file might not be
allowed to relabelto the target location type.

So i do not think that this is feasible.

>  
>  Thanks for any advice,
>  
>  
>  -----Scott.
>  
>  
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/03/2011 12:39 PM, Dominick Grift wrote:
>  On Mon, 2011-10-03 at 12:29 -0400, Scott Gifford wrote:
> > PHP uploads files into a temporary directory, where they are
> > given the label "httpd_tmp_t".  When a PHP script processes them,
> > it calls move_uploaded_file to move the newly uploaded file into
> > its final location.  This function does some validity checks,
> > then does a rename(2) from the temporary location to the location
> > passwd to move_uploaded_file.
>  
>  Your web app would need to copy the file instead.
>  
>  Or why not make your app create the file in the final destination
>  in the first place. then rename it there.
>  
> > The problem is that after the rename, the file still retains its 
> > original label, "httpd_tmp_t".  That makes it inconsistent with
> > files and directories which weren't uploaded, and requires some
> > policy gymnastics to take into account that anything that could
> > have been uploaded might have the "httpd_tmp_t" type.
>  
> > I am wondering if there is some good way to automatically relabel
> > this file when it is renamed?
> > 
> > I would like for the PHP application to work on SELinux and 
> > non-SELinux systems, so I would prefer not to make calls out to 
> > SELinux-specific scripts and programs (like restorecon).  What I
> > would really like is some configuration option that would just
> > relabel files according to their destination when they are
> > rename(2)'d, but that may be asking too much.  :-)
>  
>  That is not practical because whatever moves the file might not be 
>  allowed to relabelto the target location type.
>  
>  So i do not think that this is feasible.
>  
> > 
> > Thanks for any advice,
> > 
> > 
> > -----Scott.
> > 
> > 
> > -- selinux mailing list selinux(a)lists.fedoraproject.org 
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
>   

Either that or make sure the upload directory (hint, don't use /tmp)
has the correct label.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6J744ACgkQrlYvE4MpobMvXgCg5RwP41RUKZUmNFSXDFg5xsuR
> t+4AoN9MV7juEJ+xyylBGD6CdeCzEz1T
> =2+F3
> -----END PGP SIGNATURE-----

[Scott Gifford]

Thanks for your help Dominick, a few comments below...

On Mon, Oct 3, 2011 at 12:39 PM, Dominick Grift <dominick.grift(a)gmail.com&gt;wrote:

>  On Mon, 2011-10-03 at 12:29 -0400, Scott Gifford wrote:
>  > PHP uploads files into a temporary directory, where they are given the
>  > label "httpd_tmp_t".  When a PHP script processes them, it
>  > calls move_uploaded_file to move the newly uploaded file into its
>  > final location.  This function does some validity checks, then does a
>  > rename(2) from the temporary location to the location passwd to
>  > move_uploaded_file.
>
>  Your web app would need to copy the file instead.
>  
Certainly that is possible.  It is not the normal idiom for PHP uploaded
files though, and bypasses the checks that the system libraries provide when
using move_uploaded_file.

Or why not make your app create the file in the final destination in the
>  first place. then rename it there.
>  
The PHP system libraries handle the file upload itself, and PHP code doesn't
run until the file is uploaded.  So there isn't really a practical way to do
this without jumping pretty far outside of PHP norms.

[ ... ]

>  > I am wondering if there is some good way to automatically relabel this
>  > file when it is renamed?
>
>  [ ... ] 
>  That is not practical because whatever moves the file might not be
>  allowed to relabelto the target location type.
>  
Right, but then I would simply expect a denial, just as I would if I tried
to do some other operation not allowed by SELinux, and would modify my
policy to allow that.  I think the issues here aren't fundamentally
different than with copying the file, except of course the needed permission
would be different.

As for Dan's suggestion to use an upload directory with the correct label:
The upload is handled by the PHP libraries and so doesn't know what context
the file should end up with at the time it is being created; it will really
depend on where it is copied to.

Maybe one solution would be to first move the file to a temporary name
(giving the checks that PHP's move_uploaded_file provides), then copy it to
its final name (which will relabel).  Could be a fair bit of extra work for
the OS if the file is large, but for this application it might be workable.

I'll also take a look at what would be required to patch PHP to get the
behavior I was expecting.

Thanks again for your suggestions!

-----Scott.

[Daniel Fazekas]

On Oct 3, 2011, at 20:07, Scott Gifford wrote:

> > Or why not make your app create the file in the final destination
> in the first place. then rename it there.
>  The PHP system libraries handle the file upload itself, and PHP code doesn't run
> until the file is uploaded.  So there isn't really a practical way to do this without
> jumping pretty far outside of PHP norms. 
You can change the temporary directory for uploaded files through the upload_tmp_dir
php.ini option.
Maybe that could help.

[Vadym Chepkov]

On Oct 3, 2011, at 12:39 PM, Dominick Grift wrote:

>  On Mon, 2011-10-03 at 12:29 -0400, Scott Gifford wrote:
> > PHP uploads files into a temporary directory, where they are given the
> > label "httpd_tmp_t".  When a PHP script processes them, it
> > calls move_uploaded_file to move the newly uploaded file into its
> > final location.  This function does some validity checks, then does a
> > rename(2) from the temporary location to the location passwd to
> > move_uploaded_file.
>  
>  Your web app would need to copy the file instead.
>  
>  Or why not make your app create the file in the final destination in the
>  first place. then rename it there.
>  
> > The problem is that after the rename, the file still retains its
> > original label, "httpd_tmp_t".  That makes it inconsistent with files
> > and directories which weren't uploaded, and requires some policy
> > gymnastics to take into account that anything that could have been
> > uploaded might have the "httpd_tmp_t" type.
>  
> > I am wondering if there is some good way to automatically relabel this
> > file when it is renamed?
> > 
> > I would like for the PHP application to work on SELinux and
> > non-SELinux systems, so I would prefer not to make calls out to
> > SELinux-specific scripts and programs (like restorecon).  What I would
> > really like is some configuration option that would just relabel files
> > according to their destination when they are rename(2)'d, but that may
> > be asking too much.  :-)
>  
>  That is not practical because whatever moves the file might not be
>  allowed to relabelto the target location type.
>  
>  So i do not think that this is feasible.
>  
> > 
> > Thanks for any advice,
> > 
> > 
> > -----Scott.
> >  

Hi,

I think it's one of those cases where if a person asks how to shoot himself, he
shouldn't be provided any recipes :)

I understand where this requirement is coming from. Many current web engines nowadays
allow you to install "extensions" or "plugins" via web interface.
This is convenient, but absolutely insecure - think about it, you are trying to allow
application to do self code modifications, the very thing that SELinux should help you to
prevent.
A bug in wordpress/phpbb/cms made simple/whatever together with this SELinux backdoor
would allow installation of a malicious code on your server. I bet you have 
GRANT ALL PRIVILEGES ON database.* to webuser, and you will wake up with no website, for
example, or stolen sensitive data. 
Convenience and security most times contradict each other. Install your php code
manually.

Vadym

[Vadym Chepkov]

On Oct 4, 2011, at 7:00 AM, Vadym Chepkov wrote:

>  
>  On Oct 3, 2011, at 12:39 PM, Dominick Grift wrote:
>  
> > On Mon, 2011-10-03 at 12:29 -0400, Scott Gifford wrote:
> >> PHP uploads files into a temporary directory, where they are given the
> >> label "httpd_tmp_t".  When a PHP script processes them, it
> >> calls move_uploaded_file to move the newly uploaded file into its
> >> final location.  This function does some validity checks, then does a
> >> rename(2) from the temporary location to the location passwd to
> >> move_uploaded_file.
> > 
> > Your web app would need to copy the file instead.
> > 
> > Or why not make your app create the file in the final destination in the
> > first place. then rename it there.
> > 
> >> The problem is that after the rename, the file still retains its
> >> original label, "httpd_tmp_t".  That makes it inconsistent with files
> >> and directories which weren't uploaded, and requires some policy
> >> gymnastics to take into account that anything that could have been
> >> uploaded might have the "httpd_tmp_t" type.
> > 
> >> I am wondering if there is some good way to automatically relabel this
> >> file when it is renamed?
> >> 
> >> I would like for the PHP application to work on SELinux and
> >> non-SELinux systems, so I would prefer not to make calls out to
> >> SELinux-specific scripts and programs (like restorecon).  What I would
> >> really like is some configuration option that would just relabel files
> >> according to their destination when they are rename(2)'d, but that may
> >> be asking too much.  :-)
> > 
> > That is not practical because whatever moves the file might not be
> > allowed to relabelto the target location type.
> > 
> > So i do not think that this is feasible.
> > 
> >> 
> >> Thanks for any advice,
> >> 
> >> 
> >> -----Scott.
> >> 
>  
>  
>  Hi,
>  
>  I think it's one of those cases where if a person asks how to shoot himself, he
> shouldn't be provided any recipes :)
>  
>  I understand where this requirement is coming from. Many current web engines nowadays
> allow you to install "extensions" or "plugins" via web interface.
>  This is convenient, but absolutely insecure - think about it, you are trying to allow
> application to do self code modifications, the very thing that SELinux should help you to
> prevent.
>  A bug in wordpress/phpbb/cms made simple/whatever together with this SELinux backdoor
> would allow installation of a malicious code on your server. I bet you have 
>  GRANT ALL PRIVILEGES ON database.* to webuser, and you will wake up with no website, for
> example, or stolen sensitive data. 
>  Convenience and security most times contradict each other. Install your php code
> manually.
>  
>  Vadym
>   
In those cases were uploads are indeed necessary - never had an issue :

# wiki
/var/www/vvcwiki/bin(/.*)?                             
gen_context(system_u:object_r:httpd_mediawiki_script_exec_t,s0)
/var/www/vvcwiki/images(/.*)?                          
gen_context(system_u:object_r:httpd_mediawiki_rw_content_t,s0)
/var/www/vvcwiki/cache(/.*)?                           
gen_context(system_u:object_r:httpd_mediawiki_rw_content_t,s0)
# chat
/var/www/phpfreechat/data(/.*)?                        
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
# Google sitemap
/var/www/(.*/)?sitemap\.xml(\.gz)?                     
gen_context(system_u:object_r:httpd_cache_t,s0)
# Kayako
/var/www/kayako/__swift/cache(/.*)?                    
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/var/www/kayako/__swift/files(/.*)?                    
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/var/www/kayako/__swift/geoip(/.*)?                    
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/var/www/kayako/__swift/log(/.*)?                      
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
# wordpress
/var/www/.*/wp-content/uploads(/.*)?                   
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
# phpbb
/var/www/phpbb/cache(/.*)?                             
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/var/www/phpbb/files(/.*)?                             
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/var/www/phpbb/images(/.*)?                            
gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)

Cheers,
Vadym

[Scott Gifford]

On Tue, Oct 4, 2011 at 7:00 AM, Vadym Chepkov <vchepkov(a)gmail.com&gt; wrote:
[ ... ]

>  I think it's one of those cases where if a person asks how to
> shoot
>  himself, he shouldn't be provided any recipes :)
>  
The httpd_tmp_t does not provide any security advantage here, it is fully
accessible by the Web server, just not accessible by other tools that we use
in our development process (in particular Samba).

I'm moving the files into a directory labeled httpd_user_rw_content_t with
these Apache options:

 Options None
  AllowOverride None
 RewriteEngine Off
 php_admin_flag engine off
 AddType text/plain .html .htm .shtml .php .js


The Apache options should prevent anything from being executed (though any
suggestions on improving this are welcomed).

I understand where this requirement is coming from. Many current web engines
>  nowadays allow you to install "extensions" or
> "plugins" via web interface.
>  
No, these are just image files, not code.

Regarding the rules you mentioned in your next message: I have similar rules
for my image directory, but SELinux does not apply them to this file.  Since
the image is first uploaded to a temporary location, it has
type httpd_tmp_t, and it is not relabeled according to my policy when it is
moved into its final location.

-----Scott.

[Vadym Chepkov]

On Oct 4, 2011, at 9:57 AM, Scott Gifford wrote:

>  On Tue, Oct 4, 2011 at 7:00 AM, Vadym Chepkov
> <vchepkov(a)gmail.com&gt; wrote:
>  [ ... ]
>  I think it's one of those cases where if a person asks how to shoot himself, he
> shouldn't be provided any recipes :)
>  
>  The httpd_tmp_t does not provide any security advantage here, it is fully accessible by
> the Web server, just not accessible by other tools that we use in our development process
> (in particular Samba).
>  
>  I'm moving the files into a directory labeled httpd_user_rw_content_t with these
> Apache options:
>  
>   Options None
>   AllowOverride None
>   RewriteEngine Off
>   php_admin_flag engine off
>   AddType text/plain .html .htm .shtml .php .js
>  
>  The Apache options should prevent anything from being executed (though any suggestions on
> improving this are welcomed).
>  
>  I understand where this requirement is coming from. Many current web engines nowadays
> allow you to install "extensions" or "plugins" via web interface.
>  
>  No, these are just image files, not code.
>  
>  Regarding the rules you mentioned in your next message: I have similar rules for my image
> directory, but SELinux does not apply them to this file.  Since the image is first
> uploaded to a temporary location, it has type httpd_tmp_t, and it is not relabeled
> according to my policy when it is moved into its final location.
>  
>  -----Scott. 
ok, then :)
But you saw all those different application don't have a problem with uploading a file
and they do get a proper context. 
If files are copied and than deleted (not moved) it "should just work"

Vadym