Building a simple security sandbox on Windows 2008 by automatically creating & restricting user accounts?

Question

I want to build a fairly simple security sandbox for an application hosting service - the main goals are thus:

1. Applications running "in" the sandbox cannot install anything onto the system outside of the directory the executable is running in.
2. Access to the system in general is denied (registry access, et al.).
3. Access to the file system (even read-only) outside the directories specified is explicitly denied. It will be a .NET application running inside the sandbox, so I am uncertain as to whether this will incidentally deny the runtime & or core dependencies?

The plan I have presently is to build the sandbox in .NET using the System.DirectoryServices namespace by:

• creating a new semi-permanent user account for each launched instance
• deriving it from the guest class of users to deny wide access to the system
• then specifically granting read & write access to a finite number of directories where the application should be running.

Can anyone see any particular flaws in this plan? And is user account security sufficient to satisfy the above requirements securely? We're using a piece of commercial software right now to handle this (which is more comprehensive in it's sandboxing); but it is insufficiently automatable for our business - hence the desire to build it into our core automation software.

Answer 1

This is not a real sandbox - if the user can run malware with guest permission on the server or change anything on the server - he might be able to take over the server eventually. I'm not talking about regular apps, but and app that is designed to break your "Sandbox".

if you want a good sandbox, I think you should either use vmware (or similar) (with no access to the host machine) or use a 3rd party like this one Sandboxie which was build and tested for enough time, and I hope enough security expert validate it for it's safety.

What is the main purpose of the sandbox you're creating ?

with vmware like solution - the process of the app runs in the context of the guest machine and no the host machine so it much more difficult to access the host this way.

using slick OS setups (like win 2k8 server core) you can have many guest os on a single win2k8 machine that hosts them...