eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Symantec is arguing that Windows Vistas User Access Control features are too intrusive, and perhaps they have a point. Theres no reason to assume Microsoft got things perfect. Windows has a rich history of third parties adding value and making it better.
One of my favorite improvements on user access control in all current versions of Windows is BeyontTrust Privilege Manager, a program that is still remarkably alone in providing certain powerful security features for Windows.
User access control is all about setting the privileges for users when accessing certain resources. The heart of the problem being discussed by Symantec is that when you set a general level for a user, and presumably the philosophy these days is that you set the user to have a limited set of rights, you are inevitably going to misestimate what they need for particular tasks.
The main benefit of this is to limit the damage that bugs and exploits in the application can do on a system. When you read vulnerability disclosures you often see a line about the attacker only having the same privileges as the user of the application, and this is an important restriction.
Vistas LUA deals with this by asking the user for more privileged credentials when a task is run that requires them. Nothing shocking here; Mac OSX has done this for years and been praised for it.
There are two approaches to application privileges: building up and dumbing down. Privilege Manager and Vista support both, in different ways. With building up, described above, you start out with an unprivileged user and grant them the privileges they need, and only what they need, on an on-demand basis.
With dumbing down, you start out with a privileged user, like an administrator, and decrease rights when running potentially dangerous applications like Internet Explorer.
Windows Vista users use the building up approach as a general matter, which is why they see the privilege checks Symantec is talking about.
They also use the dumbing down approach in a couple of ways. When logged in as Administrator, Vista tries to dumb down automatically and reminds the user if an app is using privileged operations. Also IE7 itself, even when run by an Administrator, runs in a specially-crippled configuration. (You might say IE is on probation for life, and with its record the sentence is deserved.)
Next page: LUA & Windows history.
LUA
& Windows History”>
Much of this is possible because in Windows, since (I believe) Windows 2000 SP2, privileges have been set not just on users and resources like files and ports, but also on applications themselves. A particular instance of an application running in a particular user context can have specific privileges granted and revoked, as managed by the operating system or other administrative software. This is what Privilege Manager does.
You can see a simple version of this technique, using the dumbing down approach, in the well-known (in some circles) Microsoft utility “DropMyRights”. This program allows the user, on an app-by-app basis, to diminish user rights. (The author, Michael Howard, writes an excellent security blog. Read this entry for a great example of defense-in-depth in Vista.)
Another interesting point about the bits and bytes of this technique is that you can use the Sysinternals (now Microsoft) utility Process Explorer to see the privileges of each running task. Click here to see some of what Process Explorer has to say about Kaspersky Anti-Virus on my system.
The big difference with Privilege Manager is that it takes a managed enterprise approach to the problem: Using Group Policy, an administrator can set user privileges. This is key to enterprises, especially in as much as badly-written custom software is a huge part of the problem in implementing a true LUA.
If the application writes to HKEY_LOCAL_MACHINE or some such ridiculous technique administrators have heretofore either granted blanket permission to that resource to the user, or let the user run as administrator. With Privilege Manager they can allow the user with that app, and only that app, to write there, and to manage all of this centrally through Active Directory.
With Privilege Manager you set rules for one or more applications. An agent on the client system checks applications against the rules transparently. The administrative UI is an extension to the group policy MMC and feels like a natural extension to Windows Server administration.
You can set rules for specific programs, all programs in a particular folder, or take other approaches. Privilege Manager provides helpful clues like the command lines for the program launches, including difficult ones like running the clock applet from the tray.
If theres one problem with the Privilege Manager approach its that it is not easy for an administrator to know what privileges are necessary for the application to run properly, except through trial and error, or perhaps by being very smart and knowing their way around MSDN well.
BeyondTrust plans to address this in a future release with a “logging mode,” in which an administrator can run an application while a program monitors which privileges it is invoking, making a template to apply to the management features.
All of this is done through documented Windows features, and the fact that the features are documented is interesting. As I said above, they have been in Windows for many years, but Microsoft has never put any user interface in Windows for accessing these capabilities.
Some time ago I heard a rumor that Microsoft was going to include functionality like this in Windows Longhorn, but it appears that was wrong. Ive asked the Longhorn team point blank and they say they havent heard of it, and neither has BeyondTrust.
The only strange thing about this is why Microsoft wont do it; its been many years since they introduced the basic functionality, and yet they leave it in there inaccessible to users.
In fact, the situation is even stranger than that. BeyondTrust used to be DesktopStandard and PrivilegeManager used to be PolicyMaker Application Security, which eWEEK Labs reviewed rather favorably last year. Then a lot happened: Microsoft bought DesktopStandard lock, stock and barrel, except for PolicyMaker Application Security. Some of the principals took that application, which they said was their fastest growing product, and became BeyondTrust.
A few months before that, Microsoft bought tools vendor Winternals, apparently more to get the principals of that company (the famous Mark Russinovich and Bryce Cogswell) than their products, many of which Microsoft discontinued.
One of the discontinued products was Winternals Software Protection Manager, about which eWEEK Labs also had some nice things to say. In fact, Microsoft even now endorses BeyondTrust Privilege manager as a migration path for Winternals Software Protection Manager customers.
So not only has Microsoft not provided a product in this space, they seem determined not to do so. Im at a loss to explain this. I can see them not wanting to proceed using the Winternals product, which had some architectural problems, not least of which was that it wasnt based on Group Policy, but they let the DesktopStandard product slip through their fingers too.
Before Microsoft got the LUA religion it was commonly used as a stick to beat the company with, since OSX did it so well. UNIX was better in so many ways and many Windows users lazily run as Administrator. Now that Vista takes LUA so seriously youll see the same reflexive Microsoft bashers complaining about all the privilege checks.
I think consistency is in order here: Microsoft should be extending LUA using the underlying features they built in to Windows to do the job. At least someone is doing it.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer