Configuring Windows to run applications with Standard User privileges

1. Why should we separate privileges and configure permissions?

        The separation of privileges is a computer security and antivirus protection fundamental. Usually, all the users log on to the computer with individual accounts that belong to either of two categories: administrative, which are designed to configure and maintain the system; and standard, designed for everyday work. Administrators can do anything they want — install and remove software, update device drivers, infect computer with a virus etc. Standard Users are able to surf Internet, work with documents and e-mail, watch movies. But it is impossible for them to break anything in a system.

        What makes their work that safe? Standard users have limited rights and can not install or re-configure programs, thus making it impossible to screw up the system. Neither to infect it with a virus. The thing is that computer malware is not a voodoo magic but just a computer software like other programs.

        Nevertheless, it is not rare situation when we need to deal with security-unaware programmers. The software they develop requires much more rights than it is really needed, thus making it unable to launch that software with standard user privileges, or the software runs with severe errors. It is very hard to force particular developers having writing their software in a security-aware manner. But in most cases we can solve such  issues by finding out and re-configuring the necessary permissions by using Windows Auditing.

2. So what is Auditing and what way does it help us?

        Windows OS auditing subsystem is designed to track down and log particular system events. Usually, we do not enable auditing for all types of events. Basically, not all the events are of interest for us; and even more, auditing puts system under the heavy load. Then, we only configure a part which tracks down file and registry access.

        What makes the security-unaware program different from normal software?

• it requires changing data in protected folders (Windows, Program Files);
• it requires changing data in protected Registry keys (for instance, HKLM\Software).

        Auditing allows us to find out exactly what protected folders or files and registry keys are required for some particular program to run. We only extend permissions for those folders and keys, not giving away the control over the whole system and not assigning everyone the administrative rights.

        Auditing is built-in into all Microsoft Windows NT OSs: Windows XP/Vista/7, Windows Server 2000/2003/2008. Unfortunately, Windows Home versions lack Auditing policy configuration interface, thus making it too hard to configure.

3. What configuration should be performed?

        In order to enable Auditing, log on to a target computer with administrative permissions, click Start → Run and launch gpedit.msc MMC console. In a Computer Configuration node, open Windows Settings → Security Settings → Local Policies → Audit Policies folder:

        Double-click Audit object access policy and select Failure checkbox. This policy enables file, folder and Windows Registry access attempts that were ended in a failure. Actually, this is true, we are only interested in an unsuccessful object access attempts. The program in question is unable to read, write or delete something when running with standard user permissions.

        Simply enabling policy option is not enough. It is also required to designate what folders exactly are to be watched. Usually, security-unaware software requires an excessive access to the system drive (C:\) and system registry (HKEY_LOCAL_MACHINE\Software). Right-click the system disk, select Properties and switch to the Security tab. Click Advanced → Auditing → Add and select some standard user account which will be used for testing purposes:

        Since it’s not possible to guess what access type exactly was denied, we configure auditing for failed Full Control access, which includes all possible access types. Any failed access attempt performed by test user against the required folder and subfolders will result in an event added to the log.

        Additionaly, it is a good idea to configure a watchdog for system Registry failed access attempts. Click Start → Run and launch regedit.exe. Right-click HKEY_LOCAL_MACHINE\Software key and select Permissions command. Doing it same way as for a system disk, assign Auditing of Software key for failed Full Control access attempts of the same test user account:

        It is highly possible that there will be too much events listed, so it is a good idea to configure the Security event log settings. To do this, click Start → Run and launch eventvwr.msc MMC console. Right-click the Security event log, select Properties and set the following options:

• Maximum Log Size = 65536 KB (for workstations) or 262144 KB (for servers);
• Overwrite events as needed.

        Frankly, the log sizes recommended above are not calculated by any formula but are to be choosed depending on particular computer usage experience.

4. Finally, how do we make it working?

        Log on to the required computer with a test user account. Note the clock and try to launch ”badly behaving” program once. If the program does not start or shows some particular error message during the startup, skip the next step. If it is launched successfully, do all that is needed for the permission-related issue to occur.

        When faced the limited permission-related program behavior, stop testing it, note the clock and switch to the Security event log viewer. To do this, switch to the user account with administrative permissions, click Start → Run and launch eventvwr.msc MMC console. You can also launch the event viewer with elevated privileges not leaving the user session by right-clicking the console shortcut and selecting Run As command.

        It is highly possible that not only the required events are logged. Right-click Security log and select the View → Filter command. Consider the following events to be filtered:

• Event Source: Security;
• Category: Object Access;
• Event Types: Failure Audit;
• Event ID: 560;
• User: Имя тестового пользователя.

        Watch through the filtered event list taking into account the following information fields inside each record and previously noted time (from the time the program was launched till the issue appeared):

• Image File Name. The name of executable requiring elevated privileges. This should be the name of the tested program executable;
• Object Name. The name of folder, file or Registry key which an access was denied to;
• Accesses. A set of requested privileges.

        The program may request multiple access types simultaneously — for example, Read+Write+Delete. However, the single missing permission causes the whole request to be denied. Check with the currently assigned to that object permissions to see which one is not listed and could be a problem for the program.

        Extend permission list according to the needs of examined software. In case the program requires new file creation in a protected folder, add Read+Write NTFS permission for Users and Modify for Creator/Owner system group to that folder only. In case the program requires changing all of the content in some particular folder, use Modify NTFS permission for Users instead. Avoid adding Full Control for Users since this permission includes Change Permissons permision, which should only be accessible for Administrators and operating system itself (SYSTEM user account).

        Make an excessive testing on how the modified permission structure influenced the examined software behavior. When all the procedures are complete, consider disabling Auditing — the monitoring may consume significant part of system resources and fills up the event log with unneeded records. Document new permission structure — it is highly possible for this information to be required for you or other systems administrators in the future.