I have a program based on WPF in C#, and I want to remove the user's privileges for debugging the application (SeDebugPrivilege) (in Release mode at least). What's the best way to go about this ? I've found a couple of ways of doing it in code that requires unsafe calls to unmanaged code. I'd prefer to do this either purely in C# or, even better, via an application manifest or some other means that prevents the user from having the SeDebugPrivilege at all during the execution of my application. Is there anyway of declaring a Windows group and revoking the privilege for the whole group ? The motivation for this is part of a push to better secure my application by following the principles of least privilege. There are other privileges I'm sure I'd like to remove at some point later, but I'd like to worry about one thing at a time.
-
Are you attempting to prevent the user from debugging the application, or performing debugging activities *using* your application? – Iridium Nov 14 '12 at 22:27
-
@Iridium It sounds to me like the idea is to mitigate the impact of any vulnerabilities in the application. If the application has `SeDebugPrivilege` then it can do what it pleases, and that includes any malicious code that happens to creep in one way or another. – Roman Starkov Nov 14 '12 at 22:31
-
@Iridium I had intended the former. I had mistaken the purpose of the SeDebugPrivilege. I guess at this point, I'd like to know how to revoke a user or group's use of the SeDebugPrivilege – Alex Marshall Nov 14 '12 at 22:35
-
AFAIK there is NO way to do this without any native/unsafe code... removing this privilige won't have much effect IMO... what exactly is your goal ? perhaps there are other options... – Yahia Nov 14 '12 at 22:47
-
`SeDebugPrivilege` is not "the ability to debug programs" -- it is "the ability to debug programs *owned by other users*". Even a limited user is perfectly allowed to debug processes they own. – Billy ONeal Nov 15 '12 at 06:07
1 Answers
I think you may be misunderstanding the effects of privileges such as SeDebugPrivilege
. Whilst you can certainly remove the privilege from process token using AdjustTokenPrivileges
, this does not prevent the application from being debugged, it instead prevents the application itself from performing certain debugging actions. This could however be used to reduce the impact of possible vulnerabilities in your application by preventing it from affecting other processes via means that require the privilege.
Note that by default, a user can debug an application they have started themselves even without SeDebugPrivilege
, so even if run as a non-administrative user (which by default will not have the privilege at all) this will not prevent the application from being debugged.
There are of course many examples of applications that attempt to detect whether a debugger is attached and they do so with varying levels of success. At best you will be able to make it harder to debug the application but you won't be able to prevent it entirely if you are running on the user's machine.
You could perhaps periodically check System.Diagnostics.Debugger.IsAttached
, and take some action if the value is true
, but it would be relatively straightforward to overcome for someone determined to debug the application.

- 23,323
- 6
- 52
- 74
-
Anything can be debugged. If you really had to, you could just remove the debug attach blocking code. That's how pirate software work, they patch the license checking function to return "activated" or whatever. It may take longer for certain applications, but EVERYTHING can be debugged. Even your bootloader with bochs – Cole Tobin Nov 14 '12 at 22:53