Jaa

Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0

  • Artikkeli

The MSDN Magazine site just put up my article, Do You Trust It? Discover Techniques for Safely Hosting Untrusted Add-Ins with the .NET Framework 2.0, as a preview of their November security issue.  In the article I cover various techniques for safely hosting Add-Ins which may or may not be trusted, starting from the basic Assembly.Load technique and moving onto sandboxing, transparency, and AppDomainManagers.  I'd say it's worth a read, but then I might be a little biased as well :-)

This issue also features an article by Mike Downen covering the various enhancements to CLR security in v2.0.

November 2005 MSDN Cover

Comments

  • Anonymous
    October 04, 2005
    Shawn-

    Great article. Do you have a complete set of sample code?

    Regards-
    Eric

  • Anonymous
    October 13, 2005
    Hello-

    Do you have a complete sample solution that describes your techniques? It would be great to see how everything fits together.

    Regards-
    Eric

  • Anonymous
    November 04, 2005
    Releasing a sample here is a great idea -- I'll look into doing that.

    Glad you liked the article!

    -Shawn

  • Anonymous
    February 15, 2006
    Shawn,
    Great article. Thank you.
    One thing keeps bothering me. Where would you define IAddIn interface in the case of separating addins by subdirectories? The assembly where interface is defined has to be present in each add-in directory, right?
    So, as Eric noticed it would be nice to have a sample code.

    Thanks,
    Alex

  • Anonymous
    February 22, 2006
    A simple sample is definately a todo item :-)

    In the subdirectory case, you might want to consider putting IAddIn in the GAC.

    -Shawn

  • Anonymous
    April 26, 2006
    I am trying to convert a 1.1 sandboxing application to use the techniques in this article for 2.0.  The existing application uses AppDomain.ExecuteAssembly to call the client code in the sandbox AppDomain, but this doesn't seem to work with the 2.0 simple sandboxing API.  I get a security exception for the demand of a FileIOPermission to read the file containing the client assembly.  I tried giving MyComputer zone in the top-of-stack evidence parameter to CreateDomain, while the grant set corresponds to the Internet zone, but that didn't help.  (The code that calls ExecuteAssembly has full trust.)  It seems like the 2.0 Framework is changing the grant set in the new AppDomain before loading the client assembly.  Does this mean I can't use ExecuteAssembly to load client code in a sandbox?

    Thanks,
    Yishai

  • Anonymous
    April 27, 2006
    Funny you should mention it, this is the next topic on my todo list on the whiteboard.  I'll probably do a full write up on Monday, but basically you should make sure the AppBase of the domain points to the location of the EXE you're trying to run and use ExecuateAssemblyByName instead of ExecuteAssembly.

    -Shawn

  • Anonymous
    April 29, 2006
    Thanks a lot, great tip.  It now works, except that I had to add an unrestricted UIPermission to the grant set.  This is not a problem for this particular application, but could be for others.  Is there a way around this?

    -- Yishai

  • Anonymous
    May 01, 2006
    Hi Yishai,

    Console applications require unrestricted UI permission in v2.0 of the CLR (http://blogs.msdn.com/shawnfa/archive/2005/06/06/425804.aspx).  I'd bet that this is the problem you're running into.

    -Shawn

  • Anonymous
    January 04, 2007
    In the MSDN article you mention to use a seperate AppDomain (c.q. application base), either one for all add-ins or one per add-in. Is there an upper limit for the number of AppDomains that can be created per process and/or system? How many AppDomains are typically running on a system?

  • Anonymous
    May 02, 2009
    The comment has been removed

  • Anonymous
    May 21, 2009
    Which part of the code would you be looking for?  How to use the AppDomainManager? -Shawn