使用CreateProcessWithLogonW的作业控制 [英] Job Control with CreateProcessWithLogonW
问题描述
我正在编写的应用程序要求执行可能在主机系统上执行的潜在恶意代码.该代码仅与stdin，stdout和stderr交互，并且不应尝试与文件系统或网络交互.
我已通过防火墙规则限制了网络访问，并通过以NetUserAdd和CreateProcessWithLogonW创建的非特权用户身份运行进程来限制文件系统访问.最后，我将进程分配给限制内存和活动进程的作业对象.
这在Windows 8上可以正常工作，但是当我在Windows 7机器(部署平台)上对其进行测试时，我发现AssignProcessToJobObject失败，尽管以管理员身份运行，但访问被拒绝.从此答案中，我发现
CreateProcessWithLogonW作为该子进程的子进程执行新进程 辅助登录服务，其结果是完成该过程 逃避任何作业对象成员资格/限制，即使作业对象 不允许脱离.
此外，辅助登录服务会自动创建其自己的新作业对象，并将新进程分配给该对象.
因此，尽管这在允许嵌套作业对象的Windows 8上起作用，但在Windows 7及以下版本上却失败.
相同的答案建议在辅助登录"服务下生成一个代理进程，并使用它通过CREATE_BREAKAWAY_FROM_JOB标志生成该进程.但是，尝试执行此操作时，座席的CreateProcess调用失败，并显示5 ERROR_ACCESS_DENIED，这是因为辅助登录"将座席放入的工作不允许脱离.
如何在Windows 7上将在另一个用户下创建的进程分配给作业对象?
好，我做了一些实验，可以确认是否 CreateProcessWithTokenW()将新创建的进程放入作业对象.
但是， CreateProcessAsUser()不.因此，尽管它确实需要替换进程级别令牌"特权，但这可能是最好的解决方法.您可以从已经具有此特权的上下文(即，配置为作为本地服务或网络服务运行的服务)的上下文中运行代码，也可以将特权授予将用于运行代码的用户帐户.
另请参阅打破Windows安全的神话在Invisible Things Lab的博客(尤其是链接的白皮书)中，描述了在受限用户帐户中运行潜在恶意代码的各种问题.
An application I'm writing requires the execution of potentially malicious code to be executed on a host system. The code only interacts with stdin, stdout, and stderr, and should not attempt to interact with the filesystem or network.
I've restricted network access through a firewall rule, and filesystem access through running the process as an unprivileged user created through NetUserAdd with CreateProcessWithLogonW. Finally, I assign the process to a job object that limits memory and active processes.
This works fine on Windows 8, but when I tested it on a Windows 7 machine (the deployment platform), I found that AssignProcessToJobObject failed with an access denied, despite running as administrator. From this answer, I found that
CreateProcessWithLogonW executes the new process as a child of the Secondary Logon service, which has the outcome of making the process escape any Job Object membership/restrictions even if the Job Object did not allow breakaway.
Furthermore, the Secondary Logon service automatically creates its own new Job Object and assigns the new process into it.
So while this works on Windows 8 which allows nested job objects, it fails on Windows 7 and under.
The same answer suggests spawning an agent process under the Secondary Logon service and using it to spawn the process with the CREATE_BREAKAWAY_FROM_JOB flag. However, when attempting this, the agent's CreateProcess call fails with 5 ERROR_ACCESS_DENIED, because the job Secondary Logon puts the agent in does not allow breakaways.
How can I assign a process created under another user to a job object on Windows 7?
OK, I've done some experimentation, and can confirm that both CreateProcessWithLogonW() and CreateProcessWithTokenW() put the newly created process into a job object.
However, CreateProcessAsUser() does not. So this is probably the best workaround, though it does require the "Replace a process level token" privilege. You can either run the code from a context that already has this privilege (i.e., a service configured to run as local service or network service) or you can grant the privilege to the user account that will be used to run the code.
See also Shattering the myths of Windows security at the Invisible Things Lab's blog (and in particular the linked whitepaper) which describes various issues with running potentially malicious code in a limited user account.
这篇关于使用CreateProcessWithLogonW的作业控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
