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_filehttp://php.net/manual/en/function.move-uploaded-file.php 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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@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.
Thanks for your help Dominick, a few comments below...
On Mon, Oct 3, 2011 at 12:39 PM, Dominick Grift dominick.grift@gmail.comwrote:
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.
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.
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
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
On Tue, Oct 4, 2011 at 7:00 AM, Vadym Chepkov vchepkov@gmail.com 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.
On Oct 4, 2011, at 9:57 AM, Scott Gifford wrote:
On Tue, Oct 4, 2011 at 7:00 AM, Vadym Chepkov vchepkov@gmail.com 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
selinux@lists.fedoraproject.org