Avoid an application to have access to disk operations

Let's guess in my application I allow to load a DLL with LoadLibrary WIN32. As i don't know the code of that DLL it can be malicious. So my question is, there is some way to tell windows to apply some restrictions to that DLL ( for example disk access, read passwords, or other potential dangerous data read/write accesses ) ?

That way any time that the DLL code is trying to access disk, an exception is generated or the method called return some error. It could be useful to avoid using javascript or other scripts interpretated code instead of compiled & linked & efficient one.

Do exists any kind of similar mechanism that i could use?

ex1: RestrictAccess( GetProcAdress( ... ), size ); // by code memory access

ex2: thread1.loadLibrary( file ); Restric开发者_高级运维tAccess( thread1 ); // by thread access

etc...

There is no simple solution such as an API you can call to restrict a process or a thread.

What IE does in protected mode (on Vista and Windows 7) is to load plug-ins into a separate process at a low integrity level. Processes running in low integrity mode have less access to system resources and are more isolated from higher integrity level processes. You can also set up ACLs on things like file system objects and registry keys that control whether or not low-integrity processes can access them. This limits the amount of damage they can do. This is a form of sandboxing or (depending on how strictly you define it) virtualization.

It's a lot of work to get it right. A low-integrity process can be so restricted that it needs help to do much of anything. When IE launches a protected mode process, it gives it a channel for communicating back to the main IE process. The plug-in can then make requests via this channel to do things like make registry changes and write to the file system. IE considers the requests and if it determines that it should be allowed, the IE process will do it on behalf of the plugin.

Another approach (which can be used to complement the sandboxing) is to require the DLL to be signed with a valid certificate. The signing allows you to have a little more trust in the DLL, because the certificate identifies a responsible party. The signature also ensures that nobody has tampered with the DLL.

Yet another approach is to hook all of the OS API calls you want to restrict. There are libraries for this, but the technique relies on a bit of OS hackery that could break on any update. The idea would be to create a process with some of your code that sets up a hook for each API you want to restrict and then loads the untrusted code and executes it. If the DLL calls a hooked API (e.g., CreateFile), you're code will get called instead, and it can decide whether to return an error or pass the call onto the real OS API. This is difficult because the number of APIs you have to hook can be huge. Also, if the DLL knows that this is the technique in use, there are things it can do to subvert it.

Finally, you can do true sandboxing by not running native code at all. Instead of loading an untrusted DLL, you load code that's been compiled into some intermediate form and interpret it. This gives your interpretter complete control over what the program can do. This is also hard to implement, and it greatly lowers performance.

These are the extremes you have to go through if you're going to run untrusted code.

The typical solution is to only allow plugins in an interpreted language or byte code compiled that can be sandboxed (e.g. Lua). Some operating systems make such restrictions (e.g. iOS and Android), but I don't believe you'll find such features when loading a native Windows DLL.

Privileges can be increased on a per-thread basis, using impersonation, but never decreased (since the untrusted code can always do RevertToSelf).

The minimum unit for lower privileges is the process. And yes, there's an API for that: CreateProcessAsUser. You could use pipes to transfer data to/from the untrusted process.

Or you can use DCOM to call methods of an object in a DLL. You can specify the credentials, and then the OS will do the work of setting up a helper process with those credentials and marshaling the data back and forth.

You can read the names from the DLL file. This way you can be sure what other DLL's it is linked against and what external function (Windows API for example) it uses. You can create a whitelist to only allow your functions to be called from that DLL, this way you have to create wrapper function to everything the plugin can legally access.