#38622 [NEW]: Proposed new security scheme for shared hosting (safe mode substitute)
| From: | php at troy dot rollo dot name | Date: | Mon, 28 Aug 2006 05:39:32 +0000 |
| Subject: | #38622 [NEW]: Proposed new security scheme for shared hosting (safe mode substitute) | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-101403@lists.php.net to get a copy of this message | ||
From: php at troy dot rollo dot name
Operating system: UNIX/Linux
PHP version: 6CVS-2006-08-28 (CVS)
PHP Bug Type: Feature/Change Request
Bug description: Proposed new security scheme for shared hosting (safe mode substitute)
Description:
------------
Now that "safe mode" is to be thrown out, it would be nice
to have an alternative mechanism for providing some sort
of security in a shared hosting environment.
I started with the basic idea that only information that
could safely published on a newsgroup should be made
accessible directly to the user that the web server runs
as. Starting from this base point, I then considered what
a PHP script would need access to that it would no longer
have.
The first obviously missing thing would be database
passwords. Ideally these should be made available only to
scripts running on the virtual host authorised to use
them. When the web server is starting up it would need to
access a file that is specified in the virtual host's
section of the server configuration file to read the
passwords before forking off children and setting their
user IDs to the running user ID. It could then make these
available to PHP scripts as a variable only when the
script is running on that virtual host.
For example:
<VirtualHost 192.168.0.1>
ServerName www.virtualhost.example.com
...
php_privatefile /var/virtuals/virtualhost.example.com/privates
...
</VirtualHost>
The referenced file would include various settings:
enckey=418f8ae56710cb
dbpass=shh-its-a-secret
The HTTP server reads the file at startup and keeps the
data. The PHP script running on the virtual host could get
access to these values by means of an array:
$dbpass = $PRIVATES['dbpass'];
The next thing is access to files. On the assumption that
direct file accesses of this kind ought to be rare, it
seems reasonable to allow calling an external program to
assist with this. This could be handled by providing for
an ACL file, '.phpacl' in any directory. If a file access
fails with "permission denied", PHP could look in the
directory and each parent for the '.phpacl' file. If found
(and PHP would have to be able to determine its existence
without assistance even though it could not read the
file), it would call a setuid script, passing password to
it taken from a specially named value in the private
settings file (say, "_aclpass"), together with information
on the operation it needs. If the password matches the one
in the ".phpacl" file, and the operation is permitted by
the ACLs in it, the setuid script changes to the user ID
of that file and attempts the operation itself, passing
the result back to the caller. Where the operation is
an "open", it could pass the resulting file descriptor
back via a UNIX domain socket (passed as file descriptor
3, perhaps).
Without "safe mode", shared hosting becomes problematic
because even passwords must be accessible to other hosts
on the server and files and directories that need to be
written to also need to be writable to other hosts on the
server. The mechanism I have described here seeks to avoid
that by providing a restricted mechanism whereby this
information and files accessible only to some other user
could be made available on a restricted basis only to the
authorised virtual server.
--
Edit bug report at http://bugs.php.net/?id=38622&edit=1
--
Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38622&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38622&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38622&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38622&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=38622&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38622&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=38622&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=38622&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38622&r=support
Expected behavior: http://bugs.php.net/fix.php?id=38622&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=38622&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=38622&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38622&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38622&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38622&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=38622&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38622&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38622&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38622&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=38622&r=mysqlcfg