New Security Model: Moving to a Better Sandbox

re: New Security Model: Moving to a Better Sandbox

Justin — Mon, 26 Mar 2012 04:37:48 GMT

If it is complex maybe you can make it simpler or explain better in the documentation.

Removing it altogether?!!! makes things a lot more complicated. How is this simpler?

Just keep it as an option like turning the setting flag on. Why remove it????

re: New Security Model: Moving to a Better Sandbox

Oliver — Fri, 03 Dec 2010 14:04:43 GMT

Dear Andrew,

Probably the old security logic with CAS was complex, and it took a while to understand, but once you figured it out, it was flexible, and could be configured in a lot of different ways.

You could grant specific permissions to specific assemblies by rolling out an MSI package. Once this was done within our company, it was no problem for us to create a signed ActiveX, which would run in the browser but still access local files.

Now with the new logic you have either full trust or the predefined set of permissions as decided by the hosting application. Only two possibilities, instead of millions of different combinations. And as there are no settings for this within the typical host IE - you are stuck with the default ones. For us this means, that in .NET for, we can not implement our ActiveX any longer.

Also, IMHO in an ideal world, assemblies should define what permission they would like to get, but the real permissions granted should be decided by system administrator. This is now definitely not possible any longer, as the CASpol tool is obsolete.

IMHO, you went in the wrong direction...

Oliver

re: New Security Model: Moving to a Better Sandbox

Asen — Fri, 04 Dec 2009 13:17:10 GMT

I wonder why the assemblies loaded from byte array by the MBR object in the sandboxed appdomain inherit the permission set from the loader assembly. I expected their permission set to match the appdomain’s. What's the technique for having partially trusted dlls loaded dynamically from byte[]?

re: New Security Model: Moving to a Better Sandbox

Stefan Wenig — Thu, 18 Jun 2009 00:21:59 GMT

Hi Andrew,

thanks for the clarification. I disagree with your conclusions, though.

I understand the reasons for the change and I agree with your decision, but I think it's a mistake to remove the option to opt out of the sandboxing model altogether. This leaves us with no option to use managed code for browser controls in situations where we need full control.

Sure, the app needs to have control, but your SandboxActivator could provide a nice standard way to let the user configure exceptions. (The app could still decide to disable that.)

Silverlight is superior in many situations, granted, but Silverlight code always runs in a sandbox. (This is an interesting topic on its own. Compare this to Moonlight, which can run code inside the sandbox, but also on top of the normal Mono runtime - what would be your Desktop CLR. That allows for code that can run in the browser, but the same code can run with full permissions. A nice option for enterprise apps that can run online or disconnected, with a local DB and everything, or need to interact with desktop apps like Office. And the compatibility story is obviously much smoother than Silverlight/WPF. But I digress.)

re: New Security Model: Moving to a Better Sandbox

Andrew Dai [MS] — Wed, 17 Jun 2009 20:03:41 GMT

Hi Stefan,

The gist of the new CAS policy model is that everything unhosted runs as fully trusted, and hosts get to decide what the security policy is for their hosted code. Applications will have full trust unless they’re hosted, and there’s no way for the hosted, partial trust apps to elevate out of the host’s sandbox. To allow that would remove from the host’s complete control of its own security policy, which is one of the things we set out to provide for this release.

Specifically for IE hosting of managed controls - this is no longer supported in .NET Framework 4, as Silverlight is superior in terms of user and developer experience for browser-based managed code. Note that your control will continue to work as it did as long as it’s not recompiled against .NET Framework 4.

Thanks,

Andrew

re: New Security Model: Moving to a Better Sandbox

Stefan Wenig — Mon, 15 Jun 2009 11:32:27 GMT

Hi Andrew

thanks for your response. We have a managed IE control that allows an HTML-based app to interact with the desktop. We use CAS Policy to give this control (or rather, its assembly) full trust.

Wouldn't it be nice if the SandboxActivator could automatically read some standard configuration section from the from app.config file? This way, users would not depend on every single app to include some exception mechanism, and app authors wouldn't have to do the work?

(Then of course you'd have to make sure that every critical app, like IE, uses SandboxActivator, or provide some easy way to access that config from unmanaged code.)

Stefan

re: New Security Model: Moving to a Better Sandbox

Andrew Dai [MS] — Fri, 12 Jun 2009 23:31:28 GMT

Hi Stefan,

It is no longer possible for partially trusted code to be elevated to full trust the way it was in the previous model. You’re pretty much right on – each host needs to provide its own interface for trusting assemblies. It is very simple to administer exceptions to the partial trust permission set with the CreateDomain API that Cristian describes.

The CreateDomain API creates an AppDomain where there are two trust levels – full trust and partial trust. Everything loaded into the domain is partially trusted unless it’s on the full trust list – the ‘params StrongName[] fullTrustAssemblies’ argument in the overload.

This, coupled with the HostSecurityManager features provided (http://msdn.microsoft.com/en-us/library/system.security.hostsecuritymanager_members(VS.100).aspx ), provides the host the ability to define its policy for hosted code.

We are indeed working with the various teams that host partially trusted code internally. What particular IE scenario are you interested in?

Thanks,

Andrew Dai

MS Common Language Runtime Security Program Manager

re: New Security Model: Moving to a Better Sandbox

Tanveer Badar — Fri, 12 Jun 2009 20:37:23 GMT

What you call overrides at three places are actually overloads. I didn't bother reading rest of the article after those mistakes.

No more global exceptions?

Stefan Wenig — Fri, 12 Jun 2009 11:39:54 GMT

This sounds like the right thing to do. After all, the CAS policy stuff was not only overcomplicated, but also underdocumented and buggy. (What a combination!)

I'm really looking forward to the new model, but there's one thing that I'd like you to clarify:

With the current model, it is possible to elevate an assembly to full trust, even if it is loaded in, say, IE. So although IE explicitly uses APIs to load its controls in a partial trust zone, we can give it full trust without IE even noticing.

With the other options, I believe that each and every application would have to manage exceptions to their partial trust policy, right? And if the application doesn't have configuration options to do so, there is no way to work around it, right?

While this was a real PITA, at least it was possible after some trial&error.

In case my assumptions are correct, do you have any idea how various app teams at MSFT are dealing with this? Are you working with them? (I'm particularly interested in IE)

Thanks,

Stefan