让我们猜测在我的应用程序中我允许使用 LoadLibrary WIN32 加载 DLL。因为我不知道该 DLL 的代码，所以它可能是恶意的。所以我的问题是，有什么方法可以告诉Windows对该DLL应用一些限制（例如磁盘访问、读取密码或其他潜在危险的数据读/写访问）？
这样，每当 DLL 代码尝试访问磁盘时，就会生成异常或调用的方法返回一些错误。避免使用 javascript 或其他脚本解释代码而不是编译和编译代码可能会很有用。链接&高效的一个。
是否存在我可以使用的类似机制？
ex1：RestrictAccess( GetProcAdress( ... ), size ); // 通过代码访问内存
ex2: thread1.loadLibrary( file );
限制访问（线程1）； // 通过线程访问
等...
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 );
RestrictAccess( thread1 ); // by thread access
etc...
发布评论
评论（4）
没有简单的解决方案（例如可以调用 API 来限制进程或线程）。
IE 在保护模式下（在 Vista 和 Windows 7 上）的作用是以较低的速度将插件加载到单独的进程中 完整性级别。在低完整性模式下运行的进程对系统资源的访问较少，并且与较高完整性级别的进程更加隔离。您还可以在文件系统对象和注册表项等内容上设置 ACL，以控制低完整性进程是否可以访问它们。这限制了他们所能造成的伤害。这是沙箱或（取决于您定义的严格程度）虚拟化的一种形式。
要做好这项工作需要做很多工作。低完整性流程可能会受到如此严格的限制，以至于它需要帮助才能完成很多事情。当 IE 启动保护模式进程时，它会为其提供一个与主 IE 进程进行通信的通道。然后，插件可以通过此通道发出请求来执行诸如更改注册表和写入文件系统之类的操作。 IE 会考虑请求，如果它确定应该允许该请求，则 IE 进程将代表插件执行此操作。
另一种方法（可用于补充沙箱）是要求 DLL 使用有效证书进行签名。签名可以让您对 DLL 有更多的信任，因为证书标识了责任方。该签名还可以确保没有人篡改 DLL。
另一种方法是挂钩所有要限制的操作系统 API 调用。有库用于此目的，但该技术依赖于一些操作系统黑客技术这可能会在任何更新时中断。这个想法是用你的一些代码创建一个进程，为你想要限制的每个 API 设置一个钩子，然后加载不受信任的代码并执行它。如果 DLL 调用挂钩的 API（例如，
CreateFile），您的代码将被调用，并且它可以决定是返回错误还是将调用传递给真正的操作系统 API。这很困难，因为您必须挂钩的 API 数量可能会很大。另外，如果 DLL 知道这是正在使用的技术，它可以采取一些措施来破坏它。最后，您可以通过根本不运行本机代码来实现真正的沙箱。您无需加载不受信任的 DLL，而是加载已编译为某种中间形式的代码并对其进行解释。这使您的解释器可以完全控制程序可以执行的操作。这也很难实现，并且大大降低了性能。
如果您要运行不受信任的代码，则必须经历这些极端情况。
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.
典型的解决方案是只允许使用可沙箱编译的解释语言或字节代码的插件（例如Lua）。某些操作系统做出了此类限制（例如 iOS 和 Android），但我不相信您在加载本机 Windows DLL 时会发现此类功能。
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.
可以使用模拟在每个线程的基础上增加权限，但永远不会减少权限（因为不受信任的代码始终可以执行
RevertToSelf）。较低权限的最小单位是进程。是的，有一个 API：
CreateProcessAsUser。您可以使用管道将数据传输到不受信任的进程或从不受信任的进程传输数据。或者您可以使用 DCOM 调用 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.
您可以从 DLL 文件中读取名称。这样您就可以确定它链接到哪些其他 DLL 以及它使用哪些外部函数（例如 Windows API）。您可以创建一个白名单，只允许从该 DLL 调用您的函数，这样您就必须为插件可以合法访问的所有内容创建包装函数。
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.