Why is Sandboxed code secure?

Posted: March 31, 2011 in SharePoint 2010

So recently I was asked a question and annoyed enough with not knowing the answer to look it up and boy did it go into a rabbit hole.

The question…”What is it exactly that makes sandboxed code so secure?”

Simple enough question and I went into the OOB nice and clean wrapped discussion on how it is isolated but realized all the while that if I took a shovel and tried to dig under that, well I could not tell you REALLY why it was. So up came Bing and into the world I went.

So WHY is it “safe”

1. Process isolation – Unlike farm solutions which go into the solution store, sandboxed code is uploaded into the solutions library on your site collection. The includes your wsp (which is SharePoint term for a cab file), which holds your solution files. When executed, sandboxed code is run, not in your IIS Application pool that your web app runs in, but instead in a separate process (the Sandboxed worker process – SPUCWorkerProcess.exe) and each sandboxed solution is further isolated in its own thread within that process. For this reason it cannot access dlls from OTHER sandboxed processes or any DLL that is not GAC’d. It cannot even see them.  Your sandboxed code is about as isolated as it can get in a SharePoint environment.

2. CAS – Yep code access security. All your sandboxed processes on the entire farm are governed by their own CAS which is hidden in the 14 hive. This CAS restricts the access sandboxed code can have even further. Were I braver and having a virtual I could stand hosing I would really like to play with this and see how much security can be overriden by manipulating this file or just give the Sandboxed code Full trust. It is NOT, I repeat NOT supported by MS but hey, that’s what virtuals are for.

3. DLL deployment – So I started asking folks “where do my sandboxed dlls go?”. Once folks started thinking about it, well…nobody really knew. Some blogs claimed the GAC, some claimed the bin, some simply assumed they go a a better place…so where is it, c:\programdata\Microsoft\Sharepoint\UCCCache. They will be put into subfolders within that directory corresponding to user sessions. When the users session ends, they will be removed from that folder unless they are reloaded by another session within a specific period of time.

4. Selective scalability – Yeah this barely works into the realm of “safe” but I would also consider this because one thing you can do is set WHERE SharePoint executes sandboxed solution code in a farm. You can set if it runs on the server that requests it (default), or set it to use processor affinity. You can also disable the Sandboxed code service on some servers pushing SharePoint to load balance on secondary – perhaps dedicated servers. In terms of “safe” this means you can push execution of your code to a server that maybe is not directly serving content to end users and limit the impact a sandbox gone berserk can have on the farm.

Pretty cool stuff. Now, I do have to say pretty much all this can be found on MSDN (http://msdn.microsoft.com/en-us/library/ee539417.aspx and http://msdn.microsoft.com/en-us/library/gg615461.aspx).

I anyone out there has the bravery to mess with the trust levels of the sandboxed code, please feel free to comment back on this thread. I would love to see how far you can much with that without killing a farm. Like I said though it is NOT supported by MS so I would recommend doing this only for experimentation purposes on only on a virtual.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s