Forcing Command Line Arguments

Sometimes you'd like to force an application program to use some command line arguments (also called command line switches or command line options). For example you may prefer all executions of FireFox to include the -safe-mode command line argument. Unfortunately implementing such a thing in the Windows world is hard.

Problems Under Windows

If your users are cooperative and just want some way to get the right command line arguments without a lot of work, you can manipulate the properties of "shortcut" icons to supply the arguments. But if your users are not cooperative and look for ways to bypass your command line arguments, it unfortunately may be difficult to solve the problem on a vanilla Windows system.

There are many different ways to launch an application under Windows. And although you can apply your command line arguments to some of them, other ways allow your command line arguments to be circumvented. Each of the following methods of launching an application is amenable to adding command line arguments. (But the command line arguments must be added to each method separately - there is no shared method for remembering command line arguments.)

• desktop icon
• taskbar icon
• Start->Programs menu
• BATch script

On the other hand, the following methods of launching an application in Windows have no provision for allowing you to even "suggest" command line arguments:

• Start->Run
• File Explorer double-click (no command line arguments possible)
• CMD Box/DOS Box
• Start command

(Newer versions of Windows have a feature that goes by the generic name shim, which may be useful in some similar cases and may partially invalidate the statements above. The writer has no detailed experience with this feature, and does not know whether or in which cases the feature may be able to provide functionality similar to forcing command line arguments.)

Similar Solutions

*nix-like

Under *nix-like Operating Systems, forcing an application to use particular command line arguments is straightforward. Remove the permissions that allow the target users to launch the application directly. Then create a "shim" that can be launched by the target users which will in turn launch the application. (The shim is conventionally a *nix "shell script", which is very easy to create, debug, and modify.) Allow the target users to execute the shim, but not to modify it. Now the only way target users can launch the application is through the shim, which specifies the desired command line arguments and which the target users cannot modify.

As the special privileged user which the target users can't access, set the SETGID permissions bit on the "shim". When a target user executes the shim, it will internally change its identity to the Group of the special user that set up the shim, which then has the permissions to execute the desired application.

If a target user attempts to launch the application directly, they will be told "permission denied". If instead a target user launches the shim, it will in turn launch the desired application but only with the command line arguments the owner of the shim specified. If a target user attempts to modify the shim, they will be told "permission denied". And if a target user makes their own copy of the shim so they can modify it, it won't have the right permissions and won't be able to launch the desired application.

(One could do the same thing with the SETUID permissions bit, but this isn't recommended as it's more of a security risk than SETGID. In any case, to minimize security risk, the owner and group of the shim should be something other than "root" or the administrators main group.)

Windows-style Operating Systems have no analog of SETGID permissions, so this procedure is unfortunately not directly transferrable.

.PIF

Forcing an application to use particular command line arguments could be done with some 16-bit DOS applications being run under Windows by specifying the desired command line arguments in a .PIF file. But it was too easy to circumvent that even for some 16-bit DOS applications, and it doesn't work with native Windows applications.

What To Do

To have most users most of the time use your command line arguments when launching an application, modify every one of these items:

1. Shortcut in Start->Programs (if the application is installed per-machine -- otherwise it may be too hard)
2. Shortcut icon on desktop
3. Shortcut icon in taskbar (if it exists)
4. BATch script files that launch the application (if they exist) (consider creating one if the application is frequently installed per-user rather than per-machine)

However this isn't even mildly tamper-proof. It's trivial in Windows to launch an application without using any of the mechanisms you modified above. It's quite possible a creative student/user will figure out how to bypass your command line arguments, then tell other students/users, and soon most of your student/user population will be bypassing your desired command line arguments.

If the application's altered behavior isn't very noticeable or annoying, you may be able to get by with this method. But if you can't tolerate any user ever bypassing your command line arguments, give it up and look for some other overall design instead. This information is very probably correct as of January 2006. But proving a negative is quite hard; there's always a small possibility this is incorrect.

Future Possibilities (Exercises for the Reader:-)

Theory suggests forcing a Windows application to use particular command line arguments may indeed be possible (but may not be easy enough to be included in an administrator's bag of reasonable tricks). The following are prime candidates for further investigation:

• Marry *nix-like capabilities to Windows (cygwin, MKS Toolkit, etc.). Then use those additional capabilities to implement something like the SETGID shim.
• Find a commercial/shareware/freeware product that provides this capability. For example you could add the shareware tool called NTsu to your systems. Its shims that simulate *nix SETUID behavior will contain the password you want to hide. Even though the password is encrypted, a determined cracker will be able to recover it, and might even use the tool to break into other parts of systems.
• Compile a shim that simulates the change of permissions internally. Such a shim would probably have to be compiled code and would probably not respond appropriately to permissions or ownership changes after it was installed. Most likely use either the CreateProcessAsUser(...) or SHCreateProcessAsUserW(...) Windows API calls. The shim would have to contain a password, which of course should be encrypted. There would have to be a separate shim for each desired application, potentially leading to a maintenance nightmare. This would probably essentially be coding your own NTsu so you don't have to pay the shareware fee. But it would be subject to all the same limitations - in fact, your knockoff would probably be even less secure than NTsu.
• Somehow use either the RPC or the COM capabilities of Windows to effect the necessary change of permissions.