#22410 [Com]: broader apache-php security options

ID: 22410 Comment by: dale at daledude dot com Reported By: greg at laundrymat dot tv Status: Bogus Bug Type: Feature/Change Request Operating System: redhat 7.0 PHP Version: 4.3.0 New Comment: How about a virtual chroot, if you will, within php.ini and httpd.conf (needed per vhost). I hacked suexec for perl scripts to *actually* chroot to the vhosts directory tree. Needless to say this meant hardlinking required libs and executables to the vhosts directory tree, but was easy after creating a template directory tree to hardlink to. In the case of mod_php it would need to be a "fake" or internal chroot except for ticks, exec, system, etc calls where it can be safe to do an actual chroot() call since the external process will die off and the mod_php environment left in tact. Here is a proposal of new settings... * chroot_basedir: All file operations are relative to this. Not including ticks, system, exec, dl, etc. Example (pseudo): <virtualhost domain.com> php_admin_value chroot_basedir = /home/virtual/domain.com </virtualhost> <?php fopen("/var/www/html/file.php"); ?> The fopen would actually try to open "/home/virtual/domain.com/var/www/html/file.php". This might cause some overhead per function call. As I haven't even started to look at the best way to implement it I'm just guessing. Maybe the fopen arg can be manipulated the same place open_basedir is checked? * chroot_execdir: Jail to be in for ticks, exec, system, dl, etc. Follows same premise as chroot_basedir. Spawn a process chroot'd to this directory then execute the external command. Same way suexec does basically. I am considering implementing the above. No idea where to start just yet. I *very* briefly fgrep'd php source for occurances of open_basedir to get a quick glimpse. Please contact me with remarks. Previous Comments: ------------------------------------------------------------------------ [2003-04-30 12:08:16] derick@php.net I will repeat Rasmus' statement: It is impossible to implement this in a nice and straitforward way, feel free to come up with a patch on your own. The backticks as we call them are NOT functions, but properties of the PHP language, you can turn this off with safe_mode. ------------------------------------------------------------------------ [2003-04-30 12:05:55] greg at laundrymat dot tv Why is it so impossible? Just allow certain functions like the ticker command to be turned off for a virtual server. I got into a shared server yesterday that turned off the system and the exec commands system wide, but I was still able to execute the ticker command. That’s bad. There has to be a way to prohibit these commands for virtual directories. You can't use disable_functions on a per-dir basis because it is impossible to implement in an efficient manner. You should make this work: php_admin_value disable_functions "system,exec,`" Try this in safe mode: $test=ls -la; print $test; If you cold make the open_basedir command work with the system,exec and ticker commands that would sove the problem too. I just don’t want people to see anything past their root directories, while I need full access to call binaries. Thanks Greg ------------------------------------------------------------------------ [2003-04-30 11:41:13] rasmus@php.net You can't use disable_functions on a per-dir basis because it is impossible to implement in an efficient manner. safe_mode already addresses this issue with its safe_mode_exec() dir. I am sorry if you feel this is too restrictive, but there is simply no way to make open_basedir restrictions apply to arbitrary scripts a user might run. Use safe-mode or set up a jailed configuration with individual instances of Apache listening on separate ports with a reverse proxy out front directing port 80 requests to the appropriate internal port. ------------------------------------------------------------------------ [2003-04-30 11:26:23] wez@php.net Tried: php_admin_value disable_functions "system,exec" On a per directory basis? ------------------------------------------------------------------------ [2003-04-30 11:20:20] greg at laundrymat dot tv Will someone please address this security issue. It's huge! ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22410 -- Edit this bug report at http://bugs.php.net/?id=22410&edit=1