>> Hi!
>>
>> Thoughts?
>>>
>>
>> This is a fine idea, however actually doing it is not that easy. Note
>> that knowing which function is "safe" is pretty hard, but that's only a
>> start.
>> Plugin code, for example, can call functions outside plugin context,
>> while passing all kinds of arguments - is it safe or not? It depends
>> on the context - e.g. plugin may need access to the database -
>> directly or through some API - but that opens the door to various SQL
>> injections and other mischief, etc. etc.
>> So while the idea is fine, designing a working sandbox is a very
>> complicated task. That said, if you have any ideas - you're welcome to
>> propose.
>
>
> The sandbox I'm considering would only impact the ability to directly call
> internal functions. The idea rests on the hope that the framework or CMS
> provides a security model that protects the integrity of their own
> environment. The framework can for example hand off whatever state
> variables are deemed appropriate and necessary to a plugin. The framework
> can make public whatever methods are appropriate and necessary. However,
> the framework can't currently limit the direct calls to internal functions
> (without parsing the PHP source and it's dependencies), which could allow
> the plugin developer to circumvent the security policies of the framework.
>
> Indeed, the complexity is extreme, even for the limited scope of this idea.
> And, avoiding complexity for the developers using the sandboxed version
> would be difficult, too.
>
> I'm wondering if it would be easier to allow constants representing entire
> classes of functionality. For example:
>
> include_restricted('file/path', $whitelist = array('SANDBOX_FILE',
> 'SANDBOX_PDO', 'SANDBOX_MYSQL', 'SANDBOX_SOCKET'));
>
> If an error was raised because an included file required additional access,
> the error message could detail the exact constant(s) that would have to be
> whitelisted for the include to be allowed.
>
> Thank you for the feedback, Stas. The questions and concerns raised in this
> discussion help considerably.
>
> Adam
I've seen a simple "safe" code evaluator put together using token_get_all. I'm
certain that you could create an include_restricted() function in userland
using a similar system: walk through the tokens looking for anything forbidden
(this will be tricky, because there are a lot of nooks that things could hide,
like superglobals), then if everything looks good include the file. Use a
caching system of some sort to improve performance and eliminate redundant
checks.
I seriously doubt that this would ever get implemented in the core though. PHP
has been moving away from this sort of thing (and for good reason). Attempting
a "one size fits all" sandbox in the core just doesn't make any sense.
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
