Vista Evaluation Blog, part 4

Standard User

As stated earlier, Microsoft has finally embraced the industry-standard Least User Privilege principle - give a user only as much privilege that they need to get the job done. The ability to do this has actually been available since Windows NT, using principles used in VMS, but it broke so many legacy programs that it was never enforced. The default install procedure created privileged users, and creating "limited users" was discouraged.

This attitude has now flipped, and users are expected to have non=privileged accounts. Most of the old DOS-based programs that expected access to graphics hardware are gone, but there are still many Windows 9x programs that expect to store data under C:\Program Files\programname, or to store user preferences in the system registry. Some of these problems may be worked around by changing access controls, e.g. adding "user write" to C:\Program Files\programname\Data\, or to certain registry keys. Others may be more complex. Microsoft released a new tool, Standard User Analyzer, to help developers adapt. SUA is reminiscent of Filemon and Regmon from Sysinternals, or the Linux strace utilty, but it has some nice features like "noise" filtering, and logs API access as well as file and registry. However, it is not live - the target process must be stopped before the logs can be analyzed. On XP, it requires .NET 2.0 to be installed, and I was unable to run it successfully on XP as a limited user

I tried SUA on one (critical to me) application - PuTTY. PuTTY runs OK as a limited user on XP, so I had assumed it would run on Vista. However, it fails to connect. Regmon showed a winsock2 registry entry denied, which I addressed by changing the ACL. However, PuTTY would still not connect. SUA showed an access problem to \Device\NamedPipe, which is probably the critical issue. However, I don't have the skill or development tools to check this,

Conclusion:

Many applications that worked in XP and earlier versions, even in limited accounts, may fail under Vista. Users will be faced with having to upgrade the application or run in administrative mode. Developers will be faced with rewriting applications to run with least privilege, or to run under Vista's virtual environment. Administrators will be faced with the dilemma of either being perpetually on call, or giving users an administrator password. For knowledgable administrators, there is the option to tailor access controls to applications for users, so that they may be prompted for a password or simply denied.

My personal recommendation, as for XP, is to run in standard (limited) mode unless you really need privilege - most current viruses and trojans simply won't run, but everyday tasks like Web browsing, email and office will. Switch to a privileged account, or use the "run as" feature, to install software or to run legacy programs that need more access.

Andrew Daviel