-4

I'm writing a program to immediately track and kill when a user runs command prompt (and regedit if that's possible). This is to stop users from running commands I would rather they not have.

I've already written code that sees when a process is launched and checks its name using QueryFullProcessImageName. The issue is that if someone were to rename command prompt then I could no longer detect it via process name. The way I detect command prompt is currently "\cmd.exe" but clearly this is not very secure.

Posted below is what I have for the code. I removed all error checking for brevity. Please let me know if you need more clarity. Thanks!

TCHAR exeName[MAX_PATH];
DWORD exeNameSize = MAX_PATH;

//the pid comes into the function as a parameter
HANDLE handle = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION, 0, pid);

if (handle) 
{
    if (QueryFullProcessImageName(handle, 0, exeName, &exeNameSize))
    {
        tstring name = exeName;

        /*
          badProcs would contain the path identifiers such as
          "\\cmd.exe" or "\\regedit.exe".  This detection is
          what I want to make better.
        */

        for(int i=0; i < badProcs.size(); i++)
        {
            if(tstring::npos != name.find(badProcs.at(i)))
            {
                if(TerminateProcess(handle,0))
                    OutputDebugString(_T("Process should be dead\n\n"));
            }
        }
    }
    CloseHandle(handle);
}

Some additional information: The reason I'm writing this is to control what goes on in other desktops. I want to make it so that when a user launches a different desktop (via whatever proprietary program) I can control whether or not they have access to items which present the biggest security holes to the system. Given that I only want to control actions does on the other desktop, I do not want to change settings for fear of corrupting data outside of the target desktop. Is corruption not something to worry about?

I'm only interested in controlling a proprietary desktop, not mucking with what users do in their own space. Essentially the separate desktop is for corporate work, and I want to be able to limit what people can do with company information, etc.

adveres
  • 1
  • 2
  • 4
    Why can't you just remove the users' permission to run those executables? – Chriszuma Oct 27 '11 at 16:49
  • There are more ways to run apps than the command prompt. And please don't try to intercept NtCreateProcess ... – tenfour Oct 27 '11 at 16:51
  • Even if I did, what if they copied in another cmd.exe via USB or something. That file would have no permissions changed. – adveres Oct 27 '11 at 17:10
  • Preventig the user from using their computer in whatever way they see fit is just evil. – John Dibling Oct 27 '11 at 17:18
  • @JohnDibling While that is true, limiting users from doing silly things is what a lot of security software does. I'm not arguing with you, but sometimes it's better to not give them the tools to hurt themselves. In addition, this would be enforcing a corporate policy saying "don't run command prompt on your laptop!" – adveres Oct 27 '11 at 17:24
  • 1
    Oh wow, where can I get a copy of this fantastically wonderful program? – David Heffernan Oct 27 '11 at 17:25
  • What are you trying to protect against by restricting access to command line? Guess what - nothing that the the command line is capable of is unique to the command line. Worst case, they'll write a 10-line program to accomplish the same. It's a sad security model if it restricts access to functionality by prohibiting its front-ends. – Seva Alekseyev Oct 27 '11 at 19:27
  • 1
    You don't need to write your own code. Search on "software restriction policy" or (on Windows 7) AppLocker for information on using the built-in solutions. The important thing to remember is that you need to whitelist, not blacklist: create policy describing which executables the user is allowed to run, not which executables they are not. – Harry Johnston Oct 27 '11 at 22:53

2 Answers2

10

Don't. Windows has internal means for that. Read up on the policy editor, and/or file access control.

If you're admin and the "user" is not, policy (or simple ACL) will do the job; if the "user" is also an admin, they'll be able to defeat your program fairly easily.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
  • Based on [this Stack reply](http://stackoverflow.com/questions/592448/c-how-to-set-file-permissions-cross-platform) I cannot be sure that ACL will work if the user has a non-NTFS partition. Also, I'm only interested in controlling what goes on in the different desktop and do not want to funk with a user's regular permissions or files. Does this make sense? – adveres Oct 27 '11 at 17:27
  • 1
    @adveres: You cannot be sure that someone simply terminates your application using the TaskManager - unless of course you use ACL to prevent them using the TaskManager. I agree with Seva and John: Just don't go down that road, it's evil (and won't work on top of that). – Robin Oct 27 '11 at 17:53
  • 1
    So are users admins or not? If they're not, where would they get a non-NTFS partition from? – Seva Alekseyev Oct 27 '11 at 19:28
  • More specifically, the built-in solutions are Software Restriction Policy or (in Windows 7) AppLocker. – Harry Johnston Oct 27 '11 at 22:55
1

The best way to block the command prompt and registry editor is through the windows registry. These work even if you copy the executables to a different location.

Both the Registry Editor and Command Prompt cannot be run if the registry keys are set:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\DisableRegistryTools

or for the whole machine

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\System\DisableRegistryTools

Setting this to 1 will disable regedit, and setting to 0 will enable it.

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\DisableCMD

(the local machine varient works here as well).

Setting this to 1 will disable the command prompt and batch files, setting this to 2 will only disable the command line, and setting to 0 will enable it.

Justine Krejcha
  • 1,235
  • 17
  • 27