> Hi Peter,
>
> In Windows security, normally, there are 2 types of security checks:
> 1. The group membership in the process token. This is used while
> performing DACL check regarding securable objects, such as NTFS file
> objects, various kernel objects, including Process object, Thread
> object etc.... The DACL setting on these securable objects determines
> whether the process can open the objects for certain permissions.
> 2. The priviliedges in the process token. This is normally checked by
> certain high priviledge APIs.
>
> So, we should concern not only the priviledge, but also the DACL
> setting and group memeberships.
>
> Debugger is a normal application which uses Win32 debugging service to
> monitor/control the debuggee process. The key point is whether the
> debugger can call OpenProcess API to open debuggee process object for
> full access rights. This is controlled by DACL setting on the process
> object.
>
> By default, the process object will only grant Full Trust permission
> to its running account and running account direct group. So if a
> normal user called "Alice" created a process, even Administrators can
> not open this process. For this reason, OpenProcess API provided a
> backdoor for the debugger applications. That is, if a process token
> has SeDebugPrivilege, it can call OpenProcess API to obtain Full Trust
> permission to any processes. That is why debuggers(which enables
> SeDebugPrivilege internally) can obtain Full Trust to all processes in
> the system. Please refer to the "remark" section of OpenProcess API in
> MSDN.
>
> By default, only Administrators group is assigned SeDebugPrivilege, so
> normally debuggers run best under Administrators group. This can be
> configured in secpol.msc ->Local Policies->User Rights
> Assignment->Debug Programs.
>
> Why your Power Users account can still debug applications without any
> problem? This because you are pressing F5 to launch the debuggee,
> which causes the debuggee to run under the same account as the parent
> debugger process. The debugger and debuggee run under the same
> account. So the DACL setting on the debuggee process object will grant
> Full Trust to parent debugger by default. But your debugger can not
> attach to another process running under a different account, because
> the DACL setting on that process object will not grant permission to
> your account.
>
> I do not think there is an official documented list of priviledges for
> debugger. This is because priviledges are not the only checking
> information in Windows, the DACL of certain securable objects may also
> fail the debugger operations. This occurs if the debugger is accessing
> certain Admin registry or directories. This depends on the debugger
> operations. Anyway, VS2005 takes care of the LUA and performs well
> under user account: "Develop and Debug logged in as Least Privilege"
> http://msdn2.microsoft.com/en-us/vstudio/aa700978.aspx
>
> However, debugging Asp.net is a problem, because Asp.net runs under
> another account by default, so we need SeDebugPrivilege to debug it. I
> am not an Asp.net expert, but, you may get some good advice between
> about how to debug the Asp.net with Least Privilege:
> "TIP: Least Privilege and ASP.NET Debugging"
> http://blogs.msdn.com/gduthie/archive/2004/11/17/258856.aspx

> Regarding the JIT setting error, do you get the error listed in the
> link below?
> http://msdn2.microsoft.com/en-us/library/ssc8234s(VS.80).aspx
>
> Yes, this is by design. If you are using RegMon or Process Monitor to
> monitor the VS2005 registry access during changing the JIT setting,
> you will see that the registry keys VS2005 modifying only grant write
> permissions to Administrators and Local System accounts. That's why
> Power Users can not modify this JIT setting in VS2005 IDE.