Archive for the ‘Security’ Category

Modifying UAC Policies

March 4, 2006

For an overview of the six UAC policies and how to modify their settings, see the following UACBlog article:

6 User Account Control Windows Vista Policies


User Account Control Overview

March 4, 2006

For my first post I will summarise one of the key changes in Vista and the implications it will have on existing Windows applications.

One of Microsoft’s main focuses with Vista is to improve security. A major problem with current versions of Windows is that to be productive you pretty much always need to be logged in as an Administrator. There are lots of day to day tasks that a regular user can’t do, but should be able to. An obvious example, which comes up a lot, is the system clock. A regular user cannot double click on the clock in the system tray, because the system assumes they want to change the time. Changing the time is an administrator task, so Windows prevents the user from double clicking on the clock. But people often want to double click on the clock just so that they can view the calendar, without wishing to change anything. And in any case, should changing the time be such a big deal? Well, Vista addresses stuff like this by making it possible to do more as a regular user.

Because of things like this the vast majority of Windows users currently log in as administrators. This means they can do what they want, but since they are running everything with admin privs the system is effectively wide open. When you’re logged in as an administrator software can do pretty much anything, without your knowledge. Software that requires admin privileges will just run and perform admin tasks without warning you first. This leaves the system wide open to malware and we all know how easy it is for viruses and trojans to install themselves, and then run stealthily, leaving you with no idea of what they are doing. Problems with browser toolbars and plugins are rife. This is because with admin privileges they can install and do what they want.

To address this, Vista, by default, runs all applications with restricted standard user privileges, even if you are logged on as an administrator. By default if an application needs (or wants) administrator access it will attempt to “elevate” itself to admin level and Windows will ask you for confirmation before allowing it to run. So now whenever an admin task occurs, you get to know about it and decide whether to allow it or not. This in itself should pretty much wipe out problems with viruses, malware, spyware and adware etc. If a standard user tries to run something that requires admin privs the prompt will ask for an admin username and password. The benefit here is that an administrator doesn’t have to log off and back on again just to perform some admin task for a regular user.

My only concern is that, in this default mode, administrators are going to get pretty fed up with all the prompts every time they try to do something, and I can foresee that many users will disable the prompts in the system security policy, or, worse, disable the default option of running applications at the standard user level, so that all applications run as admin. So the end result would be no different to where we are now with Windows XP. So it remains to be seen how the UAC team plan to handle common tasks – will the system learn about tasks that are performed frequently and stop prompting the user?

Developers need to be aware that the default Vista setup will mean that the user is running in least privilege mode. This could have implications on a vast array of software that, rightly or wrongly, has always assumed administrator privileges. For UAC to be a success developers need to consider how to make their software UAC compliant. Apps that need to perform administrative tasks will need to request administrative privileges. This is achieved via an extension to the trustinfo section of the manifest resource. But many applications that need admin privs don’t always need to run at that level – the UI, for instance, does not require administrative privileges. So developers should consider breaking their application into different executables, putting the admin functionality into a separate executable marked with the “requireAdministrator” attribute. This would mean that the application only prompts the user when it actually needs administrator privileges, rather than on startup, and doesn’t run unnecessarily as admin when it doesn’t need to.

This is just an overview of UAC and the implications for developers. Anyone developing software for Vista should read Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.