Building a simple security sandbox on Windows 2008 by automatically creating & restricting user accounts?
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.
Building a simple security sandbox on Windows 2008 by automatically creating & restricting user accounts?
===

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.