xen dev blog

Having a look at php runkit extension. It's got some nice features including a built in sandboxing system for other php code. Very interesting.

 

So this is quite promising:

Contents of testfile.txt is: hi there blah lblah

and for output I'm getting:

Even cooler, I can remove the dangerous function redefinition functions using themselves:

Notice that we get an error on line 21 because runkit_function_remove itself has been removed already and therefore can no longer be called.

So the idea is to wrap all the dangerous file IO functions at the bootstrap stage of the xen execution stack then let xen go about its business like nothing's happened, meanwhile secretly its actually living in a Truman show bubble (sandbox)

 

enable 2fa and send me a fb message to prove you're still in control of your sythe account (which I think you are, IPs look right) and we'll arrange something on monday when I have time to take you through our cluster fuck development system

 

This is cool. Print the function table. Wonder how long it would take to loop it and destroy every last function in the function table? Lets find out.

 

Honestly I've given up on giving estimates. That's why I'm doing this blog so people can see why it's taking time. There's a lot of non trivial problems I've encountered which are mainly due to the size of the site. There's no instruction manual for running or migrating a site like this. None of the software except maybe haproxy is really designed for running sites of this size. You just have to solve problems as they arise.

I'm hoping to have CDT exploring the new production cluster within the week.

 

Ha nice:

Output:

It's quite practical to erase the entire function table. That it happens in half a microsecond suggests that internally its just nulling the pointers in the function table which is exactly what it should be doing.

This is really good. Essentially it means I can "clean" php of all the functions xen doesn't use, and redirect the ones it does use through my own code. A complete sandbox if you will. Definitely considering using this in production.

 

Looking forward to your help. Enjoy the rest of your trip

 

Cool so I'm leaving it here for the night:

I have set auto_prepend_file on our php instances to point at my sandboxing script. The sandbox will wrap all the PHP IO functions that Xen uses with lazy load of the blob database script. When the path matches certain patterns the IO calls will be translated to blob database transactions. That's the idea anyway. Very curious to see how it goes in practice. When the sandbox has finished doing its mucking it'll also remove all the functions that Xen doesn't / shouldn't need access to. This adds extra security. If (php) code injection occurs via some zero-day then the attacker will be severely limited in the php functions they can call.

Next post will be monday

 

Back at it today. Have a few things to clean up on the existing production system before I get to deving: One of our upstream providers is having extended planned downtime so I have to move a production server before I start.

 

Patched a bug in the banner bidding system on production. Moving the image server to a new datacenter presently to avoid extended downtime.

 

Alright running some backups first before migrating, which will take some time so I'll get back to working on the sandbox script now

 

how to experience sythe in 4D:
1/ place 4 dicks in your mouth
2/ open sythe

 

working on sythe sandbox which is described in previous posts

currently hooked all the php IO functions and I'm sifting through to redirect essential read/write IO from the file system to the blob system