我正在编写的应用程序要求执行在主机系统上执行的潜在恶意代码。该代码仅与stdin，stdout和stderr进行交互，不应尝试与文件系统或网络进行交互。
我通过防火墙规则限制了网络访问，并通过NetUserAdd使用CreateProcessWithLogonW创建的无特权用户运行流程来限制文件系统访问。最后，我将进程分配给限制内存和活动进程的作业对象。
这在Windows 8上运行良好，但是当我在Windows 7计算机（部署平台）上测试时，我发现尽管以管理员身份运行，但AssignProcessToJobObject因拒绝访问而失败。从this回答，我发现了
CreateProcessWithLogonW作为子进程执行新进程 次要登录服务，具有制定流程的结果 即使作业对象，也可以转义任何作业对象成员资格/限制 不允许突破。
此外，Secondary Logon服务自动创建自己的新作业对象并将新进程分配给它。
因此，虽然这适用于允许嵌套作业对象的Windows 8，但它在Windows 7及更低版本上失败。
同样的答案建议在Secondary Logon服务下生成一个代理进程，并使用它来生成带有CREATE_BREAKAWAY_FROM_JOB标志的进程。但是，在尝试此操作时，代理的CreateProcess调用将失败并显示5 ERROR_ACCESS_DENIED，因为辅助登录将代理置于其中的作业不允许发生突破。
如何将在其他用户下创建的进程分配给Windows 7上的作业对象？
答案 0 :(得分：1)
好的，我已经做了一些实验，并且可以确认CreateProcessWithLogonW()和CreateProcessWithTokenW()都将新创建的进程放入作业对象中。
但是，CreateProcessAsUser()没有。所以这可能是最好的解决方法，尽管它确实需要“替换进程级令牌”权限。您可以从已具有此权限的上下文（即，配置为作为本地服务或网络服务运行的服务）运行代码，也可以将该权限授予将用于运行代码的用户帐户。
另请参阅Invisible Things Lab的博客中的Shattering the myths of Windows security（特别是链接的白皮书），其中介绍了在受限用户帐户中运行潜在恶意代码的各种问题。
答案 1 :(得分：0)
在我的场景中，我只需要为进程分配一些限制（内存限制和活动进程限制），而不是进一步使用生成进程的作业对象。由于所有CreateProcess变体（CreateProcessWithLogon，CreateProcessWithToken等）似乎最终产生了将登录过程分配给作业的二级登录服务，我推断只要我能够掌握服务的工作，我可以施加任何我想要的限制。
调用OpenJobObject来获取Logon Service的作业对象会很方便，但后者会创建一个空名称的作业。因此，我使用枚举Logon Service的句柄，并通过IsProcessInJob检查哪个作业句柄是正确的。这听起来很脏，当然，我不确定它是否太可靠了，但是在this发布了关于sysinternals的帖子（按照this建议的答案），找到合适的手柄并不是太难了。请注意，此步骤需要SeDebugPrivilege才能生效。
之后，只需通过JobObjectExtendedLimitInformation在工作中强加SetInformationJobObject即可。为了更好的衡量，我还添加了一个JobObjectBasicUIRestrictions，至少让攻击者更难一点。
就是这样！
然而，正如@Harry Johnston所说，这种形式的沙盒是 not impervious 。但在我的情况下它足够好。