Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6686 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13880 invoked by uid 1010); 23 Dec 2003 09:58:19 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 13849 invoked from network); 23 Dec 2003 09:58:18 -0000 Received: from unknown (HELO mail.tiscali.cz) (213.235.135.72) by pb1.pair.com with SMTP; 23 Dec 2003 09:58:18 -0000 Received: from wbp1 (213.235.189.246) by mail.tiscali.cz (6.7.018) id 3FB96935009695DE; Tue, 23 Dec 2003 10:53:58 +0100 Message-ID: <001c01c3c93a$5f5814c0$d300a8c0@webpropag.cz> To: "Wez Furlong" , "Christian Schneider" Cc: "Lukas Smith" , References: <006501c3c6f2$9002e540$d300a8c0@webpropag.cz> <3FE494B9.7090501@cschneid.com> <000b01c3c7e2$cc9ec780$d300a8c0@webpropag.cz> <3FE5EC3B.9060506@cschneid.com> <01c601c3c80a$173eddd0$8802a8c0@obsidian> Date: Tue, 23 Dec 2003 10:51:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: [PHP-DEV] Extending PHP with sandbox capability ? From: prasek@silesia.cz (=?iso-8859-1?Q?ing . Martin_Pr=E1sek?=) ----- Puvodn=ED zpr=E1va -----=20 Od: "Wez Furlong" Komu: "Christian Schneider" ; "ing.Martin = Pr=E1sek" Kopie: "Lukas Smith" ; Odesl=E1no: 21. prosince 2003 22:33 Predmet: Re: [PHP-DEV] Extending PHP with sandbox capability ? > A real sandbox mechanism is not likely to be implemented, at least, > not for a very long time. >=20 > Having needed something like this myself for a commercial project > in the past, I settled on a "user-space sandbox" using the tokenizer > extension to parse the code and filter out unsafe functions, rewrite > "new" statements to prevent instantiation of certain classes, rewrite > access to global variables and so on. I know, there are probably some ways how to do that, but it required a = lot of efford and are far far to be simple and effective. You can, for example, do like this: Create on the fly appropriate wery = restrictive php.ini file (safe mode, lot of things disabled etc), then = call (via backtick for example) cli version of PHP , feed it with = restrictive ini settings,serializabled variables and the untrusted = code. And then grab its output. It will probably work and will be = probably secure enough if well designed, but adds _a lot of = overhead_....=20 I think PHP should have a simpliest ways for sandboxing code, without = needs to build circus tent with bears, lions and even clowns for this. =20 May be in my originally proposed function, Create_Sandbox() adding a = list of new ini settings for sandboxed code and/or list od = enabled/disabled PHP modules and functions will do this job. So = application designer can set .ini parameters and enabled PHP modules, = that he will allow for use inside a sandbox. I thing this should be = secure enough,especially with recomended approach "disable everything, = enable ONLY things you need". But I do not know how much work and time can take to add ability to = temporairy disable certain moules or functions "on the fly" or = temporairy change .ini settings and temporairy start a secure mode for = integrating to zend engine. PS: Execuse my bed english, it is not my native language. Martin Pr=E1sek aka NTPT.