Privilege Manager

The product is implemented as a true Group Policy extension that allows administrators to attach permission levels to applications, and is free when managed from a local GPO. Applications, users and computers are targeted using standard Group Policy conventions and per-setting filters. Simply specify the application and which security groups should be added to and/or removed from the process token when the application is launched.

Three common scenarios
There are three common scenarios that typically require application-level security in order to properly satisfy the principle of least privilege.

Restricted Users:
End-users are not entitled to local administrator or even power user status. However there is a need to allow them to run a particular set of applications that require local administrator permissions, as well as to manage their own physical printer, screen resolution and selected other computer settings.

The only resolution to this problem has been to make each user a member of the Administrators group or otherwise grant their user accounts elevated permissions. This violates the principle of least privilege, presenting significant and obvious security problems; end-users have the ability to circumvent all local computer security.

Protected Administrators:
Administrators are entitled to run processes that require local administrative permissions in order to accomplish their authorized administrative functions. However, the level of permission required varies by application/task. Cautious administrators have a second restricted user account for carrying out tasks that do not require administrative access, such as browsing the web or checking email.

Using this account by cycling between logon sessions and/or using the RunAs utility, presents its own set of difficulties associated with the user of multiple identities, and often this is enough to prevent administrators from adhering to this practice. This violates the principle of least privilege, presenting significant and obvious security problems; if the administrator’s account is attacked from within the browser or by an email worm, the potential damage to the computer and possibly the network can be substantially greater.

Need to Know:
It is common for users to be authorized to access protected data/resourced only in certain authorized circumstances. Computers do not provide this capability in the native security model. Access control to resources is based solely on user identity, not context. Many organizations have a need to restrict resource access based on the application performing the access, so that the application effectively acts as a security proxy to the data – preventing unauthorized data exposure on local systems.

Using the Policy
Policy is applied by creating rules (policies) in the Group Policy Object Editor. Each rule is configured by specifying application targeting criteria and permissions and/or privilege changes to the targeted application’s process token.

Application Targeting
Applications are targeted on the Application tab, which allows you to specify an application by one of several criteria. This includes:

• Path to an executable file
  • supports wildcards and environment variables
  • option to target only files owned by Administrators
  • option to target only if specified command line arguments were used
  • option to extend rule to sub-processes
• Folder of one or more executable files
  • including wildcards and environment variables
  • option to target only files owned by Administrators
  • option to target all subfolders
  • o option to extend rule to sub-processes
• Hash rule
  • SHA1 hash of the targeted executable file
  • option to target only if specified command line arguments were used
  • option to extend rule to sub-processes
• MSI Path rule
  • target Windows Installer installation of specified packages
  • option to extend rule to sub-processes
• MSI Folder rule
  • target Windows Installer installation of all packages in a specified folder
  • option to target packages from all subfolders
  • option to extend rule to sub-processes
• ActiveX rule
  • target installations of components within Internet Explorer
  • options to target by control’s specific source URL
  • option to target by subfolder of source URL
  • options to target by control filename, version range, CLSID, and/or MIME type
  • option to extend rule to sub-processes

Permissions Changes
Changes to the permissions of applications are applied as the application is launched. Each rule provides for security groups to be added to, and/or removed from, the application’s process token. The effect is the same as making changes to the user’s group memberships – but only for the specific application.

Privilege Changes
Changes to the privileges of applications are also applied as the application is launched. Each rule provides for permissions to be granted and/or denied to the application. The effect is the same as if the user had the privileges granted or denied – but only for the specific application. The fixed list of Windows privileges includes such items as the ability to “Shut down the system” and “Take ownership of files or other objects.”

MSI Rules
MSI rules modify MSIEXEC.EXE permissions and privileges, but allow the administrator to target by MSI package.

ActiveX Rules
ActiveX rules are not specifically limited to ActiveX controls, but apply in general to component installations initiated by Internet Explorer (IE) . With IE running as a restricted user, control installations will normally fail and often without proper feedback. This is because the installations occur within the IE process and therefore within the same restricted security context. An ActiveX rule causes a targeted control to install in a separate context that can have its permissions and privileges individually modified by the rule.

More Information
For more information see the Privilege Manager product page.