We are developing an online test application for XSLT processors in ASP.NET, however, I'm a bit worried about how to limit the vulnerabilities of our system. Is it possible with .NET to sandbox a third party unmanaged or managed application? It should:
not be allowed to start any other process by any means or vulnerability;
have no access to other existing processes on the system;
be killed when it takes too much processing power or memory;
work with both managed and unmanaged external applications;
should not be able to access system calls
Some applications have a managed API, but that doesn't suffice because than I need to run it in the same processing space as ASP.NET with all potential risks (stack overflow, memory exceptions, buffer overflow). I'm not aware whether .NET offers sandboxing of unmanaged applications.
We currently execute the external program in a console with specific affinity and monitor this, but that doesn't feel like a right or even closely safe approach.
You can execute managed code within an AppDomain which can be configured to provide some level of protection, however as soon as you allow unmanaged code to run, its pretty much got access to everything the user its running under has access to.
I'm pretty sure you can prevent unmanaged/unsafe code being executed within an AppDomain though.
Related
My problem that i'm using 32 bit application so i have limited memory usage.
I need to execute piece of code (to use some data base) that need lot of memory in parallel and i thought to run this code in different processes (If I'm not mistaken each process get approximately 2 GB's of memory usage) another advantage is any crash on process won't affect the application.
I wondering if Appdomain really don't share memory with the main application?
If so, this solution will help me?
Executing Code in a Separate Application Domain Using C#
App domains does use main application memory however once the app domain is unloaded all the memory is reclaimed, however creating and unloading of the app domain has a performance cost and if the app domain contains lots of static objects it can actually inflate the size of the process as static objects are tied to the app domain and not the process. See Understanding Application Domains.
If the memory intensive part of your application runs for a limited amount of time, you can benefit from this approach, however running in a separate process will allow you to use more memory, especially if this is a x64 process, but you may need to somehow communicate between the two processes.
You can also look at reducing the memory pressure of your application by pooling and reusing objects that consume a lot of memory.
See Difference between AppDomain, Assembly, Process, and a Thread
An AppDomain isn't usually run in a seperate process to my knowledge; I don't think this would help you there.
Why not spawn a new process directly?
I have a windows service written in C# using Selfhost technology that act like a little server that can handle some webservice's requests.
This server need to be run continuosly and actually has no policy of autoreload or explicit memory cleanup. In some tests i have noticed that after few days (a dozen) it become "instable" (what i mean is that it starts to fail accesses to DB and the memory allocated by process drammatically increase).
What i would to ask is if it's a known issue of this technology that need to be reload or a clean up memory afert certainly time, or if i need to investigate better in my code.
I smell of memory leak but it seems too strange because i only use managed objects.
How can I watch a specific process to know what resources it uses at runtime (such as sounds, pictures, cursors, and registry keys)?
I have to do that programmatically using C# (e.g. using the Windows API or any third party library).
Any help is appreciated. Thanks.
I would stick to performance counters. There are ones for
Memory
GDI Handles (Bitmap, Font, ...)
Handles (File, Registry Key, Event, Mutex, Socket, Process, ...)
Windows (User Objects)
The exact type cannot be determined by using performance counters but it can give you a hint if you are leaking something. If you want to know which handles you can use handles from SysInternals which will give you a nice per process output which you can parse.
If you want to fix the handle leaks then you need to use a debugger (Windbbg) and use the !handle extension to start tracking all aquire/release call stacks for each handle so you can get latter a statistics which handles have been allocated but not freed yet.
Your question is a little to broad because the exact tactic to nail a resource leakage is dependant on the nature of the leak. EasyHook is a good solution to track all resource aquire/release calls and record them automatically.
If you want to automate a debugger with e.g. C# you can use http://wmemoryprofiler.codeplex.com/ which is bascially a managed wrapper around Windbg which even allows you to self debug your application.
When you just want to learn the principles how to get your hands on scattered data for various resources you should read the code of Process Hacker.
Do you want the GDI objects or Win32 handles?
Win32 handles can be obtained using the NtQuerySystemInformation WinAPI function. You can find the C# code for handle-related tasks in these ProcessHacker sources: http://sourceforge.net/p/processhacker/code/HEAD/tree/1.x/trunk/ProcessHacker.Native/Windows.cs
EasyHook will allow you to intercept Windows API calls. Here's a simple example for all file accesses made by a process. Registry calls also seem to be supported.
I have an unmanaged C++ exe that I could call from inside my C# code directly (have the C++ code that I could make a lib) or via spawning a process and grabbing the data from the OutputStream. What are the advantages/disadvantages of the options?
Since you have source code of the C++ library, you can use C++/CLI to compile it into a mixed mode dll so it is easy to be used by the C# application.
The benefit of this will be most flexible on data flow (input or output to that C++ module).
While running the C++ code out of process has one benefit. If your C++ code is not very robust, this can make your main C# process stable so as not to be crashed by the C++ code.
The big downside to scraping the OutputStream is the lack of data typing. I'd much rather do the work of exporting a few functions and reusing an existing library; but, that's really just a preference.
Another disadvantage of spawning a process is that on windows spwaning a process is a very expensive (slow) operation. If you intend to call the c++ code quite often this is worth considering.
An advantage can be that you're automatically more isolated to crashes in the c++ program.
Drop in replacement of the c++ executable can be an advantage as well.
Furthermore writing interop code can be big hassle in c#. If it's a complicated interace and you decide to do interop, have a look at c++/cli for the interop layer.
You're far better off taking a subset of the functions of the C++ executable and building it into a library. You'll keep type safety and you'll be able to better leverage Exception Handling (not to mention finer grain control of how you manage the calls into the functions in the library).
If you go with grabbing the data from the OutputStream of the executable, you're going to have no visibility into the processes of the executable, no real exception handling, and you're going to lose any type information you may have had.
The main disadvantage to being in process would be making sure you handle the managed/native interactions correctly.
1)
The c++ code will probably depend on deterministic destruction for cleanup/resource freeing etc. I say probably because this is common and good practice in c++.
In the managed code this means you have to be careful to dispose of your c++ cli wrapper code properly. If your code is used once, a using clause in c# will do this for you. If the object needs to live a while as a member you'll find that the dispose will need to be chained the whole way through your application.
2)
Another issue depends on how memory hungry your application is. The managed garbage collector can be lazy. It is guaranteed to kick in if a managed allocation needs more space than is available. However the unmanaged allocator is not connected in anyway. Therefore you need to manaully inform the managed allocator that you will be making unmanaged allocations and that it should keep that space available. This is done using the AddMemoryPressure method.
The main disadvantages to being out of process are:
1) Speed.
2) Code overhead to manage the communication.
3) Code overhead to watch for one or other process dying when it is not expected to.
I have a managed Windows application that loads a managed C++ component that uses AfxLoadLibrary to load a third party component if present on the client machine. Once detected, I'm unloading the component using AfxFreeLibrary in an attempt to lower the working set of the managed parent application.
The call to AfxFreeLibrary is successful (verified using Process Explorer), but no memory is freed up. Is this due to the nature of a managed application, or is there a way to free up this process space?
I'm not looking for alternative ways to tackle this problem in general, since the code is already in production, rather I would like to find out if the approach of unloading is worthwhile.
It should do, you can prove it by writing a pure native app and seeing the working set.
However, working set is the size of the memory required to run the app, so if the code used by the dll can be swapped out, then the working set will not be reduced - Windows doesn't count it as part of the working set.
If the dll has private memory allocated to the process, that cannot be swapped, then that does count and will reduce the working set.
so the answer is that it depends. Its not guaranteed to make any difference, and if the dll is not used, then it will have been swapped out and isn't part of the current working set. You might as well not bother unloading it, unless you like to keep things tidy.
The only way to reduce the working set is to have your app use less memory. As its a .NET app, chances are you don't have much control over it at all (as the GC will make its own mind up about how much memory is 'active' and needed in the working set)