#23612 [NEW]: new "Security" related settings
| From: | dale at daledude dot com | Date: | Tue, 13 May 2003 15:23:24 +0000 |
| Subject: | #23612 [NEW]: new "Security" related settings | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-39533@lists.php.net to get a copy of this message | ||
From: dale at daledude dot com
Operating system: linux rh 7.2
PHP version: 4.3.2RC2
PHP Bug Type: Feature/Change Request
Bug description: new "Security" related settings
I posted this as a response to bug #22410, but taking a chance to open it
as a new feature request.
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.
--
Edit bug report at http://bugs.php.net/?id=23612&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=23612&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=23612&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=23612&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=23612&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=23612&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=23612&r=support
Expected behavior: http://bugs.php.net/fix.php?id=23612&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=23612&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=23612&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=23612&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23612&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=23612&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=23612&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=23612&r=gnused