Stoppt die Vorratsdatenspeicherung! Jetzt klicken & handeln!Willst du auch bei der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien:

six demon bag

Wind, fire, all that kind of thing!

2008-10-13

How to Beat Windows Software into Submission

A great deal of Windows software requires to be run with administrative or at least power user privileges for no good reason. That's a Bad Thing™, because it enables any user to compromise the system. Most of this software can, however, be talked into running with a normal user's privileges. The problem is usually that the program attempts to write temporary data, configuration data and other stuff like that to places a normal user can't write to. In this article I will describe the procedure I usually apply when having to deal with reluctant software.


  1. Read the documentation. Sometimes the vendor has documented what must be done to use the software as a normal user. Do not ask me why they don't act on their own advice, it's beyond me, too.
  2. Whenever you have installed software, run it once with an administrative account. Not only to test if it runs at all, but also to give it the chance to write some final global configuration. I continually fail to see why that data cannot be written during the installation process, but there is software out there that does this kind of crap.
  3. Try to run the software with a normal user account, play around with it a bit (especially do some configuration), close and re-open it. If you experience any problems during this procedure (e.g. program does not start, error messages pop up, configuration changes are gone after re-opening, etc.), it usually means the program is trying to write data someplace a normal user does not have write access to. Use Sysinternal's Regmon and Filemon to find out what and where (if you have Windows 2000 SP4 or Windows XP SP2 and later use Process Monitor instead). Log in with a normal user account and start Regmon and Filemon via runas. Leave the Include filter set to "*", monitor the system for a while and add the programs that generate log entries to the Exclude filter bit by bit. Set the Highlight filter to ACCESS DENIED. Run the program in question and see if there are any access violations. Here are two examples for Regmon and Filemon filter settings (in Process Monitor you'd simply add exclude entries for each process name in the Filter dialog):
    Regmon Filter: Include:*, Exclude:Regmon;LSASS;CSRSS;WINLOGON;explorer.exe, Highlight:ACCESS DENIED
    Filemon Filter: Include:*, Exclude:winlogon;Regmon;LSASS;explorer.exe, Highlight:ACCESS DENIED
    Another option is to Include only the program executable, but if the program calls other programs to carry out its tasks, you will miss access violations generated by those programs.
  4. If any access violations show up in Regmon or Filemon, assign the proper access rights to normal users. Filesystem ACLs (Access Control Lists) are set through Cacls/XCacls or the Security settings tab in a file/folder's properties dialog. Registry ACLs are set through Regedt32 (in Windows XP this functionality has been incorporated into Regedit) or a command-line tool like SetACL.
  5. Repeat the aforementioned steps until no further errors show up.

If a program needs to create a file or a subfolder in a specific directory, you should grant create files in this folder only permissions to normal users and full access on files and maybe subfolders to CREATOR-OWNER instead of granting change or full access permissions on the folder itself to normal users.

In some folders users should not even be allowed to create files (e.g. %SystemRoot% and all of its subfolders). If a program requires users to be able to create files or folders in any such location I suggest to replace it with software that is not written by braindead monkeys. Same applies to software that requires normal users to be able to write to the registry somewhere outside HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE\SOFTWARE. However, if write access to HKEY_CLASSES_ROOT is required, you can work around that by creating the keys and values in question in HKEY_CURRENT_USER\Software\classes, since user settings will override global settings. Create the keys and values in HKEY_USERS\.DEFAULT\Software\classes as well, if you want these settings to be applied to all newly created users.

Sometimes it is useful to export Regmon and Filemon logs to text files and use Excel (or similar software) for further analysis. Here's a simple Excel macro to import these text files, do some formatting and save them as Excel sheets.

Posted 11:27 [permalink]