This is related to the this question and the answer maybe the same but
I'll ask anyways.
I understand that we can start managed executables from the network from .NET
3.5 SP1 but what about assemblies loaded from inside the executable?
Does the same thing apply?
You have been able to load Assemblies from the network at leasst from .NET 2.0. I have used this on a previous project. The only thing to watch is the size of the assembly and the number and size of the dependancies that it is loading.
If you are using a seperate AppDomain, then you will need to take special consideration of the dependancies.
My understanding is yes, you're trying to load an untrusted module into your local app domain.
Related
I'm currently working on a .NET 5.0 Blazor Server project that imports and utilizes user-uploaded .NET assemblies (in either DLL or NUPKG form). Currently, these assemblies are loaded using Collectible AssemblyLoadContexts which, if I understand correctly, is a major security hazard for both my user-base and the server itself. That said, I'm searching for methods that can sandbox the inclusion/execution of those assemblies. The main concerns that I can think of are:
Access to sensitive system information/environment variables
Access to processes
Access to internet (sockets/clients)
File System access
but I probably haven't thought about a plethora of other factors I should be aware of.
How could I achieve such feat?
ps: The server runs on a Linux machine and all uploaded assemblies must be valid architecture-irrelevant .net5 or .netStandard2.0 in order to be loaded.
I am facing a strange problem with packaging an assembly for Azure worker role. I am building a sample Azure cloud application having one website and a worker role. I am referencing a third party assembly, myasm.dll in both website and worker role project. The myasm.dll has dependency on two other assemblies. When I build the project all three(myasm.dll and two dependent assemblies) third party assemblies are getting copied to bin directory for both website and worker role projects. So far so good.
When packaging is done for worker role, off the three third party assemblies, only two assemblies are included in the package, the third assembly is not included. Strangely enough, packaging of Website project includes all three assemblies. I created one more worker role to test the behavior but same behavior was seen again.
Is this a known issue or something? Any help is highly appreciated.
I use VS2012 Update 4.
Package will not include any dll which is not explicitly used in your project or referenced. I know this problem occurs when you do not use type explicitly in a your project(old bug raised - with won't fix status)
I guess your best option is to explicitly reference those missing dll's (see here) or try to add dummy usage of types from missing dependencies.
I have 2 plugin assemblies which are sharing the proxy code generated by crmsvcutil. The proxy code file tends to be large(14+ MB) and it seems to bloat up the Plugin Dlls.
I am thinking that it might make sense to offset the proxy code into a separate assembly and deploy it to the GAC on the CRM server.This would reduce the bloat in the plugin assemblies and also reduce the memory footprint since only a single copy of the proxy code would be loaded into the process space.
The question is, how does CRM load individual plugin assemblies?
Are they all loaded into the same process space or are they loaded into separate app domains?
If they are loaded into separate app domains then it defeats the purpose of having a separate assembly containing the generated proxy code since it will be loaded separately into both app domains anyways.
Any thoughts appreciated
I can't answer your question directly, but if bloat is the problem, there is a number of extensions to the crmsvcutil out there that will allow you to filter the generated class file to only include the entities that you wish to play with. I've done so before (at a previous company and have since lost the source. Grrr!) with success, achieving a class file of a few kb rather than mb.
A quick google search took me to... http://fourbusyxrmarchitects.wordpress.com/2012/08/09/filtering-the-list-of-early-bound-classes-generated-by-the-code-generation-tool-crmsvcutil-for-crm-2011-2/
I have a fairly stable server application version that's been deployed for nearly a year at dozens of customers.
One new customer recently setup the application and is getting the following error:
System.MethodAccessException: Attempt by security transparent method
[SomeMethod] to access security critical method [SomeOtherMethod]
failed.
Both SomeMethod and SomeOtherMethod are methods in assemblies that I wrote, that are built against .NET 4, and that are running inside a Windows Service. If it makes a difference, SomeOtherMethod does reference a type from a 3rd party assembly (EntLib 4.1) built against .NET 2.0. Looking at the code for EntLib 4.1, I do see that they use both SecurityTransparent and APTC attributes, but this has never caused issues at other clients.
These assemblies were upgraded from the .NET 2.0 CLR, but a long time ago. This exact code is running on other customers just fine, and I'm not explicitly using the APTC attribute nor am I using the SecurityCritical attribute anywhere.
This leads me to the conclusion that it's a configuration issue or perhaps .NET Framework patch issue. Has there been a patch released for .NET that would cause this breaking change? Is there a configuration setting some where that enforces this type of check which is off by default but that my customer may have enabled?
One last point. My service utilizes SSRS RDLCs to generate PDFs. Due to some changes in .NET 4, I must force the service to use the legacy security policy via the following config:
<runtime>
<NetFx40_LegacySecurityPolicy enabled="true" />
</runtime>
For more details on why I need to do this, see this stackoverflow post: Very High Memory Usage in .NET 4.0
The important point is that I do this at all my other customers as well. Only this one customer is having issues.
Sigh, the patterns and practices employed by the Microsoft Patterns And Practices team that's responsible for the Enterprise libraries are pretty deplorable. Well, the exception is accurate, you cannot call a method that's decorated as "I'll definitely check security" from code that's decorated with "Meh, I won't check security so don't bother burning the cpu cycles to check it". Which scales about as well as exception specifications as used in Java. CAS is incredibly useful, but diagnosing the exceptions is a major headache and often involves code that you don't own and can't fix. Big reason it got deprecated in .NET 4.
Editorial done. Taking a pot-shot at the problem, you need to find out why CAS is being enforced here. The simplest explanation for that is that the service doesn't run in full trust. The simplest explanation for that is that the client didn't install the service on the local hard drive. Or is generally running code in don't-trust-it mode even on local assemblies, a very paranoid admin could well prefer that. That needs to be configured with Caspol.exe, a tool whose command line options are as mysterious as CAS. Pot-shooting at the non-trusted location explanation, your client needs to run Caspol as shown in this blog post. Or just simply deploy the service locally so the default "I trust thee" applies.
Editing in the real reason as discovered by the OP: beware of the alternate data stream that gets added to a file when it is downloaded from an untrusted Internet or network location. The file will get a stream named "Zone.Identifier" that keeps track of where it came from with the "ZoneId" value. It is that value that overrides the trust derived from the storage location. Usually putting it in the Internet zone. Use Explorer, right-click the file and click "Unblock" to remove that stream. After you're sure you can trust the file :)
I was facing the similar issue while running the downloaded WCF sample from http://www.idesign.net/ while using their ServiceModelEx library.
I commented out the below line in AssemblyInfo.cs in ServiceModelEx project
//[assembly: AllowPartiallyTrustedCallers]
and it worked for me.
In case it helps others i post my solution for this issue:
1) On the AssemblyInfo.cs, removed/commented the [assembly: SecurityTransparent] line.
2) The Class and the Method that does the actual Job was marked as [SecuritySafeCritical], in my case establishing a Network Connection:
[SecuritySafeCritical]
public class NetworkConnection : IDisposable
{
[SecuritySafeCritical]
public NetworkConnection(string networkName, NetworkCredential credentials)
{
.............
}
}
3) The Caller Class and Method was market as [SecurityCritical]:
[SecurityCritical]
public class DBF_DAO : AbstractDAO
{
[SecurityCritical]
public bool DBF_EsAccesoExclusivo(string pTabla, ref ArrayList exepciones)
{
....
using (new NetworkConnection(DBF_PATH, readCredentials))
{
....
}
}
}
In my case it was an issue when I managed a NuGet packages in the solution some package overrides System.Web.Mvc assembly version binding in main web site project. Set back to 4.0.0.0 (I had 5.0 installed). I didn't change notice the change because Mvc v4.0 was installed and accessible via GAC. Set back
I have a standard DotNetNuke installation that I am developing some modules for.
Every time I update one of my modules, it updates that module's DLL in the DotNetNuke installation's bin folder.
Despite the fact that I am not touching the main DotNetNuke DLL, it seems that IIS is either reprocessing every DLL in the folder, or doing some other majorly time consuming task because it is taking at least 10 seconds to load any page after I recompile the single module's DLL.
For comparison, if this module were running outside of DotNetNuke, it would load in under a second.
Is there some way to get around this delay?
Whenever you change a .dll in the bin folder ASP.Net will restart the application. Application startup does not necessarily mean anything gets recompiled, though some of the modules may get recompiled, but probably not until they are used. A bunch of the time goes into inspecting/loading all of the assemblies in the bin folder, and executing all the application startup code. Removing any unneeded modules will help reduce the start up time, as those assemblies will no longer need to be loaded.
Mitchell Sellers has a great document titled DotNetNuke Performance Configuration Best Practices download here several of the recommendations will help reduce startup time, and it is a generally a good reference on how to effectively deploy a DNN site.
Per comments, it sounds like the usual Asp.net site compile happening. Here are some good links covering the details.
msdn: ASP.NET Compilation Overview
msdn: ASP.NET Web Site Precompilation Overview
Rick Stahl has a good write up